Vamos discutir alguns padrões em relação a base de um projeto com JPA?

This message was edited 1 time. Last update was at 28/05/2009 12:06:14

A minha idéia com relação a este tópico é distribuir informações de padrões de implementação para lógica de negócio e dados, especificamente JPA e seus padrões. O padrão que adotei aqui não é o mais correto ou menos correto, é apenas um padrão, e como eu falei, a importância é discutir várias formas diferentes de implementações a fim de melhorar técnicas e padrões e também difundir conhecimento.

:: Criação de APIs

Para distribuir o JPA entre as aplicações, criamos uma API que servirá como base para qualquer projeto poder estender e usar suas funcionalidades, a priore essa API entrega:

- Estrutura de classes de exceção para a aplicação.
- Estrutura de login para as aplicações (para tier de negócio).
- Estrutura de acesso a uma abstração de JPA única
- Estrutura de classes de negócio básica

Distribuíndo essa lib, a aplicação terá o suporte básico para inciar um projeto de camada de négocio e dados.

O projeto final será o resultado de 3 outros projetos. Um ou dois para apresentação (WEB ou Swing e REL) e um para négocio.

Por exemplo, o nome do meu projeto fictício é Sistema de Controle Externo (SCE), ele irá constituir de:

- SCE_API.jar
- SCE_REL.jar

e

Se for Swing:
- SCE_SWING.jar
Se for Web:
- SCE_WEB.war

Dessa forma componentizada, permite melhor reaproveitamento do código, se eu desenvolver incialmente para Swing, poderei migrar para web de forma mais rápida e com menos problemas, já que a estrutura de negócio estará contida em um .jar isolado da apresentação.

Das classes representantes:

:: A estrutura do modelo para JPA utilizada:

Existe uma interface e uma classe abstrata para a JPA:

- JPAUtil (interface)
- JPAUtilBase (classe)

Para a Interface temos:

public final static String PU_ONLINE="ONLINE";
    
    public final static String PU_OFFLINE="OFFLINE";
    
    public void setOnline(Boolean pOnLine);
    
    public Boolean isOnline();
       
    public void close();

public void commitTran();

public List executarQuery(String pQuery, Map pParametros);

public List executarNamedQuery(String pQueryName, Map pParametros);

public List executarNativeQuery(String pQuery, Map pParametros, Class pEntidade);
    
    public List executarNativeQuery(String pQuery, Map pParametros);

public void executarNativeUpdate(String pUpdateCommand);

public void executarUpdate(String pUpdateCommand);

public ModelGeral find(Class pClasseEntidade, Long pId) throws RegistroNaoEncontradoException;

public void flush();

public EntityManager getEntityManager();

public ModelGeral reference(Class pClasseEntidade, Long pId) throws RegistroNaoEncontradoException;

public List obterTodos(Class pClasseEntidade, int pOffset, int pQtde);

public ModelGeral persist(ModelGeral pEntidade);

public ModelGeral refresh(ModelGeral pEntidade)throws RegistroNaoEncontradoException;

public void remove(ModelGeral pEntidade) throws RegistroNaoEncontradoException, RegistroDependenteException;

public void rollbackTran();
    
    public void closeEMF();

NOTA:

- O 'ModelGeral' é uma classe abstrata que estabelece um model primário para qualquer entidade de qualquer projeto. Voltando ao exemplo do SCE, se eu for criar uma entidade no projeto SCE, crio antes uma abstração que estender de ModelGeral que se chamara ModelSCE, que todas as entidades desse projeto passarão a ser uma ModelSCE que por sua vez é uma ModelGeral.
- As exceções checked criadas são as de NegocioExcepion, AmbienteException e SegurancaException, dessas a NegocioException tem suas especializacoes em RegistroDependenteException, RegistroNaoEncontradoException, etc.

A JPAUtilBase irá implementar vários desses métodos especificados na interface, porém alguns deverão ser implementados para cada projeto, eles são:

# getEntityManagerFactory
# getPUMap
# getPUName

Como a lógico de acesso ao banco de dados colocamos em um outro jar isolado, então é obrigatório a implementação do PUMaps que será um HashMap de algumas propriedades do hibernate-jpa como a exemplo o pool de conexão da aplicação considerada e dados de acesso ao banco como URL, username e pasword.

Mais informações eu poderei detalhar, por enquanto dá para se ter uma base de como os projetos são feitos aqui, poderiamos discutir maneiras diferentes, aprimorar e comentar os padrões aqui adotados.

Olá
É complicado chegar a um consenso nesse tipo de discussão, pois você está falando de uma arquitetura muito específica que serve pra vocês mas pode não servir pra nós. Mas podemos discutir alguns aspectos técnicos:

1) Por que não usar enums no lugar das constantes PU_ONLINE e PU_OFFLINE?
2) Não pude deixar de reparar a falta de uso de generics também.
3) Há controvérsias se o atrelamento das classes de negócio a uma classe abstrata - nesse caso, ModelGeral - é uma boa prática. E além disso, pra cada projeto ainda será criada uma abstração extra que herda de ModelGeral? O que vocês ganham com isso?
4) Não seria preferível utilizar exceções não checadas? Senão os desenvolvedores que utilizarem o framework vão acabar colocando throws em todos os métodos com código passível de lançamento dessas exceções.
5) A presença dos métodos getEntityManagerFactory(), getPUMap() e getPUName() da forma que você colocou sugere a adoção de configuração programática. Por que vocês decidiram não deixar os dados no persistence.xml?

Abraços

Olá tnaires

Tnaires wrote:
1) Por que não usar enums no lugar das constantes PU_ONLINE e PU_OFFLINE?
2) Não pude deixar de reparar a falta de uso de generics também.
3) Há controvérsias se o atrelamento das classes de negócio a uma classe abstrata - nesse caso, ModelGeral - é uma boa prática. E além disso, pra cada projeto ainda será criada uma abstração extra que herda de ModelGeral? O que vocês ganham com isso?
4) Não seria preferível utilizar exceções não checadas? Senão os desenvolvedores que utilizarem o framework vão acabar colocando throws em todos os métodos com código passível de lançamento dessas exceções.
5) A presença dos métodos getEntityManagerFactory(), getPUMap() e getPUName() da forma que você colocou sugere a adoção de configuração programática. Por que vocês decidiram não deixar os dados no persistence.xml?

1 - Verdade, algumas coisas deixamos em Enum outras em constantes clássicas mesmo.

2 - Usamos sim, para passar a entidade corrente das classes de negócio para o JPAUtilBase, etc.

3 - Também achei, na verdade não conseguimos achar uma outra solução para a questão, mas dessa forma atende perfeitamente. Por que algumas regras excluivas para aquele projeto pode ser tratado direntamente nessa abstração extrar, outro exemplo? O uso de um listener próprio para entidades desse projeto.

4 - Existem algumas exceções básicas criadas, os métodos que irão tratar de persistência em negócio quase sempre levantam essas exceções para a camada de apresentar para refletir na apresentação para o usuário. Mas o esquema feito para elas não está 100% do jeito que deveria ser, mas até que atende, depois mostrarei mais detalhes dessa implementação.

5 - Por questão de segurança, no início até que ficavam no persistence.xml, mas na medida que leva-se para a produção, um jar extar cotnendo essas informações criptografadas se torna necessário, então o usuário, senha e como se conectar ao banco ficam em outro elemento.

Gostei muito de seu questionamento, também se tiver alguma outra ressalta, sugestão ou crítica pode mandar

Grinvon wrote:2 - Usamos sim, para passar a entidade corrente das classes de negócio para o JPAUtilBase, etc.

Sei... Eu me referi aos métodos de execução de queries que retornam e recebem "raw types", como List e Map. Porém, sei que isso é um pouco complicado pois as próprias classes do Hibernate/JPA não são genéricas.

No mais, acho que se você postasse um pequeno exemplo de CRUD usando a sua proposta enriqueceria muito a discussão.

Abraços.

Por acaso isso é para servir de Arquitetura de Referência para sua empresa?!?!?!?!

Be careful ...

Notícias, artigos e o maior fórum brasileiro sobre Java