Lineamientos Capa de Negocio

Lineamientos Generales

Stateful Bean: Cuando se necesite manejar variables de estado dentro del EJB, es decir, mantener información de las variables a través de las invocaciones a métodos. Los EJBs Session Stateful tienen la característica de guardar información del cliente que lo invoca.

@Stateful
@Scope(ScopeType.CONVERSATION)
@Name(value="registroContable")
public class RegistroContableBean implements RegistroContable {
...

Stateless Bean: El Stateless Bean no tiene información específica para un cliente, es decir que no guarda estado entre una y otra petición. En un sólo método de invocación, el bean ejecuta tareas genéricas para todos los clientes. Por ejemplo, se puede usar un Stateless Bean para enviar un email que confirma una orden en línea.

@Stateless
@Name(value="envioNotificaciones")
public class EnvioNotificacionesBean implements EnvioNotificaciones {
...

Las siguientes son los lineamientos que se deben seguir respecto a los EJBs de sesion:

  • Los EJBs Session deben tener un nombre que identifique en forma reducida el nombre del caso de uso (Ejemplo: RegistroContable) seguido del sufijo Bean para identificar que se trata de un Enterprise Java Beans. El nombre de la interface debe tener el mismo nombre del EJB sin el sufijo Bean
  • Las anotaciones básicas que debe haber a nivel del EJB de Session (Anotaciones a nivel de clase) son las siguientes:
    • @Stateful o @Stateless: estas anotaciones son obligatorias para poder definir un EJB de tipo Session (Sin Estado o con Estado)
    • @Name: Cuando se utiliza Seam se debe colocar esta anotación con el nombre del caso de uso pero con la primera letra en minúscula (Ejemplo: registroContable). Este nombre sirve es utilizado cuando el EJB es invocado desde interfaz gráfica
    • @Scope: esta anotación especifica el contexto Seam en el cual estará el EJB: Existen los siguientes contextos Seam: Application, Bussiness, Session, Conversation, Event, Page. Se debe colocar el EJB Session Stateful en un contexto de Conversación por motivos de desempeño y eficiencia. No es necesario especificar el contexto en los Stateless bean. Los EJB Session pueden estar en otros contextos excepto en contexto Page.
    • @Remove: esta anotación debe estar presente sólo en los EJBs Stateful y se debe crear un método (No es necesario que el método contenga implementación) que tenga esta anotación.
  • Los campos dentro de los EJB Session Stateful deben ser privados con sus respectivos métodos get o set si estos son requeridos.
  • En los EJBs Session Stateless no deben existir campos para guardar el estado de un cliente, debido a que estos no guardan información para un cliente especifico.
  • Los campos que pueden tener los EJBs Session Stateless son utilizados para inyección de dependencias (Ej. Inyección de FacesMessages, PersisntenceContext, Resource, etc), o son utilizados para guardar el estado en algún contexto de Seam (excepto contexto Page).
  • La interface que debe implementar los EJB Session debe tener una de las siguientes anotaciones: @Remote o @Local
  • Utilizar en los EJBs Session la clase Log de Seam como mecanismo de log en lugar de la clase Logger de la API log4j.
@Logger
private Log log;
  • La ubicación de los EJBs debe ser sobre el directorio src/hot del proyecto en un paquete con la siguiente nomenclatura.

{com-edu-org}.{enterprise}.{name_project}.{module-component}.{usecase}
Ejemplo: com.heinsohn.core5.batchprocessing.ejecucionprocesos

Manejadores para consultas

Una recomendaciòn en JPA es usar named queries para no escribir directamente en los EJBs las consultas JPQL. Sin embargo el uso de los named queries en los diferentes EJBs que contienen la lógica de negocio presenta ciertos problemas:

  • Si en un EBJ se escribe mal el nombre de un named query el compilador no muestra ningún error y saldra un error en tiempo de ejecución. Esto pasa porque el nombre de un named query es un string y cuando se usa la instruccion createNamedQuery("nombreQuery") el compilador no verifica que exista un query con nombre "nombreQuery".
  • Cuando se usa un namedQuery en un EJB se debe conocer el nombre y el tipo de cada uno de los parámetros que dicha consulta espera. Si el desarrollador usa un namedQuery y le envia parametros diferentes a los que la consulta espera, se generara un error en tiempo de ejecución.
  • Si un named query se esta usando en varios EJBs y este named query se modifica cambiando sus parámetros, se debe ir a cada uno de los EJBs que usan el named query para enviarle a la consulta los nuevos parámetros. Sin embargo, puede ocurrir que se olvide de modificar algun EJB y el error solo se vera en tiempo de ejecucion.
  • Los EJBs que usan un named query o una consulta directamente escrita deben tener código para el manejo de las excepciones que pueda lanzar la ejecucion de la consulta. Esto implica que exista código de manejo de excepciones repetido en todas las partes donde se usa el mismo named query o consulta JPQL.

Los anteriores problemas se pueden resolver con los manejadores. Un manejador es un componente SEAM, que puede ser un Stateless o un POJO, con la característica de que solo debe contener métodos que realicen consultas. De esta forma, un manejador puede ser visto como un Wrapper sobre los named queries de una entidad JPA, aunque también puede contener métodos que realicen consultas con sentencias construidas dinamicamente de acuerdo a los parámetros que reciba el método.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License