EJB3 Business Logic Patterns & amp; Practicas

Question

Estoy en el proceso de desarrollar una aplicación de procesamiento financiero de múltiples niveles en Java usando EJB3 (Hibernate + Glassfish para la aplicación y la capa de servicios web, Lift on Glassfish para la interfaz de usuario web) y estoy luchando con la pregunta de donde colocar mi logica empresarial.

Cuando este proyecto comenzó, nuestra primera idea fue poner la mayor parte de nuestra lógica de negocios en los beans de sesión sin estado. Sin embargo, a medida que el tiempo transcurrió, encontramos que la inyección de dependencia proporcionada por el marco EJB es demasiado limitada, por lo que gran parte de nuestra lógica de negocios 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 de negocios 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 usara las interfaces remotas de los beans de sesión para realizar algunas funciones a las que se puede acceder tanto desde la interfaz de usuario como desde la capa de servicio web, que se proporciona mediante @ WebService sin estado de sesión sesgados. Esto resultó ser una pesadilla desde la perspectiva de la persistencia y el rendimiento, ya que nuestro gráfico de entidad puede crecer bastante y volver a unir el gráfico de la entidad separada 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 necesario.

Mi pregunta básica es la siguiente: ¿qué principios y pautas puede sugerir para decidir si la lógica de negocios debería incluirse en un bean de sesión o un POJO? ¿Cuándo tiene sentido pasar los 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. Ya que golpear la base de datos con consultas repetidas era más escalable que tener muchas entidades grandes en la memoria, decidí pasar solo sus ID y nunca a la entidad en sí.

Wicket y su concepto de modelos tuvieron mucho que ver con esta decisión. Su loadableDetachableModel limpia las entidades cuando no están en uso, mientras se mantienen en la identificación. Se implementa un método load () que sabe cómo obtener la entidad cuando se necesita nuevamente, en mi caso, llamando 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 visualización y la validación de entrada, y solo necesito inyectar el ejb en las clases del modelo. Quizás puedas crear algo similar en tu aplicación (no tengo idea de lo que Lift tiene para ofrecer ...).

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

Answer 2

Cuando necesites muchos " sistema " Los servicios (inyecciones, etc.) utilizan frijol sin estado. De lo contrario - POJOs. Los POJO son mucho más flexibles.

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