I modelli di progettazione creano app J2EE migliori

Sin dal suo inizio, J2EE (Java 2 Platform, Enterprise Edition) ha semplificato la costruzione di applicazioni aziendali in Java. Con l'adozione sempre più ampia di J2EE, tuttavia, gli sviluppatori stanno realizzando la necessità di approcci definiti che semplificano e standardizzano la creazione di applicazioni. Puoi iniziare a raggiungere questo obiettivo standardizzando il livello architettonico della tua applicazione .

Il livello architettonico generalmente incapsula le complessità tecniche di un'applicazione indipendentemente dalla logica aziendale, fornendo così un accoppiamento libero tra la funzionalità aziendale e l'infrastruttura tecnica sottostante. In questo articolo, spiego un metodo emergente per creare l'architettura dell'applicazione per i progetti J2EE, uno che utilizza modelli di progettazione per fornire la standardizzazione e la semplicità richieste da una buona architettura.

Architettura dell'applicazione e J2EE

J2EE è una grande tecnologia di infrastruttura. Fornisce uno standard uniforme per le attività di livello inferiore dello stack tecnologico, come la comunicazione del database o la distribuzione dell'applicazione. J2EE, tuttavia, non porta gli sviluppatori a creare applicazioni di successo. I creatori di J2EE, esaminando lo stack tecnologico, si sono chiesti: "Come possiamo standardizzare queste API?" Avrebbero dovuto guardare gli sviluppatori delle applicazioni e chiedere: "Come posso fornire agli sviluppatori gli elementi costitutivi di cui hanno bisogno per concentrarsi sulla loro applicazione aziendale?"

Quando si inizia un nuovo progetto J2EE, alcuni membri del team spesso chiedono: "Se J2EE è esso stesso un'architettura, perché ne abbiamo bisogno di più?" Molti sviluppatori ritenevano questo malinteso agli albori di J2EE, ma gli sviluppatori J2EE esperti capiscono che J2EE non riesce a fornire l'architettura applicativa necessaria per fornire costantemente applicazioni di alta qualità. Questi sviluppatori utilizzano spesso modelli di progettazione per colmare questa lacuna.

Modelli di progettazione

Nella programmazione, i modelli di progettazione consentono di sfruttare l'esperienza collettiva della comunità di sviluppatori condividendo problemi e soluzioni a vantaggio di tutti. Un modello di progettazione deve catturare la definizione e il contesto di un problema, una possibile soluzione e le conseguenze della soluzione.

Ai fini dell'architettura dell'applicazione J2EE, i modelli di progettazione rientrano in due categorie: modelli generali di sviluppo software e quei modelli che identificano specifiche sfide J2EE. I modelli di progettazione specifici di J2EE identificano il set minimo di problemi noti che una solida architettura applicativa dovrebbe risolvere. Il primo gruppo, quello dei modelli di sviluppo software non specifici per J2EE, si dimostra ugualmente potente, non per identificare i problemi, ma per guidare la costruzione dell'architettura.

Esaminiamo ogni area in modo più dettagliato.

Modelli di design J2EE

I modelli di progettazione J2EE si sono evoluti negli ultimi anni man mano che la comunità Java ha acquisito esperienza J2EE. Questi modelli di progettazione identificano i potenziali problemi riscontrati durante l'utilizzo delle varie tecnologie specificate da J2EE e aiutano gli sviluppatori a costruire i requisiti dell'architettura dell'applicazione. Il popolare modello di progettazione del Front Controller, ad esempio, trasforma il codice servlet non strutturato in un controller che ricorda lo sviluppo raffinato della GUI (interfaccia utente grafica).

I modelli di progettazione J2EE identificano i problemi di dominio che con maggiore probabilità compaiono nei progetti J2EE. In effetti, se i problemi fossero stati rari, i modelli di progettazione non si sarebbero evoluti per soddisfarli. Con questo in mente, trarrai vantaggio dall'affrontare ogni problema di dominio nella tua architettura. Per risolverli tutti, crea un elenco di controllo per convalidare la completezza della tua architettura. Questo processo è in contrasto con il processo per i modelli di progettazione dello sviluppo software di cui parlerò in seguito, poiché è necessario applicare quei modelli solo quando e se appropriato.

Allora, dove trovi i design pattern J2EE? Sun Microsystems offre due libri che contengono molti pattern J2EE:

  • Progettazione di applicazioni aziendali con la piattaforma Java 2 (Enterprise Edition) del gruppo J2EE BluePrint , Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
  • Core J2EE Patterns del Sun Professional Services Group : Best Practices and Design Strategies, Deepak Alur, John Crupi e Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Vedi Risorse per i collegamenti a entrambi i libri.)

Oltre alle risorse di Sun, altre pubblicazioni offrono informazioni sui modelli di progettazione J2EE, comprese varie riviste o siti Web del settore Java (come JavaWorld ), oltre a numerosi libri. (Vedi Risorse per link ad alcuni di questi siti, tra cui JavaWorld' s Design Patterns pagina Indice topica.)

Modelli di progettazione di sviluppo software

Inoltre, essere consapevoli dei modelli di progettazione dello sviluppo software, suddivisi in modelli di progettazione orientati agli oggetti (OO) generali e modelli di progettazione specifici di Java. Il modello Factory, ad esempio, rappresenta un potente modello di progettazione OO per incapsulare la creazione di oggetti per consentire il riutilizzo e soddisfare i requisiti in evoluzione di un sistema. Da parte loro, i modelli di progettazione del linguaggio Java tengono conto delle specifiche del linguaggio Java. Alcuni sono esclusivi di Java e di solito sono informali (ad esempio, eccezioni e primitive), mentre altri sono modelli OO perfezionati da applicare a Java. Il famoso libro Gang of Four, Design Patterns di Eric Gamma et al., Descrive in dettaglio numerosi modelli generali di sviluppo software utili a tutti i programmatori.

Non ignorare questi pattern semplicemente perché non sono specifici di J2EE. Al contrario, tali pattern possono dimostrarsi altrettanto potenti, se non di più, dei design pattern J2EE, perché:

  • Mentre i modelli di progettazione J2EE sono nuovi e in evoluzione (perché J2EE è nuovo e in evoluzione), gli altri modelli traggono vantaggio dall'età, poiché l'industria ha avuto più tempo per rivederli e perfezionarli.
  • Spesso servono come base da cui derivano i design pattern J2EE.
  • Costruiscono le basi su cui vengono implementate le soluzioni specifiche J2EE. La costruzione corretta di questa base influisce ampiamente sulla robustezza e sull'estensibilità dell'intera architettura. Se non costruita correttamente, la base ridurrebbe al minimo l'utilità dell'architettura indipendentemente dal numero di problemi J2EE che risolve.

Non fare una lista di controllo che copra i modelli di sviluppo software richiesti dalla tua architettura, come faresti con i modelli J2EE. Utilizza invece tali modelli, ove appropriato, in base alle sfide specifiche del tuo progetto. Molti sviluppatori credono erroneamente che i loro prodotti miglioreranno se utilizzeranno più modelli o se li utilizzeranno tutti! Tuttavia, non è così. Usa discrezione e finezza quando decidi quali modelli utilizzare e come usarli insieme.

Pattern di progettazione: dov'è il codice?

Tieni presente che i modelli di progettazione non vengono forniti con l'implementazione esatta o il codice sorgente che utilizzerai. Le offerte di modelli di progettazione vanno da descrizioni testuali sparse a una ricca documentazione fino a possibilmente qualche codice di esempio. La sfida sta nell'applicare le potenti idee dei modelli. Queste idee devono essere applicate all'ambiente in cui verranno utilizzate; l'ambiente definisce la corretta implementazione.

Come analogia, considera un modello di progettazione per costruire le fondamenta di una casa. Il modello di progettazione identifica il problema, il contesto e la possibile soluzione per costruire le fondamenta: informazioni immensamente preziose per l'operaio edile sul campo. Il lavoratore, tuttavia, deve ancora costruire le fondamenta. Quell'operaio edile non trarrebbe più vantaggio dall'assegnazione delle basi (simile allo sviluppatore del software a cui viene data l'implementazione)? Forse questa fondazione sarebbe solo una lastra di cemento su cui costruire la casa. Il problema: la fondazione deve integrarsi con la casa stessa e con il terreno in cui risiederà la casa. Come può una tale fondazione precostruita ospitare tutte le possibili planimetrie di una casa (rettangolo, quadrato e altre forme dispari) e tutti i possibili paesaggi (in cima a una collina,nel mezzo di una foresta, e così via)?

Tornando al mondo del software, la fattibilità dell'uso di modelli di progettazione predefiniti dipende da due fattori:

  • L'implementazione, non i modelli di progettazione individuali, rappresenta una soluzione. La soluzione potrebbe incorporare più modelli di progettazione e, così facendo, conoscerebbe come interagiscono i singoli modelli di progettazione.
  • La soluzione deve essere adattabile, che risponde alla domanda finale dall'analogia della fondazione precostruita: la fondazione deve essere in grado di adattarsi al terreno e alle planimetrie. Come puoi immaginare, ci vorrebbe un artigiano estremamente abile per costruire la fondazione adattabile rispetto alla fondazione standard.

Modelli di progettazione comuni

La tabella seguente elenca alcuni modelli di progettazione comuni da entrambe le origini J2EE e modelli OO più ampi.

Modelli di progettazione comuni
Modelli di design J2EE Modelli di sviluppo del software
Facciata della sessione Singleton
Value Object Assembler ponte
Modello di localizzazione del servizio Prototipo
Delegato aziendale Fabbrica astratta
Entità composita Peso mosca
Gestore elenco valori Mediatore
Localizzatore di servizi Strategia
Entità composita Decoratore
Oggetto valore Stato
Servizio al lavoratore Iteratore
Oggetto di accesso ai dati Catena di responsabilità
Filtro di intercettazione Model View Controller II
Visualizza Helper Memento
Vista composita Costruttore
Visualizzazione Dispatcher Metodo di fabbrica

Diamo un'occhiata a due esempi di design pattern J2EE: i pattern Session Facade e Value Object. Entrambi dimostrano come i modelli di progettazione J2EE si concentrino su problemi specifici dell'ambiente J2EE, in opposizione ai modelli di progettazione di sviluppo software che generalmente si applicano a qualsiasi sforzo di sviluppo di applicazioni.

Esempio: il pattern J2EE Session Facade

Il modello Session Facade si è evoluto dalle esperienze con Enterprise JavaBeans (EJB). I sistemi costruiti sugli EJB dell'entità di recente introduzione (che comunicano con un database) stavano rallentando a una scansione. I test delle prestazioni hanno rivelato problemi derivanti da più chiamate di rete effettuate durante la comunicazione con i bean EJB dell'entità, che hanno aggiunto un sovraccarico per stabilire la connessione di rete, serializzare i dati sia per l'invio che per la ricezione e altri effetti.

In risposta, il modello Session Facade ha migliorato le prestazioni centralizzando i molteplici hit di rete in una singola chiamata. Session Facade utilizza un EJB di sessione senza stato per mediare tra la chiamata del client e l'interazione EJB dell'entità richiesta. Esistono più modelli per migliorare le prestazioni di accesso al database, inclusi i modelli Fast Lane Reader e Data Access Object.

Esempio: il pattern J2EE dell'oggetto valore

Il pattern Value Object J2EE mira anche a migliorare le prestazioni dei sistemi che utilizzano EJB sulla rete. Quelle chiamate di rete che provocano sovraccarico dell'esempio precedente recuperano i singoli campi di dati. Per esempio, si può avere un Personbean entità con metodi come getFirstName(), getMiddleName()e getLastName(). Con il modello di progettazione Value Object, è possibile ridurre tali chiamate di rete multiple a una singola chiamata con un metodo sul bean dell'entità, ad esempio getPersonValueObject(), che restituisce i dati tutti in una volta. Tale oggetto valore contiene i dati rappresentati dall'entità EJB ed è possibile accedervi secondo necessità senza incorrere nel sovraccarico delle chiamate di rete.

Esempio: il modello OO dei pesi mosca

Per un esempio di un design pattern OO ampiamente applicabile, si consideri il pattern Flyweight, che migliora le prestazioni dell'applicazione attraverso il riutilizzo degli oggetti. Il software OO produce overhead (cicli di CPU sprecati, garbage collection e allocazione della memoria) quando crea e distrugge un oggetto. Se il sistema potesse riutilizzare quegli oggetti, potresti evitare questo sovraccarico. Gli oggetti spesso non sono riutilizzabili, tuttavia, perché contengono informazioni (chiamate stato ) specifiche dell'utente corrente dell'oggetto. Il pattern Flyweight fornisce approcci per spostare quello stato altrove in modo che il resto dell'oggetto possa essere riutilizzato.

Mettili tutti insieme: esempio di persistenza

Ora che conosci le basi, puoi iniziare ad applicare i modelli di progettazione nelle tue pratiche di sviluppo. Ma come si usano effettivamente i modelli? Inizia identificando un dominio o un problema tecnico che richiede una soluzione. La persistenza, che risolve la secolare mancata corrispondenza tra database oggetto e database relazionale, rappresenta un buon esempio per la maggior parte delle applicazioni aziendali. Vediamo i passaggi necessari per progettare e creare il livello di persistenza dell'architettura dell'applicazione.

Seguendo la tradizionale architettura OO e l'approccio alla progettazione, crea casi d'uso che descrivono le tue esigenze di persistenza. I possibili casi d'uso includono:

  1. La persistenza degli oggetti dovrebbe essere trasparente dal punto di vista degli sviluppatori.
  2. I meccanismi di persistenza (bean di entità, oggetti di accesso ai dati e così via) dovrebbero essere configurabili a livello di architettura.
  3. La nostra architettura dovrebbe utilizzare le tecnologie J2EE ma incapsulare le dipendenze J2EE. Dovremmo essere in grado di cambiare i fornitori di server delle applicazioni J2EE, le versioni J2EE o sostituire completamente J2EE senza richiedere un'intera revisione dell'applicazione.
  4. Il livello di persistenza risultante dovrebbe essere riutilizzabile in tutti i progetti. Questo dovrebbe far parte della nostra attuale architettura applicativa.

Dopo aver identificato il problema, puoi decidere quali modelli applicare. Ricorda che per i modelli J2EE, dovresti determinare quali modelli si applicano nell'area problematica e risolverli. Per la persistenza, i modelli di progettazione J2EE rilevanti sono (vedere i libri sui modelli di progettazione J2EE di Sun in Risorse):

  • Oggetto valore
  • Lettore Fast Lane
  • Oggetto di accesso ai dati
  • Facciata della sessione
  • Entità composita
  • Gestore elenco valori

Poiché utilizzerai EJB, includi i pattern Business Delegate e Service Locator per indirizzare l'accesso EJB.

Inoltre, la risoluzione del secondo e del terzo caso d'uso richiede modelli di progettazione di sviluppo software tradizionali. Come incapsulare le dipendenze e disporre di meccanismi di persistenza configurabili? Alcuni modelli di sviluppo software applicabili includono:

  • Fabbrica
  • Mediatore
  • Strategia