architettura web: MVC, l'inizializzazione differita, trasferimento Data Objects, Sessione aperta in visualizzazione, c'è un approccio consensuale?

StackOverflow https://stackoverflow.com/questions/1969278

Domanda

Quali difetti vedete nel seguente disegno, (e quale sarebbe la vostra architettura suggerimento ideale) per una tipica applicazione web 3-tier?

Il mio attuale approccio progetto è molto grosso modo questo (supponendo Java, Spring, Hibernate, JSP)

Regolatore

Stateless, potenzialmente avvolto con un solo transazione di lettura (per evitare eccezioni init pigri), di ottenere entità di stoccaggio persistenza via solo il servizio, li passa alla vista come il modello. Conduce la logica di business su di loro (se il BL essere al livello di servizio unico?), Passa indietro al livello di servizio per la persistenza se necessario.

Pro : per sola lettura involucro transazione - una sola connessione, non colpisce ridondanti per la stessa entità persistenti, utilizza cache delle query migliore, livello di servizio non deve "sapere" parametri di richiesta, o richiesto init arco grafico, evitare eccezioni init pigri.

Contro : L'approccio di transazione di sola lettura può essere rischioso, i controllori non sono il luogo ideale Business Logic appeso ... molto difficile da fare JUnits (l'input è una richiesta ...)

Visualizza

Non transazionale (accesso alle collezioni non pigri / membri si tradurrà in un'eccezione init pigro)

Pro :

  • L'autore vista non dovrebbe influenzare per semplice notazione la prestazione dell'applicazione (per esempio causa N + 1 seleziona causa di pigrizia inizializzazione di una grande raccolta.

  • Anche nel client disconnessi (Flex o altri rich client) l'inizializzazione differita da remoto è o non supportato, o semplicemente non è una cosa intelligente da fare

Contro : il controller / servizio / DAO devono preparare con cura il diritto grafo degli enti per la vista, e possono essere overshooting (performance) / undershooting (pigro eccezione init). una miriade di metodi lato server può causare confusione in quanto v'è un prodotto cartesiano al numero di permutazioni un grafico entità può essere inizializzato

Modello

Utilizzando gli oggetti persistenti come è, (oggetti senza trasferimento dati), lo stato viene salvato nella sessione.

Pro : non c'è bisogno di riscrivere POJO, il riutilizzo di entità esistenti, lo stato della sessione è più sicuro di campi nascosti affermare la manipolazione

.

Contro :. Male per quadri disconnessi, rischio di salvataggio di oggetti disconnessi stantii, rischio di problemi di blocco, sovrascrivendo i dati di altri, richiede ottimista bloccaggio a volte

servizio

transazionale, non conosce la portata richiesta, chiama uno strato DAO per effettivo accesso allo storage persistenza. questo è dove il BL dovrebbe essere classicamente, ma sembra che le perdite BL al lato controllore ripetutamente.

DAO

Contiene facciata stoccaggio persistenza atomica, ignaro del BL, o qualsiasi contesto

Infine, alla domanda:

Cosa vorresti correggere nell'architettura di cui sopra?

Pensi che (come me) si tratta di un approccio abbastanza comune (con alcune differenze minori, come sessione aperta a vista, ecc)? O è la prima volta che si vede e che sto facendo qualcosa di terribilmente sbagliato (o di destra)?

Come si risolve nelle vostre applicazioni? Usi il tuo entità POJO anche per il modello e visualizzare? o si cablaggio fino ai fagioli di interfaccia utente più semplici (tutte completamente inizializzato e sicuro)?

Questa può essere una questione soggettiva, ma sono sicuro che ci sono chiari migliori schemi di progettazione pratica che cluster per uno, due o tre max "religioni" generali.

È stato utile?

Soluzione

In generale, sembra che una buona architettura. Se non lo avete già letto, mi sento di raccomandare Martin Fowlers Patterns of Enterprise Application Architecture, che descrivono ogni soggetto nella sua interrogazione.

Non è chiaro dalla domanda quanto grande un problema che ci si aspetta prestazioni sia. Nella mia esperienza, i colli di bottiglia delle prestazioni sono raramente in cui si pensa che sono, e quanto prima li trovate, più facile è quello di cambiare l'architettura in modo che corrisponda.

Hai ragione che testabilità è una preoccupazione importante. Ho usato Martin Fowlers Passive View -pattern con un certo successo. Si dovrebbe anche dare un'occhiata a supervisione Controller, dallo stesso sito.

Altri suggerimenti

Super a meno di fare un front-end stile Sofea, che fondamentalmente si libera della parte controller nell'architettura sopra.

Il frontale è interamente contenuto sul client, che richiama direttamente REST o SOAP servizi di ritorno JSON o XML. Che sembra risolvere 100% dei problemi di trasformare oggetti di dominio per la visualizzazione !!!!

Forse, alcuni suggeriscono, la ragione non c'è soluzione pulita per l'architettura N-tier sopra descritto è perché è semplicemente sbagliato.

Link

  1. http://raibledesigns.com/rd/entry/sofea_also_known_as_soui
  2. http://www.theserverside.com/news/thread.tss ? ID_Thread = 47.213
  3. http://wisdomofganesh.blogspot.com/2007 /10/life-above-service-tier.html

Il mio progetto attuale utilizza un'architettura N-tier un po 'datato con il trasferimento Objects. I DTOs sono inutili perché l'applicazione non è distribuito e non lo sarà mai. L'unico vantaggio (che non vale la pena IMO) di utilizzare i DTOs è che obbliga un'interfaccia pulita per i metodi di business - i componenti di vista può attraversare il grafo di oggetti sulle pseudo-modelli tuttavia essi desiderano - senza eccezioni lazy-inizializzazione può essere gettato.

Uno dei punti di dolore-architettoniche che vedo nella nostra architettura è che le interfacce di business sono due dannati complicate. Sembra come se abbiamo bisogno di un'interfaccia meta-business per incapsulare tutti i piccoli interfacce di business. In effetti, questo finisce per accadendo in cui un servizio finisce per chiamare altri tre servizi per fare il suo lavoro.

I controllori (nel nostro caso, Struts 1.2 le classi d'azione) finiscono per chiamare qualsiasi combinazione di questi componenti di business ultra-grana fine o grana grossa. Nella maggior parte dei casi, purtroppo, gli sviluppatori involontariamente o pigramente codificare una varietà di ciò che dovrebbe essere la logica di business nelle classi controller. Io urlo ogni volta che guardo in uno di questi tre metodi cento linea di azione !!!!

L'approccio Sofea sembra offrire un approccio molto più pulito. AJAX consente anche le applicazioni web in esecuzione sul browser di avere la loro estremità anteriore codificato utilizzando l'apposito modello MVC, che è buono sia per gli utenti (offrendo una più dinamica UI) e gli sviluppatori (permettendo loro di codice appropriato MVC).

L'interfaccia utente è completamente disaccoppiato dalla logica di business riutilizzabile. È l'interfaccia grafica spesso o sottile? In realtà non sarà questione -they'll essere codificato in sostanzialmente allo stesso modo.

Sofea / Soui è nuovo per me e non ho mai provato, ma ho letto su di esso ultimamente e ho pensato di condividere i miei pensieri.

Il tuo approccio sopra buon suono.

Ma penso che si dovrebbe usare UI-Fagioli. Naturalmente questo UI-Bean dovrebbe essere efficace immutabile. Non appena viene creato il suo stato (e l'oggetto dominio incapsulato) non dovrebbe essere modificato.

esempio molto semplificato: 


class UIBean {
  DomainObject o;

  public String getDescription(){
     return trimToSummaryText(o.getDescription());
  }

  private static String trimForSummaryText(){
     ....
  }
}

pro principali:

  • il codice del modello tende a diventare più pulito e conciso. Il tuo Frontend-sviluppatore sarà contento di questo.
  • Non si tendono ad aggiungere metodi helper specifici frontend per classi di oggetti di dominio.
  • Il raggruppamento di diversi oggetti di dominio o visualizzare in grano è possibile (ui-fagioli potrebbe avere più campi). L'incapsulamento delle liste è particolarmente bello qui.

Sì, si tratta di più java-classi per questo. Ma questo livello di astrazione è quasi sempre bene non appena il vostro webapp e pagine di crescere.

Nonostante la questione è stata risolta scorso su anno fa, forse la risposta sembra utile a qualcuno. Nel complesso delineato da voi l'architettura va bene, l'unico dettaglio da aggiungere è: di solito per il passaggio dei dati tra gli strati (ad esempio, View and Service) invece di cui sopra UiBean-s cosiddetti DTOs (trasferimento dati Objects), a questi sono POJO semplici con appositi campi / setter / getter.

In uno dei precedenti / prime versioni di Java EE Spec "DTO" termine è stato erroneamente mescolato con "ValueObject", anche se hanno finalità po 'diverso.

La speranza, questo aiuta.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top