Alcance del prototipo de primavera: ¿casos de uso?

Question

Tengo una comprensión clara de los diversos alcances de Spring beans. Pero estoy buscando algunos casos de uso del alcance prototipo de un frijol en proyectos de nivel empresarial. Sería genial si puede compartir algunos casos de uso de la vida real del alcance del prototipo (no el alcance de la solicitud ).

Answer 1

He usado un prototipo en su mayoría junto con la primavera lookup-method. Mi aplicación es game server que necesita decodificar bytes entrantes en el puerto tcp. Considere la siguiente definición de frijol

<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> 

Dentro de la clase de implementación de protocolo, tengo el siguiente código para crear el decodificador marco pipeline.addLast("lengthDecoder", createLengthBasedFrameDecoder()); Cuando se invoca este método, la primavera va a crear una nueva instancia decodificador de cuadro y devolverlo.

El bean devuelto por bean="lengthFieldBasedFrameDecoder" debe ser del alcance prototype, ya que es un bean con estado en mi aplicación.

Nota: Un protocolo no es más que un conjunto específico de decodificadores y codificadores encadenados. Patrón de diseño de "cadena de responsabilidad".

Answer 2

Usé prototipos de beans para declarar los elementos de formulario configurados (un cuadro de texto configurado para validar nombres, direcciones de correo electrónico, por ejemplo) y obtener instancias "vivas" de ellos para cada formulario que se crea en mi aplicación web. Los detalles no son importantes, sólo el principio, que iba a resumir de esta manera:

• Hay una clase que tiene muchos parámetros de configuración
• Es necesario crear instancias de ella con un conjunto de configuración predefinida (fancy1 , fancy2, STC.)
• pienso en la applicationContext.getBean("myBeanConfiguredFancy1") como una especie de método de fábricaque crea la instancia como preconfigurado en el xml

Answer 3

podemos utilizar alcance prototipo en el caso de las clases del modelo (también ca llenos como Entidades en hibernación) ya que la aplicación necesita diferentes instancias de clase de modelo para cada subproceso/solicitud.

Answer 4

Como alguien que trabajó anteriormente en SpringSource y ha hablado con los desarrolladores sobre este tema. Aquí está mi opinión. El prototipo es ideal para probar cosas, de ahí el prototipo de nombre y no crear algo nuevo o algo más que describa la creación de una nueva instancia del bean cada vez que lo solicite desde el contenedor de Spring.

También he encontrado en mi uso a lo largo de los años que no puedo pensar en ningún otro lugar donde el prototipo tenga sentido en cualquier aplicación de producción del mundo real. Si su objeto mantiene el estado, por lo general no debería ser un Bean de primavera. He encontrado en todas las aplicaciones en las que he trabajado que todos los beans son Servicios, Repositorios y objetos de retención no estatales de Singleton donde necesito agregar funciones como Transactionality, JPA, JMS y los "me gusta" que nos brindan las características empresariales que POJOs don ' t tener.

Los objetos en mi sistema que mantienen el estado son mis Entidades y Vistas DTO quizás, u otras cosas que simplemente no tienen sentido para ser un Spring Bean. Por lo tanto, en mis aplicaciones en producción no ha habido un solo bean "prototipo".