Spring область действия прототипа - использовать случаи?

Ответ 1

Я использовал прототип в основном в сочетании с spring lookup-method. Мое приложение - игровой сервер, который должен декодировать входящие байты на tcp-порту. Рассмотрим следующее определение bean

<bean id="channelBufferProtocol" class="org.menacheri.protocols.impl.ChannelBufferProtocol">
    <lookup-method name="createLengthBasedFrameDecoder" bean="lengthFieldBasedFrameDecoder"/>
    <property name="eventDecoder" ref="eventDecoder"></property>
    <property name="lengthFieldPrepender" ref="lengthFieldPrepender"></property>
    <property name="eventEncoder" ref="eventEncoder"></property>
</bean>

Внутри класса реализации протокола у меня есть следующий код для создания декодера кадров pipeline.addLast("lengthDecoder", createLengthBasedFrameDecoder()); Когда этот метод вызывается, spring создаст экземпляр нового декодера кадра и вернет его.

bean, возвращаемый bean="lengthFieldBasedFrameDecoder", должен иметь область prototype, так как это состояние bean в моем приложении.

Примечание.. Протокол - это не что иное, как определенный набор декодеров и кодеров, соединенных вместе. Конструкция шаблона "Цепь ответственности".

Ответ 2

Я использовал прототип beans для объявления настроенных элементов формы (текстовое поле, настроенное для проверки имен, адресов электронной почты, например) и получения "живых" экземпляров для каждой формы, созданной в моем веб-приложении. Детали не важны, только принцип, который я бы обобщил следующим образом:

• Существует класс, который имеет множество параметров конфигурации
• Вам нужно создать экземпляры его с набором предопределенной конфигурации (fancy1, fancy2, stc.)
• Подумайте о applicationContext.getBean("myBeanConfiguredFancy1") как виде factory метода, который создает экземпляр как предварительно сконфигурированный в xml

Ответ 3

Как тот, кто ранее работал в SpringSource и говорил с разработчиками по этой теме. Вот мой прием. Прототип отлично подходит для тестирования, поэтому прототип имени, а не createnew или что-то более подробное описание создания нового экземпляра bean каждый раз, когда вы запрашиваете его из контейнера Spring.

Я также нашел в моем использовании на протяжении многих лет, что я не могу ничего другого места, где прототип имеет смысл в любом реальном приложении для производства. Если ваш объект имеет состояние, он обычно не должен быть Spring bean. Я нашел во всех приложениях, над которыми я работал, что все beans являются службами, хранилищами и хранилищами Singleton, в которых мне нужно добавить такие функции, как Transactionality, JPA, JMS и т.п., которые предоставляют нам функции предприятия, которые POJO не имеют.

Объекты моей системы, в которых хранятся состояния, могут быть мои объекты и View DTOs, или другие вещи, которые просто не имеют смысла быть Spring bean. Поэтому поэтому в моих приложениях в производстве не было ни одного "prototype" bean.

Ответ 4

Мы можем использовать область прототипа в случае классов моделей (также называемых сущностями в спящем режиме), поскольку для каждого потока/запроса приложения нужны разные экземпляры класса модели.