Utilizzo di applicazioni aziendali multistrato di oggetti JAXB

Question

Utilizzo di applicazioni aziendali multistrato di oggetti JAXB

#1 da (1 voti)

0

Mi viene chiesto di refactoring e mantenere un'applicazione enterprise. Normalmente sono abituato a usare il modello di progettazione MVC. Questa volta però, mi piacerebbe separare tutto in strati (architettura multistrato). Qualcosa sulla falsariga di (Microsoft Application Architecture Guide, 2nd Edition - October 2009):

LemieoriginidatisonoingeneralefileXML.Questifilesonolettiescritticonl'usodiJAXBequestorisiedenellivellodati.OgnivoltachecaricounXMLspecificoun"provider" userà JAXB per costruire un albero di oggetti che rappresentano la struttura XML. Questi oggetti / informazioni devono essere utilizzati all'interno del livello aziendale, di servizio e di presentazione. Per livello le informazioni devono essere trattate in modo diverso, vale a dire che il livello aziendale imporrà regole aziendali sugli oggetti / informazioni, mentre il livello di presentazione necessita di informazioni aggiuntive sull'interfaccia utente per mostrare tutto all'utente.

Sto cercando i tuoi suggerimenti / esperienze quando si tratta di utilizzare le origini dati in un'applicazione multistrato. Dovrei:

Crea una sorta di mappatura, in modo tale che un nuovo albero di oggetti sia costruito in ogni livello?
Lavorare attraverso le linee di aggregazione, in modo che le mie origini dati possano essere decorate con funzionalità / informazioni extra all'interno di un oggetto che vive in un altro livello?
Rendi gli oggetti JAXB "grassi", con un'interfaccia che supporti tutte le mie esigenze provenienti da tutti gli altri livelli?

Mi piacerebbe sentire i tuoi pensieri!

java architecture enterprise-architecture architectural-patterns

posta Velth 07.07.2014 - 15:36

fonte

1 risposta

Leggi altre domande sui tag java architecture enterprise-architecture architectural-patterns

DTO - livello di servizio - best practice per l'apolidia che interferiscono tra loro Come sono organizzate le tessere in WORDAMENT?

score 1 · Answer 1

Raccomando quanto segue:

Implementa il livello dati utilizzando un framework ORM consolidato. Il mio preferito è myBatis, ma JPA e Hibernate sono contendenti definiti.
Avvolgi il livello dati con un'API Java che supporta solo le operazioni aziendali (non le operazioni CRUD), ad es. Leggi i dettagli del cliente, iscriviti al nuovo cliente, cancella il cliente, effettua l'ordine ecc. In questo modo sei libero di decidere nel livello dati se hai bisogno di registrare cronologia, effettuare registrazioni di transazioni, ecc. Ha anche il vantaggio di operazioni pesanti (ad es. ) può utilizzare direttamente l'API, mentre le operazioni a livello aziendale utilizzano SOAP o simili. Il punto importante è che tutti i client finiscono per utilizzare la stessa API.
Se il livello dati è ben progettato, il livello aziendale dovrebbe essere quasi un pass-through. In caso contrario, probabilmente sei sulla strada della rovina, dal momento che il tuo database non riflette il tuo modo di fare business.
MVC è ottimo per il livello della GUI, ma a mio avviso ha un'applicazione limitata altrove. Se hai capito bene, il livello del modello consisterà semplicemente in un'aggregazione di alcuni POUO DAO. La visualizzazione sarà JSP, JSF o un'altra tecnologia consolidata. Mi piace utilizzare Spring Web MVC con JSP, ma ci sono molte alternative.
La mappatura del sistema esterno dovrebbe essere flessibile, consentendo di mappare da una visione diversa della realtà al proprio modello interno di dati aziendali. Protocolli standardizzati come SOAP vincono qui, ma sembra esserci un passaggio alle interfacce REST, che non hanno ancora lo stesso livello di definizione.

In ogni caso, c'è più di una risposta "corretta". c'è una battuta di vecchia data che se chiedi a tre architetti di software di esprimere un'opinione, avrai almeno 4 risposte ...