Hola habrozhiteli! Publicamos un libro que ofrece una visión general del marco de Spring 5 y los patrones de diseño para él. Se explica el principio de inyección de dependencia, que desempeña un papel clave en la creación de código débilmente acoplado en el marco de Spring. Luego, se examinan los patrones clásicos de Gang of Four cuando se diseñan aplicaciones en Spring. En las siguientes partes del libro, el autor considera los patrones de Programación Orientada a Aspectos (AOP), patrones JDBC que le permiten abstraer el acceso a la base de datos. En los capítulos finales del libro, el autor explora cómo trabajar con MVC, los patrones de diseño reactivos y los patrones de diseño utilizados en la primavera y la programación concurrente.
Sugerimos que se familiarice con el pasaje "Patrón" Objeto de acceso a datos ""
Un objeto de acceso a datos (DAO) es un patrón de diseño extremadamente popular para el nivel de persistencia en aplicaciones J2EE. Separa el nivel de lógica de negocios del nivel de retención. El patrón DAO se basa en principios orientados a objetos de encapsulación y abstracción. El contexto del uso del patrón DAO es el acceso a los datos y su almacenamiento dependiendo de la implementación específica y el tipo de almacenamiento, por ejemplo, una base de datos orientada a objetos, archivos no estructurados, bases de datos relacionales, etc. Basado en el patrón DAO, puede crear una interfaz DAO e implementarla, para abstraer y encapsular todas las llamadas a la fuente de datos. Una implementación DAO similar administra los recursos de la base de datos, como las conexiones a una fuente de datos.
Las interfaces DAO se adaptan muy fácilmente a todos los mecanismos subyacentes de las fuentes de datos; no es necesario reemplazarlas con cambios en las tecnologías de almacenamiento en los niveles inferiores. Este patrón le permite implementar diversas tecnologías de acceso a datos sin afectar la lógica empresarial de la aplicación corporativa. Consideremos la fig. 8.1 para comprender mejor los principios del patrón DAO.
Como puede ver en el diagrama, los siguientes objetos están involucrados en el patrón.
BusinessObject, un objeto que funciona a nivel empresarial, un cliente para el nivel de acceso a datos. Necesita datos para simular procesos empresariales, así como preparar objetos Java para funciones auxiliares o controladores de aplicaciones.
DataAccessObject es el objeto principal del patrón DAO. Oculta de BusinessObject toda la implementación de bajo nivel de la base de datos subyacente.
Un DataSource también es un objeto que contiene toda la información de bajo nivel sobre cuál es exactamente la base de datos subyacente: RDBMS, archivos no estructurados o XML.
TransferObject: un objeto utilizado como medio de almacenamiento. Usado por DataAccessObject para devolver datos a BusinessObject.
Considere el siguiente ejemplo de un patrón DAO en el que AccountDao es la interfaz de un DataAccessObject y AccountDaoImpl es una clase que implementa la interfaz AccountDao:
public interface AccountDao { Integer totalAccountsByBranch(String branchName); } public class AccountDaoImpl extends JdbcDaoSupport implements AccountDao { @Override public Integer totalAccountsByBranch(String branchName) { String sql = "SELECT count(*) FROM Account WHERE branchName = "+branchName; return this.getJdbcTemplate().queryForObject(sql, Integer.class); } }
Crear objetos DAO en Spring usando el patrón de diseño Factory
Como saben, en el marco de Spring intervienen muchos patrones de diseño. El patrón Factory es un patrón de diseño genérico y se utiliza para crear un objeto sin revelar la lógica subyacente al cliente, así como para asignar un nuevo objeto al llamante utilizando una interfaz común o una clase abstracta. Gracias al método Factory y los patrones de diseño Abstract Factory, se puede lograr una flexibilidad muy alta del patrón DAO.
Descubriremos dónde en nuestro ejemplo implementamos la estrategia en la que la fábrica produce objetos DAO para la implementación de una base de datos común (Fig. 8.2).
Puede ver en el diagrama anterior que AccountDaoFactory produce un objeto AccountDao, es decir, es una fábrica para él. La base de datos subyacente se puede reemplazar en cualquier momento, mientras que el código comercial no necesita ser cambiado: la fábrica se encarga de este trabajo. Spring admite el almacenamiento de todos los DAO en la fábrica de componentes, así como en la fábrica de DAO.
Patrón de mapeo de datos
El marco ORM proporciona mapeo entre objetos y bases de datos relacionales, porque los objetos y las tablas de bases de datos relacionales almacenan datos de aplicaciones de diferentes maneras. Además, los objetos y las tablas tienen varios mecanismos para estructurar los datos. Al usar cualquier solución ORM en una aplicación Spring, como Hibernate, JPA o JDO, no hay necesidad de preocuparse por el mecanismo de mapeo entre objetos y bases de datos relacionales.
Consideremos la fig. 8.3 para comprender mejor el patrón del "Mapeador de datos".
En el diagrama, el objeto Cuenta se asigna a la base de datos relacional utilizando la interfaz AccountMapper. AccountMapper desempeña el papel de intermediario en la aplicación entre el objeto Java y la base de datos subyacente. Considere otro patrón utilizado en el nivel de acceso a datos.
Patrón "Modelo de dominio"
Un modelo de dominio es un objeto que tiene datos y comportamiento, donde el comportamiento determina la lógica empresarial de una aplicación corporativa, y los datos representan información sobre los resultados empresariales. El modelo de dominio combina datos y el proceso. En una aplicación corporativa, el modelo de datos se encuentra por debajo del nivel empresarial y define la lógica empresarial, devolviendo los resultados del comportamiento empresarial. Considere el siguiente diagrama para mayor claridad (Fig. 8.4).
Como puede ver en el diagrama, la aplicación define dos modelos de dominio de acuerdo con los requisitos comerciales. El algoritmo empresarial para transferir dinero de una cuenta a otra se describe en la clase TransferService. Las clases TransferService y AccountService se relacionan con el patrón "Modelo de dominio" en la aplicación empresarial.
Proxies para el patrón de descarga diferida
La “carga demorada” es un patrón de diseño utilizado por algunas de las soluciones ORM, por ejemplo, Hibernate, en aplicaciones corporativas para retrasar la inicialización de un objeto hasta que otro objeto acceda a él, es decir, cuando sea necesario. El propósito de este patrón de diseño es optimizar la memoria en la aplicación. El patrón de diseño de carga diferida de Hibernate se implementa utilizando un objeto proxy virtual. Para demostrar la carga retrasada, utilizamos un proxy, pero no se aplica al patrón "Adjunto".
Patrón de método de plantilla para soporte de hibernación en primavera
Spring Framework proporciona una clase auxiliar para acceder a los datos en el nivel DAO, basado en el patrón de diseño del Método de Patrón GoF. La clase HibernateTemplate de Spring Framework admite operaciones de base de datos como guardar, crear, eliminar y actualizar. Esta clase garantiza que solo se use una sesión de Hibernate para cada transacción.
Integración de Hibernate con Spring
Hibernate es un marco de persistencia ORM de código abierto que no solo proporciona una asignación de relaciones de objetos simples entre objetos Java y tablas de bases de datos, sino que también ofrece muchas características avanzadas para mejorar el rendimiento de la aplicación y también ayuda a mejorar la utilización de recursos, como el almacenamiento en caché , carga retrasada, recuperación inmediata de datos y almacenamiento en caché distribuido.
Spring proporciona soporte completo para la integración con el marco de Hibernate, tiene varias bibliotecas integradas que permiten utilizar Hibernate al 100%. Para establecer la configuración de Hibernate en la aplicación, puede usar el patrón de inyección de dependencia y el contenedor IoC del marco Spring.
En la siguiente sección, descubriremos cómo configurar correctamente Hibernate en el contenedor IoC del framework Spring.
Definición de la configuración de objetos de Hibernate de SessionFactory en un contenedor Spring
El mejor enfoque para configurar Hibernate y otras tecnologías de almacenamiento en cualquier aplicación empresarial es separar los objetos comerciales con directorios de recursos cableados, como DataSource en JDBC o SessionFactory en Hibernate. Estos recursos se pueden describir como componentes en el contenedor Spring. Pero el acceso a ellos por objetos comerciales requiere referencias a ellos. Considere la siguiente clase DAO que usa un objeto SessionFactory para recuperar datos para una aplicación:
public class AccountDaoImpl implements AccountDao { private SessionFactory sessionFactory; public void setSessionFactory(SessionFactory sessionFactory) { this.sessionFactory = sessionFactory; } // ... }
Como puede ver, la clase DAO, AccountDaoImpl, sigue el patrón de inyección de dependencia. Para acceder a los datos, el objeto SessionFactory del marco de Hibernate está incrustado en él, y se siente muy bien en el contenedor IoC Spring. El objeto SessionFactory del marco de Hibernate es un objeto único; genera el objeto principal de la interfaz de Hibernate org.hibernate.Session. El objeto SessionFactory gestiona el objeto Session y también es responsable de abrirlo y cerrarlo. La interfaz de sesión contiene la funcionalidad de acceso a datos reales: guardar (guardar), actualizar (actualizar), eliminar (eliminar) y cargar (cargar) objetos de la base de datos. En la aplicación, un objeto de la clase AccountDaoImpl o cualquier otro repositorio realiza todas las operaciones de almacenamiento de datos necesarias utilizando este objeto Session.
Spring Framework proporciona módulos integrados de Hibernate, por lo que puede usar componentes SessionFactory Hibernate en sus aplicaciones.
El componente org.springframework.orm.hibernate5.LocalSessionFactoryBean es una implementación de la interfaz Spring FactoryBean. LocalSessionFactoryBean se basa en el patrón Abstract Factory; genera un objeto SessionFactory en la aplicación. Este objeto se puede configurar como un componente en el contexto de una aplicación Spring de la siguiente manera:
@Bean public LocalSessionFactoryBean sessionFactory(DataSource dataSource) { LocalSessionFactoryBean sfb = new LocalSessionFactoryBean(); sfb.setDataSource(dataSource); sfb.setPackagesToScan(new String[] { "com.packt.patterninspring.chapter8.bankapp.model" }); Properties props = new Properties(); props.setProperty("dialect", "org.hibernate.dialect.H2Dialect"); sfb.setHibernateProperties(props); return sfb; }
En este código, configuramos el objeto SessionFactory como un componente utilizando la clase LocalSessionFactoryBean del marco Spring. El método de este componente acepta un objeto de tipo DataSource como argumento, que determina la ubicación y el método de conexión a la base de datos. También especificamos qué paquete ver al establecer el valor "com.packt.patterninspring.chapter8.bankapp.model" para la propiedad setPackagesToScan del componente LocalSessionFactoryBean, y establecemos la propiedad de dialecto del componente SessionFactory utilizando el método setHibernateProperties para indicar qué tipo de base de datos tenemos con materia en la solicitud.
Ahora, después de configurar el componente SessionFactory Hibernate, en el contexto de la aplicación Spring, veamos cómo podemos implementar objetos de acceso a datos para el nivel de guardado de nuestra aplicación.
Sobre el autor
Dinesh Rajput es editor jefe del sitio web Dineshonjava, un blog técnico dedicado a las tecnologías Java y Spring. El sitio contiene artículos sobre tecnología Java. Dinesh es blogger, autor de libros, desde 2008 entusiasta de Spring, especialista certificado en Pivotal (Pivotal Certified Spring Professional). Tiene más de una década de experiencia en diseño y desarrollo utilizando Java y Spring. Se especializa en trabajar con la última versión de Spring Framework, Spring Boot, Spring Security, creando una API REST, arquitectura de microservicios, programación reactiva, programación orientada a aspectos usando Spring, patrones de diseño, Struts, Hibernate, servicios web, Spring Batch, Cassandra, MongoDB, una arquitectura de aplicaciones web.
Actualmente, Dinesh está trabajando como gerente de tecnología en una de las compañías líderes en el campo del desarrollo de software. Fue el desarrollador y líder del equipo en Bennett, Coleman & Co. Ltd, y antes de eso, un desarrollador líder en Paytm. Dinesh está entusiasmado con las últimas tecnologías Java y le gusta escribir sobre ellas en blogs técnicos. Es miembro activo de las comunidades de Java y Spring en varios foros. Dinesh es uno de los mejores especialistas en Java y Spring.
Sobre el revisor
Rajiv Kumar Mohan tiene una amplia experiencia en desarrollo de software y capacitación corporativa. Durante 18 años, ha trabajado para importantes empresas de TI como IBM, Pentasoft, Sapient y Deft Infosystems. Comenzó su carrera como programador, dirigió muchos proyectos.
Es experto en el área temática de Java, J2EE y marcos relacionados, Android, tecnologías de interfaz de usuario. Certificado por Sun como Programador Java (SCJP, Programador Java Certificado Sun) y Desarrollador Web Java (Desarrollador de Componentes Web Certificado Sun, SCWCD). Rajiv tiene cuatro estudios superiores: en el campo de la informática (informática), informática aplicada (aplicaciones informáticas), química orgánica y administración de empresas (MBA). Es consultor de reclutamiento y experto en capacitación en HCL, Amdocs, Steria, TCS, Wipro, Oracle University, IBM, CSC, Genpact, Sapient Infosys y Capgemini.
Rajeev es el fundador de SNS Infotech, una empresa ubicada en la ciudad de Greater Noida. Además, trabajó en el Instituto Nacional de Tecnología de la Moda (NIFT).
»Se puede encontrar más información sobre el libro en
el sitio web del editor»
Contenidos»
ExtractoCupón de 20% de descuento para vendedores ambulantes -
Primavera