Oi, habrozhiteli! Publicamos um livro que fornece uma visão geral da estrutura e padrões de design do Spring 5. O princípio da injeção de dependência é explicado, que desempenha um papel fundamental na criação de código fracamente acoplado na estrutura Spring. Em seguida, os padrões clássicos do Gang of Four são examinados ao projetar aplicativos no Spring. Nas partes seguintes do livro, o autor discute os padrões de programação orientada a aspectos (AOP), padrões JDBC que permitem abstrair o acesso ao banco de dados. Nos capítulos finais do livro, o autor explora o trabalho com o MVC, os padrões de design reativo e os padrões de design usados na programação simultânea e paralela no Spring.
Sugerimos que você se familiarize com a passagem "Padrão" Objeto de acesso a dados ""
Um Data Access Object (DAO) é um padrão de design extremamente popular para o nível de persistência nos aplicativos J2EE. Ele separa o nível da lógica de negócios do nível de retenção. O padrão DAO é baseado em princípios orientados a objetos de encapsulamento e abstração. O contexto para usar o padrão DAO é o acesso aos dados e seu armazenamento, dependendo da implementação e do tipo de armazenamento específicos, por exemplo, um banco de dados orientado a objetos, arquivos não estruturados, bancos de dados relacionais etc. Com base no padrão DAO, você pode criar uma interface DAO e implementá-la, abstrair e encapsular todas as chamadas para a fonte de dados. Uma implementação semelhante do DAO gerencia recursos de banco de dados, como conexões com uma fonte de dados.
As interfaces DAO são muito fáceis de se adaptar a todos os mecanismos subjacentes das fontes de dados; elas não precisam ser substituídas por alterações nas tecnologias de armazenamento em níveis mais baixos. Esse padrão permite implementar várias tecnologias de acesso a dados sem afetar a lógica de negócios do aplicativo corporativo. Vamos considerar a fig. 8.1 para entender melhor os princípios do padrão DAO.
Como você pode ver no diagrama, os seguintes objetos estão envolvidos no padrão.
BusinessObject - um objeto que funciona no nível comercial - um cliente para o nível de acesso a dados. Ele precisa de dados para simular processos de negócios, bem como preparar objetos Java para funções auxiliares ou controladores de aplicativos.
DataAccessObject é o principal objeto do padrão DAO. Oculta do BusinessObject toda a implementação de baixo nível do banco de dados subjacente.
Um DataSource também é um objeto que contém todas as informações de baixo nível sobre o que exatamente é o banco de dados subjacente: RDBMS, arquivos não estruturados ou XML.
TransferObject - um objeto usado como meio de armazenamento. Usado pelo DataAccessObject para retornar dados ao BusinessObject.
Considere o exemplo a seguir de um padrão DAO no qual AccountDao é a interface de um DataAccessObject e AccountDaoImpl é uma classe que implementa a interface 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); } }
Criando objetos DAO no Spring usando o padrão de design Factory
Como você sabe, muitos padrões de design estão envolvidos na estrutura do Spring. O padrão Factory é um padrão genérico de design e é usado para criar um objeto sem revelar a lógica subjacente ao cliente, além de atribuir um novo objeto ao chamador usando uma interface comum ou classe abstrata. Graças aos padrões de projeto Factory Method e Abstract Factory, é possível obter uma flexibilidade muito alta do padrão DAO.
Descobriremos onde, em nosso exemplo, implementamos a estratégia na qual a fábrica produz objetos DAO para a implementação de um banco de dados comum (Fig. 8.2).
Você pode ver no diagrama anterior que o AccountDaoFactory produz um objeto AccountDao, ou seja, é uma fábrica para ele. O banco de dados subjacente pode ser substituído a qualquer momento, enquanto o código comercial não precisa ser alterado - a fábrica realiza esse trabalho. O Spring suporta o armazenamento de todos os DAOs na fábrica de componentes e também na fábrica do DAO.
Padrão de Mapeamento de Dados
A estrutura ORM fornece mapeamento entre objetos e bancos de dados relacionais, porque objetos e tabelas de bancos de dados relacionais armazenam dados do aplicativo de maneiras diferentes. Além disso, objetos e tabelas possuem vários mecanismos para estruturar dados. Ao usar qualquer solução ORM em um aplicativo Spring, como Hibernate, JPA ou JDO, não é necessário se preocupar com o mecanismo de mapeamento entre objetos e bancos de dados relacionais.
Vamos considerar a fig. 8.3 para entender melhor o padrão "Data Mapper".
No diagrama, o objeto Account é mapeado para o banco de dados relacional usando a interface AccountMapper. O AccountMapper desempenha o papel de intermediário no aplicativo entre o objeto Java e o banco de dados subjacente. Considere outro padrão usado no nível de acesso a dados.
Padrão "Modelo de Domínio"
Um modelo de domínio é um objeto que possui dados e comportamento, em que o comportamento determina a lógica de negócios de um aplicativo corporativo e os dados representam informações sobre os resultados dos negócios. O modelo de domínio combina dados e o processo. Em um aplicativo corporativo, o modelo de dados está localizado abaixo do nível de negócios e define a lógica de negócios, retornando os resultados do comportamento dos negócios. Considere o seguinte diagrama para maior clareza (Fig. 8.4).
Como você pode ver no diagrama, o aplicativo define dois modelos de domínio de acordo com os requisitos de negócios. O algoritmo comercial para transferir dinheiro de uma conta para outra é descrito na classe TransferService. As classes TransferService e AccountService estão relacionadas ao padrão "Modelo de Domínio" no aplicativo corporativo.
Proxies para o Padrão de Download Adiado
"Carregamento atrasado" é um padrão de design usado por algumas das soluções ORM, por exemplo, Hibernate, em aplicativos corporativos para atrasar a inicialização de um objeto até que outro objeto o acesse, ou seja, quando for necessário. O objetivo desse padrão de design é otimizar a memória no aplicativo. O padrão de design de carregamento diferido do Hibernate é implementado usando um objeto proxy virtual. Para demonstrar o atraso no carregamento, usamos um proxy, mas ele não se aplica ao padrão "Deputado".
Padrão de método de modelo para suporte a hibernação na primavera
A estrutura Spring fornece uma classe auxiliar para acessar dados no nível DAO, com base no padrão de design do Método de Padrão GoF. A classe HibernateTemplate da estrutura Spring suporta operações de banco de dados, como salvar, criar, excluir e atualizar. Essa classe garante que apenas uma sessão do Hibernate seja usada para cada transação.
Integração do Hibernate com Spring
O Hibernate é uma estrutura de persistência ORM de código aberto que não apenas fornece uma exibição de relacionamentos simples de objetos entre objetos Java e tabelas de banco de dados, mas também oferece muitos recursos avançados para melhorar o desempenho do aplicativo e também ajuda a melhorar a utilização de recursos, como cache , carregamento atrasado, recuperação imediata de dados e cache distribuído.
O Spring oferece suporte completo à integração com a estrutura do Hibernate, possui várias bibliotecas internas que possibilitam o uso do Hibernate em 100%. Para definir as configurações de hibernação no aplicativo, você pode usar o padrão de injeção de dependência e o contêiner de IoC da estrutura Spring.
Na próxima seção, descobriremos como configurar o Hibernate corretamente no contêiner IoC da estrutura Spring.
Definindo configurações de objeto de hibernação SessionFactory em um contêiner Spring
A melhor abordagem para configurar o Hibernate e outras tecnologias de armazenamento em qualquer aplicativo corporativo é separar objetos de negócios com diretórios de recursos conectados, como DataSource no JDBC ou SessionFactory no Hibernate. Esses recursos podem ser descritos como componentes no contêiner Spring. Mas o acesso a eles por objetos de negócios requer referências a eles. Considere a seguinte classe DAO que usa um objeto SessionFactory para recuperar dados para um aplicativo:
public class AccountDaoImpl implements AccountDao { private SessionFactory sessionFactory; public void setSessionFactory(SessionFactory sessionFactory) { this.sessionFactory = sessionFactory; } // ... }
Como você pode ver, a classe DAO, AccountDaoImpl, segue o padrão de injeção de dependência. Para acessar os dados, o objeto SessionFactory da estrutura do Hibernate está incorporado e fica ótimo no contêiner IoC Spring. O objeto SessionFactory da estrutura do Hibernate é um único objeto; ele gera o principal objeto da interface org.hibernate.Session do Hibernate. O objeto SessionFactory gerencia o objeto Session e também é responsável por abri-lo e fechá-lo. A interface Session contém funcionalidades reais de acesso a dados - salvar (salvar), atualizar (atualizar), excluir (excluir) e carregar (carregar) objetos do banco de dados. No aplicativo, um objeto da classe AccountDaoImpl ou qualquer outro repositório executa todas as operações de armazenamento de dados necessárias usando esse objeto Session.
A estrutura do Spring fornece módulos internos do Hibernate, para que você possa usar os componentes SessionFactory Hibernate em seus aplicativos.
O componente org.springframework.orm.hibernate5.LocalSessionFactoryBean é uma implementação da interface Spring FactoryBean. LocalSessionFactoryBean é baseado no padrão Abstract Factory; gera um objeto SessionFactory no aplicativo. Este objeto pode ser configurado como um componente no contexto de um aplicativo Spring da seguinte maneira:
@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; }
Nesse código, configuramos o objeto SessionFactory como um componente usando a classe LocalSessionFactoryBean da estrutura Spring. O método desse componente aceita um objeto do tipo DataSource como argumento, que determina o local e o método de conexão com o banco de dados. Também especificamos qual pacote exibir, definindo o valor “com.packt.patterninspring.chapter8.bankapp.model” para a propriedade setPackagesToScan do componente LocalSessionFactoryBean e configuramos a propriedade dialect do componente SessionFactory usando o método setHibernateProperties para indicar qual tipo de banco de dados temos com importa na aplicação.
Agora, depois de configurar o componente SessionFactory Hibernate, no contexto do aplicativo Spring, vamos ver como podemos implementar objetos de acesso a dados para o nível de salvamento de nosso aplicativo.
Sobre o autor
Dinesh Rajput é editor chefe do site Dineshonjava, um blog técnico dedicado às tecnologias Java e Spring. O site contém artigos sobre a tecnologia Java. Dinesh é um blogueiro, autor de livros, desde 2008 um entusiasta da primavera, um especialista certificado da Pivotal (Pivotal Certified Spring Professional). Ele tem mais de uma década de experiência em design e desenvolvimento usando Java e Spring. Ele é especialista em trabalhar com a versão mais recente do Spring Framework, Spring Boot, Spring Security, criando uma API REST, arquitetura de microsserviço, programação reativa, programação orientada a aspectos usando Spring, padrões de design, Struts, Hibernate, serviços da web, Spring Batch, Cassandra, MongoDB, uma arquitetura de aplicativos da web.
Atualmente, Dinesh está trabalhando como gerente de tecnologia em uma das empresas líderes no campo de desenvolvimento de software. Ele foi o desenvolvedor e líder de equipe da Bennett, Coleman & Co. Ltd e, antes disso, um desenvolvedor líder da Paytm. Dinesh está entusiasmado com as mais recentes tecnologias Java e gosta de escrever sobre elas em blogs técnicos. Ele é um membro ativo das comunidades Java e Spring em vários fóruns. Dinesh é um dos melhores especialistas em Java e Spring.
Sobre o Revisor
Rajiv Kumar Mohan tem uma vasta experiência em desenvolvimento de software e treinamento corporativo. Por 18 anos, ele trabalhou para grandes empresas de TI como IBM, Pentasoft, Sapient e Deft Infosystems. Ele começou sua carreira como programador, liderou muitos projetos.
Ele é especialista na área de assunto de Java, J2EE e estruturas relacionadas, Android, tecnologias de interface do usuário. Certificado pela Sun como programador Java (SCJP, programador certificado Sun da Java) e desenvolvedor web Java (desenvolvedor certificado pela Sun Web Component, SCWCD). Rajiv possui quatro cursos superiores: no campo da ciência da computação (ciência da computação), ciência da computação aplicada (aplicações de computador), química orgânica e administração de empresas (MBA). Ele é consultor de recrutamento e especialista em treinamento na HCL, Amdocs, Steria, TCS, Wipro, Oracle University, IBM, CSC, Genpact, Sapient Infosys e Capgemini.
Rajeev é o fundador da SNS Infotech, localizada na cidade da Grande Noida. Além disso, ele trabalhou no Instituto Nacional de Tecnologia da Moda (NIFT).
»Mais informações sobre o livro podem ser encontradas no
site do editor»
Conteúdo»
Trecho20% de desconto no cupom para vendedores ambulantes -
Primavera