EJB3 Business Logic Patterns & Practices

Question

Estoy en el proceso de desarrollo de una aplicación de procesamiento financiero en Java con EJB3 (Hibernate + Glassfish para la capa de aplicaciones y servicios web, Lift on Glassfish para la interfaz de usuario web) y yo Estoy luchando con la pregunta de dónde poner mi lógica comercial.

Cuando se inició este proyecto, nuestra primera noción era poner la mayor parte de nuestra lógica comercial en los beans de sesión sin estado. Sin embargo, a medida que pasa el tiempo, hemos encontrado que la inyección de dependencia proporcionada por el marco EJB es demasiado restrictiva, por lo que gran parte de nuestra lógica empresarial ha terminado en POJOs que Guice ensambla en el método @PostConstruct de los beans de sesión sin estado . Este progreso ha llevado a la fragmentación de nuestra lógica empresarial entre los beans de sesión y los POJO, y estoy tratando de encontrar un enfoque para corregir esto.

Inicialmente, intentamos que nuestro nivel web utilizara las interfaces remotas de los beans de sesión para realizar algunas funciones que son accesibles tanto desde la interfaz de usuario como desde la capa de servicio web, proporcionada por beans de sesión sin estado anotados por @ WebService . Esto resultó ser una pesadilla desde una perspectiva de persistencia y rendimiento, porque nuestro gráfico de entidades puede crecer bastante y volver a unir el gráfico de entidad separado al contexto de persistencia resultó ser altamente propenso a errores, por lo que nuestra solución fue comenzar a pasar el objeto identificadores alrededor y buscando las entidades de la base de datos donde sea que se necesiten.

Mi pregunta básica es esta: ¿qué principios y directrices puede sugerir para decidir si la lógica comercial debe ir en un bean de sesión o un POJO? ¿Cuándo tiene sentido pasar beans de entidad, dado un gráfico de objeto complejo?

Answer 1

Luché con esto mientras construía una aplicación web usando JPA, EJB3 y Wicket. Desde que tocó mi base de datos dura con consultas repetidas era más escalable que sostiene un montón de grandes entidades en la memoria, decidí pasar sólo alrededor de sus ids y nunca la propia entidad.

Wicket y su concepto de modelos tuvieron mucho que ver con esta decisión. Su modelo descargableDetachableModel limpia las entidades cuando no están en uso, sin dejar de aferrarse a la id. Se implementa un método load() que sabe cómo obtener la entidad cuando se necesita de nuevo, en mi caso llamando a un bean de sesión sin estado; y un método persist() llama al bean sin estado para persistir los cambios. Esta clase de modelo es lo que realmente paso. Wicket solo maneja la lógica relacionada con la validación de visualización y entrada, y solo necesito inyectar el ejb en las clases de modelo. Tal vez podría crear algo similar en su aplicación (no tengo idea de qué ascensor tiene para ofrecer ...).

Esto ha funcionado muy bien para mí, pero no tengo una lógica empresarial particularmente compleja y puedo aislar cualquier cambio que deba persistir en unidades pequeñas de lógica y páginas individuales.

Answer 2

Cuando necesite muchos servicios de "sistema" (inyecciones, etc.) use bean sin estado. De lo contrario - POJOs. Los POJO son mucho más flexibles.

Sin embargo, los métodos simples (¿de acceso?) (Por ejemplo, en webservices y beans) pueden simplemente hacer un trabajo simple y devolver los resultados.