Ricerca di modelli di progettazione per isolare i livelli di struttura gli uni dagli altri

Question

Mi chiedo se qualcuno abbia esperienza nell'isolare gli oggetti di framework l'uno dall'altro (Spring, Hibernate, Struts). Sto iniziando a vedere i "problemi" di progettazione in cui un oggetto da un framework viene utilizzato in un altro oggetto da un framework diverso. La mia paura è che stiamo creando oggetti strettamente accoppiati.

Ad esempio, ho un'applicazione in cui abbiamo un DynaActionForm con diversi attributi ... uno dei quali è un POJO generato da Hibernate Tools. Questo POJO viene usato ovunque ... il JSP popola i dati ad esso, l'azione Struts lo invia a un livello di servizio, il DAO lo manterrà ... ack!

Ora, immagina che qualcuno decida di eseguire un piccolo refactoring su quel POJO ... quindi significa che JSP, Action, Service, DAO devono tutti essere aggiornati ... il che è piuttosto doloroso ... C'è deve essere un modo migliore ?!

C'è un libro intitolato Core J2EE Patterns: Best Practices and Design Strategies (2a edizione) ... vale la pena dare un'occhiata? Non credo che tocchi alcun framework specifico, ma sembra che potrebbe dare qualche idea su come applicare correttamente il layer all'applicazione ...

Grazie!

Answer 1

Per esempio, ho un'applicazione in cui abbiamo un DynaActionForm con diversi attributi ... uno dei quali è un POJO generato da Hibernate Tools. Questo POJO viene usato ovunque ... il JSP popola i dati ad esso, l'azione Struts lo invia a un livello di servizio, il DAO lo manterrà ... ack!

Per me, non c'è niente di male ad avere dominio oggetti come strato "transveral" in un'applicazione web (dopo tutto, si desidera il loro stato di andare dal database per l'interfaccia utente e non vedo il bisogno di mapparli in strutture intermedie):

Ora, immaginate che qualcuno decide di fare un po 'di refactoring su quel POJO ... in modo che significa che il JSP, Azione, servizio, DAO tutte le esigenze per essere aggiornato ... che è un po 'doloroso ... Ci deve essere un modo migliore ?!

Certo, si poteva leggere "fagioli" dal database al livello dello strato DAO, mapparli in "Domain Objects" a livello di servizio e mappare il dominio oggetti in "oggetti di valore" per il livello di presentazione e si avrebbe un accoppiamento molto basso. Ma poi ti rendi conto che:

1. L'aggiunta di una colonna in un database di solito comporta l'aggiunta di alcune informazioni sulla vista e viceversa.
2. La duplicazione di oggetti e mappature è estremamente dolorosa da fare e da mantenere.

E dimenticherai questa idea.

C'è un libro intitolato Core J2EE Patterns: Best Practices and Design Strategies (2a edizione) ... vale la pena dare un'occhiata? Non credo che tocchi alcun framework specifico, ma sembra che potrebbe dare qualche idea su come strutturare correttamente l'applicazione ...

Questo libro era una "vetrina" di come implementare (oltre applicazioni ingegnerizzate) utilizzando l'intero stack J2EE (con EJB 2.x) e in qualche modo è sempre stato considerato troppo complicato (troppi modelli). Oltre a questo, oggi è chiaramente obsoleto. Quindi è interessante ma deve essere preso con un granello di sale gigante.

In altre parole, non consiglierei quel libro (almeno certamente non come stato dell'arte). Invece, dai un'occhiata a Real World Java EE Patterns - Rethinking Best Practices (vedi Capitolo 3 - Mappatura dei modelli J2EE core in Java EE) e/o alla letteratura Spring se non stai usando Java EE.

Answer 2

In primo luogo, evitare Struts 1. Il dover estendere una classe framework (come DynaActionForm) è uno dei motivi per cui questo framework non è più una buona scelta.

Non si usano le classi primaverili nei soliti scenari. La primavera è non invadente - collega semplicemente i tuoi oggetti. Si dipende da esso solo se si utilizzano alcune interfacce come ApplicationContextAware o se si utilizzano le estensioni di ibernazione o jdbc. Usare queste estensioni insieme a hibernate/jdbc completamente bene e non è un accoppiamento indesiderato.

Aggiornamento: Se sei costretto a lavorare con Struts 1 (onestamente, prova a negoziare per Struts 2, Struts 1 è obsoleto!), Il solito modo per andare era creare una copia della classe Form, che contenesse l'esatto stessi campi, ma non ha esteso la classe framework. Ci sarebbe un metodo factory che prende la classe form e restituisce il semplice POJO. Questa è duplicazione del codice, ma l'ho vista in pratica e non è poi così male (rispetto all'uso di Struts 1 :))

Answer 3

Direi che i modelli Core J2EE: best practice e strategie di progettazione (2 ° Edizione) affronta le preoccupazioni di EJB 2.0, alcune delle quali sarebbero considerate anti-pattern oggi. La conoscenza non è mai sprecata, ma non farei di me la mia prima scelta.

Il problema è che è impossibile separare tutti i livelli. Rifare il POJO significa modificare il problema che stai risolvendo, quindi tutti i livelli DEVONO essere modificati. Non c'è modo di aggirare questo.

Il disaccoppiamento puro di strati che non hanno conoscenza reciproca richiede un sacco di duplicazione, traduzione e mappatura per verificarsi. Non cadere nell'idea che l'accoppiamento libero significhi che questo lavoro va via.

Una cosa che puoi fare è avere un livello di servizio espresso in termini di richieste e risposte XML. Ti costringe a mappare l'XML agli oggetti sul lato del servizio, ma disaccoppia l'interfaccia dal resto.

Answer 4

Penso che il tuo problema non sia così grande come sembra.

Immaginiamo, che cosa si può cambiare davvero nel vostro POJO:

1) nome della sua classe: qualsiasi IDE con supporto refactoring farà automaticamente tutte le modifiche necessarie per voi

2) aggiungere un po 'di campo/metodo: significa quasi sempre aggiungere nuove funzionalità, ciò che deve sempre essere fatto manualmente e con attenzione. Solitamente causa alcuni cambiamenti nel tuo livello di servizio, molto raramente in DAO e di solito nella tua vista (jsp).

3) implementazione dei metodi di modifica: con una buona progettazione questo dovrebbe causare cambiamenti nelle altre classi.

Questo è tutto, imho.

Prendere una decisione sulla tecnologia per l'implementazione della logica di occupato (EJB o Spring) e utilizzare le sue funzionalità di iniezione delle dipendenze. L'utilizzo di DI consente a parti diverse del programma di comunicare tra loro tramite interfacce. Dovrebbe essere sufficiente per raggiungere il livello di accoppiamento necessario (abbastanza piccolo).

Answer 5

È sempre bello tenere le cose chiare se è possibile e separare gli strati ecc. Ma non esagerare. Ho visto sistemi in cui gli sviluppatori erano così attenti a seguire rigorosamente i loro modelli e le pratiche adottati che hanno finito con un sistema peggiore di quello immaginario che stavano cercando di evitare.

L'arte del buon design è capire le buone pratiche e gli schemi, sapere quando e come applicarli, ma anche sapere quando è opportuno interromperli o ignorarli.

Quindi, date un'occhiata a come potete ottenere ciò che state cercando, leggete gli schemi. Quindi fai una prova su una prova di concetto separata o su una piccola parte del tuo sistema per vedere le tue idee in pratica. La mia esperienza è che solo una volta messo in pratica un codice, vedi davvero i pro ei contro dell'idea. Una volta che lo hai fatto, sarai in grado di prendere una decisione informata su ciò che vuoi o non vuoi presentare.

Infine, è possibile creare un sistema che gestisca tutti i problemi di cui si è interessati, ma sia pragmatico: ogni obiettivo che si sta tentando di raggiungere vale il codice e le API aggiuntivi che si dovranno presentare per raggiungerlo.