5.4 Caso de estudio: diseño e implementación de la capa modelo de MiniBank con EJB

Transcripción

1 5.4 Caso de estudio: diseño e implementación de la capa modelo de MiniBank con EJB

2 Introducción La arquitectura de la capa modelo de MiniBank es igual que la de MiniPortal Paquetes nuevos en la capa modelo Clases Entidad Account y AccountOperation es.udc.fbellas.j2ee.minibank.model.account.entity es.udc.fbellas.j2ee.minibank.model.accountoperation.entity Implementación de los casos de uso (AccountFacade) es.udc.fbellas.j2ee.minibank.model.accountfacade.ejb y es.udc.fbellas.j2ee.minibank.model.accountfacade.ejb.actions Qué aspectos nuevos aporta el estudio de la capa modelo de MiniBank con respecto a la de MiniPortal? El soporte del API de Persistencia para la generación numérica de identificadores El soporte del API de Persistencia para la implementación del patrón Page-by-Page Iterator Implementación de Stateless Session Beans

3 Generación numérica de identificadores En las clases entidad Account y AccountOperation se han usado anotaciones especiales en la propiedad de la clave primaria para que Los valores se generen mediante una secuencia (si la base de datos proporciona secuencias) Se mapee a una columna contador (si la base de datos ofrece columnas contador) Al igual que en MiniPortal, no se han generado nuevas tablas, sino que se utilizan las mismas que las de la versión JDBC de la capa modelo de MiniBank (inclusive las secuencias)

4 Ejemplo: public class AccountOperation { private Long accountoperationidentifier; private Long accountidentifier; private Calendar date; private byte type; private double amount; public AccountOperation() { public AccountOperation(Long accountidentifier, Calendar date, byte type, double amount) { this.accountidentifier = accountidentifier; this.date = date; this.type = type; this.amount = amount;

5 Ejemplo: // It only takes effect name="accountoperationidentifiergenerator", // for databases provi- // ding intentifier sequencename="accountopseq") generator="accountoperationidentifiergenerator") public Long getaccountoperationidentifier() { return accountoperationidentifier; public void setaccountoperationidentifier( Long accountoperationidentifier) { this.accountoperationidentifier = public Long getaccountidentifier() { return accountidentifier; public void setaccountidentifier(long accountidentifier) { this.accountidentifier = accountidentifier;

6 Ejemplo: AccountOperation (y 3) public Calendar getdate() { return date; public void setdate(calendar date) { this.date = date; public byte gettype() { return type; public void settype(byte type) { this.type = type; public double getamount() { return amount; public void setamount(double amount) { this.amount = amount;

7 Anotaciones para generación de identificadores numéricos stategy Especifica la estrategia de generación de identificadores numéricos Es de tipo GenerationType (enumerado) SEQUENCE: usar una secuencia IDENTITY: mapear la clave a una columna contador TABLE: usar una tabla para emular un conjunto de secuencias (cada fila es una secuencia para una entidad particular) AUTO: la implementación del API de Persistencia decide la estrategia en función de la BD que se esté usando generator Especifica el nombre del generador que se usará en el caso de las estrategias TABLE o SEQUENCE

8 Anotaciones para generación de identificadores numéricos Especifica información de mapeo para un generador que se puede usar con la estrategia SEQUENCE name: nombre del generador sequencename: nombre de la Especifica información de mapeo para un generador que se puede usar con la estrategia TABLE La estrategia SEQUENCE es más eficiente Los atributos/propiedades anotadas tienen que ser de tipo entero (short, int, long y sus contrapartidas objetuales)

9 Anotaciones para generación de identificadores numéricos (y 3) Cómo se puede especificar que la implementación del API de Persistencia utilice secuencias o columnas contador para la propiedad accountoperationidentifier? En el ejemplo se ha generator="accountoperationidentifiergenerator") JBoss utiliza la estrategia IDENTITY para MySQL y SEQUENCE para PostgreSQL (utiliza la información del generador especificado) Si la implementación del API de Persistencia no es tan inteligente, habría que especificar (dependiendo del tipo de generator="accountoperationidentifiergenerator")

10 Otros aspectos (1) El constructor con argumentos deja el atributo accountoperationidentifier sin inicializar La implementación de los casos de uso invoca este constructor cuando tiene que crear una instancia de AccountOperation No puede dar valor al atributo accountoperationidentifier: es la implementación del API de Persistencia la que le asignará valor tras la invocación de EntityManager.persist (invocando el método setaccountoperationidentifier) AccountOperation accountoperation = new AccountOperation(...); // "accountoperationidentifier" todavía no tiene valor asignado. entitymanager.persist(accountoperation); // "accountoperationidentifier" ya tiene valor asignado. Se ha usado la para especificar que la entidad AccountOperation se mapea a la tabla AccountOp

11 Otros aspectos (y 2) Los atributos/propiedades de tipo Calendar se mapean por defecto al tipo SQL TIMESTAMP Si alternativamente se desea usar DATE o TIME se puede usa la No se ha incluido una propiedad anotada dado que las instancias de AccountOperation no son modificables (y en consecuencia, no es útil)

12 Page-by-Page Iterator (1) En MiniBank se hace uso del lenguaje de consultas EJB-QL para la implementación de los caso de uso Encontrar las cuentas de un usuario Encontrar las operaciones bancarias realizadas sobre una cuenta entre dos fechas El lenguaje EJB-QL se estudia en el apartado 5.5 El API de Persistencia permite lanzar una consulta de búsqueda y obtener Todos los resultados, o Un rango de resultados (Page-by-Page Iterator)

13 Page-by-Page Iterator (2) Ejemplo: en la implementación del caso de uso findaccountoperationsbydate (cont) /* * Find count+1 account operations to determine if there exist more * account operations above the specified range. */ List<AccountOperation> accountoperations = entitymanager.createquery( "SELECT o FROM AccountOperation o " + "WHERE o.accountidentifier = :accountidentifier AND " + "o.date >= :startdate AND o.date <= :enddate ORDER BY o.date"). setparameter("accountidentifier", accountidentifier). setparameter("startdate", startdate, TemporalType.TIMESTAMP). setparameter("enddate", enddate, TemporalType.TIMESTAMP). setmaxresults(count+1). setfirstresult(startindex-1). getresultlist(); boolean existmoreaccountoperations = accountoperations.size() == (count+1);

14 Page-by-Page Iterator (3) Ejemplo: en la implementación del caso de uso findaccountoperationsbydate (cont) /* * Remove the last account operation from the returned list if there * exist more account operations above the specified range. */ if (existmoreaccountoperations) { accountoperations.remove(accountoperations.size()-1); /* Return AccountOperationChunkVO. */ return new AccountOperationChunkVO( AccountFacadeHelper.toAccountOperationVOs(accountOperations), existmoreaccountoperations);

15 Page-by-Page Iterator (y 4) Ejemplo: en la implementación del caso de uso findaccountoperationsbydate (cont) El método createquery devuelve un objeto Query Las cadenas :XXX son parámetros nombrados y se les puede dar valor con los métodos setparameter Devuelven el propio objeto Query otra vez, para permitir escribir de manera compacta la construcción de la consulta y su ejecución En el caso de fechas, hay que usar la variante que recibe un parámetro que especifica si el valor pasado es un DATE, TIME o TIMESTAMP Page-by-Page Iterator setmaxresults permite especificar el número máximo de resultados setfirstresult permite especificar el índice del primer resultado (de 0 en adelante) Ambos métodos devuelven otra vez el objeto Query getresultlist permite ejecutar una consulta de lectura y devuelve una lista con los resultados

16 SLSBs (1) Los SLSBs (Stateless Session Beans) son fachadas sin estado Al igual que en MiniPortal, en MiniBank se han definido los interfaces AccountFacade LocalAccountFacade y RemoteAccountFacade La clase de implementación de un SLSB Se anota (definida en javax.ejb) Tiene que tener un constructor público sin argumentos No puede ser final Tiene que implementar los interfaces definidos Ejemplo en MiniBank: AccountFacadeEJB

17 SLSBs (2) public class AccountFacadeEJB implements LocalAccountFacade, RemoteAccountFacade (unitname=globalnames.persistence_unit) private EntityManager entitymanager; public AccountFacadeEJB() { public AccountVO createaccount(accountvo accountvo) { //... //...

18 Pool de instancias SLSBs (y 3) La implementación de EJB crea un pool de instancias por cada SLSB Cuando una clase cliente busca un SLSB por JNDI, la implementación de EJB no crea una instancia asociada al Proxy devuelto Cada vez que la clase cliente realiza una invocación sobre el Proxy de un SLSB, la petición se redirige a una de las instancias del pool que no esté siendo utilizada en ese momento En consecuencia Un SLSB no puede tener atributos que definan estado propiamente dicho No puede tener atributos cuyo valor haya que recordar entre invocaciones (e.g. no podría tener un atributo tipo loginname como en el caso de UserFacadeEJB en MiniPortal) NOTA: el atributo entitymanager en AccountFacadeEJB sólo tiene un valor útil durante la ejecución de cada método de la fachada Recuérdese que la implementación de EJB inicializa un atributo anotado antes de ejecutar cualquier método del Session Bean