Vamos compartilhar arquiteturas de aplicações web baseadas em Java!

existem muitas arquiteturas diferentes para aplicações web que devem ser implementadas usando Java. As respostas a esta pergunta podem servir como uma biblioteca de vários projetos de aplicações web com seus prós e contras. Embora eu perceba que as respostas serão subjetivas, vamos tentar ser o mais objetivas possível e motivar os prós e contras que listamos.

Use o nível de detalhe que prefere para a descrever a tua arquitectura. Para que a sua resposta seja de qualquer valor, terá pelo menos de descrever as principais tecnologias e ideias utilizadas na arquitectura que descreve. E por último, mas não menos importante, Quando devemos usar a tua arquitectura?

panorâmica da arquitectura

• persistência
• Negócios
• apresentação

os possíveis fluxos de comunicação entre as camadas são representados por:

Persistence <-> Business <-> Presentation

persistência

executa criar, ler, actualizar e apagar (CRUD) operações de persistência. No nosso caso, estamos a usar a JPA (Java Persistence API ) e usamos actualmente Hibernate como nosso fornecedor de persistência e usamos o seu 'EntityManager' .

Esta camada é dividida em várias classes, onde cada classe lida com um certo tipo de entidades (i.e. entidades relacionadas a um carrinho de compras poderá obter manipulado por uma única classe de persistência) e usada por uma e apenas uma gerente .

além disso, esta camada também armazena entidades da APP que são coisas como Account, ShoppingCart etc.

Negócios

toda a lógica que está ligada à funcionalidade da aplicação web está localizada nesta camada. Esta funcionalidade pode ser iniciar uma transferência de dinheiro para um cliente que quer pagar por um produto on-line usando seu cartão de crédito. Pode muito bem ser a criação de um novo utilizador, a exclusão de um utilizador ou o cálculo do resultado de uma batalha em um jogo baseado na web.

Esta camada é dividida em várias classes, e cada uma destas classes é anotada com @Stateless para se tornar um Stateless Session Bean (SLSB). Cada SLSB é chamado de um manager e, por exemplo, um manager pode ser uma classe anotada como mencionado chamado AccountManager.

Quando AccountManager Precisa de realizar operações CRUD faz as chamadas apropriadas para uma instância de AccountManagerPersistence, que é uma classe na camada de persistência. Um esboço de dois métodos em AccountManager pode ser:

...
public void makeExpiredAccountsInactive() {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    // Calls persistence layer
    List<Account> expiredAccounts = amp.getAllExpiredAccounts();
    for(Account account : expiredAccounts) {
        this.makeAccountInactive(account)
    }
}
public void makeAccountInactive(Account account) {
    AccountManagerPersistence amp = new AccountManagerPersistence(...)
    account.deactivate();
    amp.storeUpdatedAccount(account); // Calls persistence layer
}

usa-se recipiente gerenciador de transações então, nós não temos de fazer a demarcação da transação nosso self. O que basicamente acontece sob o capô está a iniciar uma transação quando entrar o SLSB método e cometê-lo (ou reversão-lo) imediatamente antes de sair do método. É um exemplo de Convenção sobre configuração, mas não tivemos necessidade de nada além do padrão, exigido, ainda.

Se o cliente estiver a correr dentro de um transacção e invoca a empresa método do bean, o método executa dentro da transacção do cliente. Se o cliente não está associado a transacção, o contentor inicia um Nova transacção antes de executar a metodo.

o atributo requerido é o implícito atributo da transacção para todos métodos de feijão da empresa em execução com transacção gerida por contentores demarcacao. Você normalmente não define o atributo requerido a menos que precise para substituir outra transacção atributo. Porque a transacção os atributos são declarativos, você pode muda - os facilmente mais tarde.

apresentação

Os Métodos de chamadas de camada emgestores da camada de negócio para realizar as operações solicitadas pelo utilizador e para receber informações a mostrar na página web. Por vezes, as informações recebidas da camada de negócio são tipos menos complexos como String's e integers, e noutras vezes entidades da APP.

prós

Ter tudo relacionado com uma forma específica de fazer persistência nesta camada só significa que podemos trocar de usar a APP por outra coisa, sem ter que reescrever nada na camada de Negócio. É fácil para nós trocar a nossa camada de apresentação em outra coisa, e é provável que o façamos se encontrarmos algo melhor. Deixar o contentor da EJB gerir os limites da transacção é bom.
• usando Servlet's + JPA é fácil (para começar) e as tecnologias são amplamente utilizadas e implementadas em muitos servidores.
• utilizar Java EE é suposto tornar mais fácil para nós criar um sistema de alta disponibilidade comequilíbrio de carga efalha acima de . Ambos achamos que devemos ter.

conts

• usando o JPA, poderá armazenar as consultas usadas com frequência, tal como as chamadas consultas, usando a anotação @NamedQuery na classe de entidades JPA. Se você tem tanto quanto possível relacionado para a persistência nas aulas de persistência, como em nossa arquitetura, isso irá espalhar os locais onde você pode encontrar consultas para incluir as entidades da App também. Será mais difícil de visualizar as operações de persistência e, portanto, mais difícil de manter.
Temos entidades da APP como parte da nossa camada de persistência. Mas não são realmente objectos de negócios? É feito desta forma, pois você tem que tocar essas classes e transformá-las em Entidades que a APP sabe como manipular.
• as entidades da APP, que são também os nossos objectos de negócio, são criadas como objectos de transferência de dados (DTO's), também conhecidos como objectos de valor (VO's). Isso resulta em um modelo de domínio anêmico como os objetos de negócio não têm lógica própria, exceto métodos de accessor. Toda a lógica é feita por nossos gerentes na camada de negócios, o que resulta em um estilo de programação mais processual. Não é um bom design orientado a objetos, mas talvez isso não seja um problema? (Afinal de contas objecto a orientação não é o único paradigma de programação que produziu resultados.)
O uso de EJB e Java EE introduz um pouco de complexidade. E não podemos usar puramente Tomcat (adicionar um micro-container da EJB não é [[24]}puramente Tomcat).
• há muitos problemas com o uso de Servlet + JPA. Use o Google para obter mais informações sobre estes problemas.
Como as transacções são encerradas ao sair da camada de negócio, não podemos carregar qualquer informação das entidades da APP que é configurado para ser carregado a partir da base de dados quando necessário (usando fetch=FetchType.LAZY) a partir do interior da camada de apresentação. Vai despoletar uma excepção. Antes de devolver uma Entidade contendo estes tipos de campos, temos de ter a certeza de ligar para o getter relevante. outra opção é usar a linguagem Java Persistence Query Language (JPQL) e fazer um FETCH JOIN. No entanto, ambas as opções são um pouco pesadas.