Объем прототипа Spring - варианты использования?

Question

У меня есть четкое понимание различных областей применения бобов Spring. Но я ищу некоторые варианты использования прототипа bean-компонента в проектах уровня предприятия. Было бы здорово, если бы вы могли поделиться некоторыми реальными случаями использования области действия прототипа (не области действия request ).

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

<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="lengthFieldBasedFrameDecoder", должен иметь область действия prototype, поскольку в моем приложении это бин с состоянием.

Примечание: Протоколничего, кроме определенного набора декодеров и кодеров, соединенных вместе.Шаблон проектирования «Цепочка ответственности».

Answer 4

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