Como modelar em Java EE?

Question

Digamos que decidi usar a pilha Java EE para meu aplicativo corporativo.

Agora, para modelagem de domínio (ou:para projetar o M do MVC), quais APIs posso assumir e usar com segurança e quais devo evitar...digamos, através de uma camada de abstração?

Por exemplo,

1. Devo prosseguir e encher meu modelo com chamadas para a API Hibernate/JPA?Ou devo construir uma abstração ...uma camada de persistência própria para evitar a codificação dessas duas APIs de persistência específicas? Por que pergunto isso: Alguns anos atrás, existia esta API Kodo que foi substituída pelo Hibernate.Se alguém tivesse projetado uma camada de persistência e codificado o restante do modelo nessa camada (em vez de sobrecarregar o modelo com chamadas para API de fornecedor específico), isso teria permitido mudar (relativamente) facilmente de Kodo para Hibernate para xyz.

2. É recomendado fazer uso agressivo do *QL fornecido pelo seu fornecedor de persistência no seu modelo de domínio?Não estou ciente de quaisquer problemas do mundo real (como desempenho, escalabilidade, portabilidade, etc.) decorrentes do uso intenso de uma linguagem semelhante a HQL. Por que pergunto isso: Gostaria de evitar, tanto quanto possível, escrever código customizado quando o mesmo pudesse ser feito por meio de uma linguagem de consulta mais portátil que SQL.

Desculpe, mas sou um completo novato nesta área.Onde posso encontrar mais informações sobre este assunto?

Answer 1

Aqui está o que acredito ser a visão tradicional:

• As entidades do seu projeto formam o modelo de domínio.Eles devem ser reutilizáveis ​​e não fortemente acoplados a uma tecnologia de persistência (voltarei mais tarde sobre tight vs.acoplamento solto)
• A camada de negócios usa o modelo de domínio, mas também expõe serviços e outras coisas.
• A camada de acesso a dados é responsável por persistir o modelo de domínio (entidades) em um armazenamento persistente.

Uma entidade não deve chamar diretamente a camada de acesso a dados.Mas a camada de negócios irá, de certa forma, carregar e persistir entidades do modelo de domínio.

Se você mapear isso para tecnologias Java EE, normalmente obterá algo como:

• Entidades -> POJO com anotações Hibernate/JPA.Observe que as anotações não implicam um acoplamento forte com JPA/Hibernate, o mesmo POJO poderia ser usado em outro lugar sem o Hibernate.
• Camada de negócios -> Sessão EJB ou Spring
• Camada de acesso a dados -> JPA/Hibernate

Esse é um esboço e há muitas variantes possíveis.Você pode pular a sessão EJB e implementar a camada de negócios de outra maneira.Você também pode decidir fazer com que a camada de negócios chame o JPA/Hibernate Session/EntityManager diretamente, caso em que JPA/Hibernate é realmente o DAL, ou você pode querer agrupar o acesso do Session/EntityManager nos chamados Data Access Objects (DAO). ).

Em relação ao HQL, tente manter o que é portátil e, se você usar SQL nativo, siga as convenções do SQL-92.Se as coisas ficarem complicadas, talvez introduza DAOs.Dessa forma, você sabe que o único lugar onde existem consultas HQL é nos DAOs.Você também pode primeiro implementar a lógica de consulta "proceduralmente" no DAO e, se tiver problemas de desempenho, reimplementá-la com uma consulta HQL mais complicada.

EDITAR

Em relação às suas perguntas no comentário:

A camada de negócios depende da camada de dados.Se você deseja que a camada de negócios não dependa do Hibernate/JPA, então sua camada de dados precisa abstrato Hibernar/JPA fora.Se você usar DAO para sua camada de dados, esse será o caso.O DAO será a "fina camada de persistência escrita à mão sobre o Hibernate" (para usar suas palavras).Eu apresentaria o DAO para todas as entidades no seu caso.

O que você está perguntando é uma questão de design bastante genérica.Não posso dar uma receita definitiva para isso, nem possivelmente resumir todas as variantes numa única resposta, pois depende de caso a caso.Por exemplo, não falamos até agora sobre o problema das transações, que normalmente você inicia na camada de negócios, mas que a camada de dados deve estar atenta.Isso normalmente depende das tecnologias usadas e dos seus requisitos.

Ainda assim, aqui está uma lista de recursos nos quais você pode estar interessado:os livros Padrão de arquitetura de aplicativos empresariais, o livro Padrões Java EE do mundo real - repensando as melhores práticas, o livro Design baseado em domínio e mais especificamente os padrões Objeto de acesso a dados, Padrão de repositório, Abrir sessão na visualização (se for para um aplicativo da web) e talvez Modelo de Domínio Anêmico.

EDITAR 2

Ok, mais algumas frases sobre transações:

As transações devem ser gerenciadas conceitualmente na camada de negócios;a definição do que precisa ser feito em uma unidade de trabalho para ser consistente depende, na verdade, da própria lógica da aplicação.

Com o EJB3, as transações podem ser declaradas com anotações e pelo aplicativo.servidor gerencia isso para você.Ver esta outra resposta meu para mais informações.Com o Spring você também pode marcar as transações de forma declarativa, mas não sei os detalhes.Caso contrário, você mesmo precisará iniciar/interromper a transação.Isso será um pouco diferente se você usar transações JDBC ou transações JTA.

As transações também estão relacionadas ao carregamento lento no Hibernate/JPA.Uma entidade que foi carregada lentamente só pode ser carregada se houver uma transação atual.Se as transações forem encerradas na camada de negócios, as entidades que retornarem à camada de apresentação precisarão ser carregadas avidamente.

Para contornar esse problema, um padrão popular para aplicações web é Abrir sessão na visualização, que já mencionei.Nesse caso, a camada de apresentação inicia/para as transações (o que é um pouco errado conceitualmente), mas funciona bem com carregamento lento.

Answer 2

Seu modelo de domínio e sua camada de persistência devem, em teoria, ser separados - não há necessidade de uma aula chamada Entity Saber algo sobre se e como é persistido, para que você possa usar algo como Hibernate para criar a camada de persistência sem poluir as próprias classes de modelos de domínio. Você não "codifica o modelo [...] contra essa camada" - codifica o modelo e o mapeia em um armazenamento persistente com algum tipo de camada ORM, onde o modelo de domínio não depende da camada ORM. Obviamente, a camada de persistência dependerá do modelo de domínio, mas tudo bem.

Pessoalmente, luto a menos de usar muito HQL com (n) hibernado pelo motivo que você pergunta, mas há momentos em que é inevitável. Você já sabe e se destacou, a questão principal lá, então é improvável que você use demais isso de qualquer maneira.