Condividiamo le architetture di applicazioni web basate su Java!

Ci sono molte architetture diverse per le applicazioni web che devono essere implementate usando Java. Le risposte a questa domanda possono servire come una libreria di vari progetti di applicazioni web con i loro pro e contro. Mentre mi rendo conto che le risposte saranno soggettive, cerchiamo di essere il più obiettivo possibile e motivare i pro ei contro che elenchiamo.

Usa il livello di dettaglio che preferisci per descrivere la tua architettura. Affinché la tua risposta sia di qualsiasi valore dovrai almeno descrivere le principali tecnologie e idee utilizzate nell'architettura che descrivi. E, ultimo ma non meno importante, quando dovremmo usare la tua architettura?

Inizierò...

Panoramica dell'architettura

Utilizziamo un'architettura a 3 livelli basata su standard aperti di Sun come Java EE, Java Persistence API, Servlet e Java Server Pagina.

• Persistenza
• Affari
• Presentazione

I possibili flussi di comunicazione tra i livelli sono rappresentati da:

Persistence <-> Business <-> Presentation

Che ad esempio significa che il livello di presentazione non chiama mai o esegue operazioni di persistenza, lo fa sempre attraverso il livello aziendale. Questa architettura è pensata per soddisfare le esigenze di un'applicazione Web ad alta disponibilità.

Persistenza

Esegue la creazione, la lettura, aggiornamento ed eliminazione ( CRUD ) operazioni di persistenza. Nel nostro caso stiamo usando ( Java Persistence API ) JPA e attualmente usiamo Hibernate come fornitore di persistenza e usiamo il suo EntityManager.

Questo livello è diviso in più classi, in cui ogni classe si occupa di un determinato tipo di entità (cioè le entità relative a un carrello possono essere gestite da una singola classe di persistenza) ed è utilizzato da uno e solo uno gestore .

Inoltre questo livello memorizza anche entità JPA che sono cose come Account, ShoppingCart ecc.

Affari

Tutta la logica legata alla funzionalità dell'applicazione Web si trova in questo livello. Questa funzionalità potrebbe essere l'avvio di un trasferimento di denaro per un cliente che vuole pagare per un prodotto on-line utilizzando la sua carta di credito. Potrebbe anche essere la creazione di un nuovo utente, l'eliminazione di un utente o il calcolo dell'esito di una battaglia in un gioco basato sul web.

Questo livello è diviso in più classi e ciascuna di queste classi è annotata con @Statelessper diventare un bean di sessione Stateless (SLSB). Ogni SLSB è chiamato manager e ad esempio un manager potrebbe essere una classe annotata come detto chiamata AccountManager.

Quando AccountManager deve eseguire operazioni CRUD, effettua le chiamate appropriate a un'istanza di AccountManagerPersistence, che è una classe nel livello di persistenza. Uno schizzo approssimativo di due metodi in AccountManager potrebbe essere:

...
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
}

Usiamo transazioni di container manager quindi non dobbiamo fare la demarcazione delle transazioni da soli. Quello che succede fondamentalmente sotto il cofano è che iniziamo una transazione quando entriamo nel metodo SLSB e la commit (o rollback) immediatamente prima di uscire dal metodo. È un esempio di convenzione sulla configurazione, ma non abbiamo ancora avuto bisogno di altro che di default, Richiesto.

Ecco come il tutorial Java EE 5 di Sun spiega il Attributo di transazione richiesto per JavaBeans Enterprise (EJB):

Se il client è in esecuzione all'interno di un transazione e richiama l'impresa metodo di bean, il metodo viene eseguito all'interno della transazione del cliente. Se il client non è associato a transazione, il contenitore avvia un nuova transazione prima di eseguire il metodo.

L'attributo Richiesto è l'implicito attributo transazione per tutti metodi bean aziendali in esecuzione con transazione gestita dal contenitore demarcazione. In genere non si imposta l'attributo richiesto a meno che non sia necessario per sovrascrivere un'altra transazione attributo. Perché transazione gli attributi sono dichiarativi, puoi facilmente cambiarli in seguito.

Presentazione

Il nostro livello di presentazione è responsabile... presentazione! È responsabile dell'interfaccia utente e mostra le informazioni all'utente creando pagine HTML e ricevendo l'input dell'utente tramite GET e POST richiesta. Attualmente stiamo utilizzando la vecchia combinazione Servlet + Java Server Pages ( JSP ).

Il livello chiama i metodi in manager del livello aziendale per eseguire le operazioni richieste dall'utente e per ricevere informazioni da mostrare nella pagina web. A volte le informazioni ricevute dal livello aziendale sono tipi meno complessi come Stringe integer, e altre volte entità JPA .

Pro e contro con il architettura

Pro

• Avere tutto ciò che riguarda un modo specifico di fare persistenza in questo livello significa solo che possiamo passare dall'uso di JPA a qualcos'altro, senza dover riscrivere nulla nel livello aziendale.
• È facile per noi scambiare il nostro livello di presentazione in qualcos'altro, ed è probabile che lo faremo se troviamo qualcosa di meglio.
• Lasciare che il contenitore EJB gestisca i limiti delle transazioni è bello.
• Utilizzo di Servlet + JPA è facile (per cominciare) e le tecnologie sono ampiamente utilizzate e implementate in molti server.
• L'utilizzo di Java EE dovrebbe facilitare la creazione di un sistema ad alta disponibilità con bilanciamento del carico e failover . Entrambi i quali sentiamo che dobbiamo avere.

Contro

• Utilizzando JPA è possibile memorizzare le query utilizzate spesso come query denominate utilizzando l'annotazione @NamedQuery nella classe di entità JPA. Se hai il più possibile correlato per la persistenza nelle classi di persistenza, come nella nostra architettura, questo distribuirà le posizioni in cui è possibile trovare query per includere anche le entità JPA. Sarà più difficile per le operazioni di persistenza panoramica e quindi più difficile da mantenere.
• Abbiamo entità JPA come parte del nostro livello di persistenza. Ma Account e ShoppingCart, non sono davvero oggetti di business? È fatto in questo modo poiché devi toccare queste classi e trasformarle in entità che JPA sa come gestire.
• Le entità JPA, che sono anche i nostri business objects, vengono create come Oggetti di trasferimento dati ( DTO), noti anche come Oggetti di valore (VO). Ciò si traduce in un modello di dominio anemico poiché gli oggetti di business non hanno logica propria tranne i metodi di accesso. Tutta la logica viene eseguita dai nostri manager nel livello aziendale, il che si traduce in uno stile di programmazione più procedurale. Non è un buon design orientato agli oggetti, ma forse non è un problema? (Dopo tutto l'oggetto l'orientamento non è l'unico paradigma di programmazione che ha dato risultati.)
• L'utilizzo di EJB e Java EE introduce un po ' di complessità. E non possiamo usare puramente Tomcat (aggiungere un micro-contenitore EJB non è puramente Tomcat).
• Ci sono molti problemi con l'utilizzo di Servlet + JPA. Utilizzare Google per ulteriori informazioni su questi problemi.
• Poiché le transazioni vengono chiuse quando si esce dal livello aziendale, non è possibile caricare alcuna informazione dalle entità JPA che configurato per essere caricato dal database quando è necessario (usando fetch=FetchType.LAZY) dall'interno del livello di presentazione. Attiverà un'eccezione. Prima di restituire un'entità contenente questi tipi di campi, dobbiamo essere sicuri di chiamare i getter pertinenti. Un'altra opzione è usare Java Persistence Query Language (JPQL) e fare un FETCH JOIN. Tuttavia entrambe queste opzioni sono un po ' ingombranti.