Design Dominio Design Design VS Design driven per un'applicazione Web MVC

Question

Sto espandendo / conversione di un'applicazione di forme Web legacy in un'applicazione MVC totalmente nuova. L'espansione è sia in termini di tecnologia, nonché del caso di uso aziendale. L'applicazione legacy è un design guidato da database ben fatto (DBDD). Quindi per e.g. Se hai diversi tipi di dipendenti come operatore, supervisore, custode del negozio ecc. E devi aggiungere un nuovo tipo, devi solo aggiungere e aggiungere alcune righe in un paio di tavoli e voilà, il tuo UI ha automaticamente tutto per aggiungere / aggiornare il nuovo Tipo di dipendente. Tuttavia la Seperazione degli strati non è così buona.

Il nuovo progetto ha due obiettivi primari

.
• Estensibilità (per i requisiti di pipeline attualmente e futuri)
• Performance

  Io intendo creare il nuovo progetto Sostituzione del Design Driven Database (DBDD) con un design guidato da dominio (DDD) mantenendo in mente il requisito di estensibilità. Tuttavia, passare da un design guidato dal database al design guidato dal dominio, sembra influire in modo inversamente il requisito delle prestazioni se lo paragonassi con la performance dell'applicazione DBDD legacy. Nell'applicazione legacy qualsiasi chiamata per i dati dell'UI interagire direttamente con il database e qualsiasi dato verrà restituito in forma di un DataReader o (in alcuni casi) un set di dati.

  Ora con un DDD rigoroso in posizione Qualsiasi chiamata per i dati verrà indirizzata tramite il livello aziendale e il livello di accesso ai dati. Ciò significherebbe che ogni chiamata avrebbe inizializzato un oggetto business e un oggetto di accesso ai dati. Una singola pagina dell'interfaccia utente potrebbe richiedere diversi tipi di dati e questa applicazione web da ciascuna pagina potrebbe essere richiesta da più utenti. Anche un'applicazione Web MVC è apolide, ogni richiesta avrebbe bisogno di inizializzare gli oggetti aziendali e gli oggetti di accesso ai dati ciascuno e ogni volta. Quindi sembra che una applicazione apolidi MVC il DBDD sia preferito da DDD per le prestazioni.

  O c'è un modo in DDD per ottenere entrambe, l'estensibilità che il DDD fornisce e le prestazioni fornite da DBDD?

Answer 1

Hai preso in considerazione una qualche forma di separazione della query di comando in cui gli aggiornamenti sono attraverso il modello di dominio, ma recita come DataReader?DDD soffiato completo non è sempre appropriato.

Answer 2

.

"Ora con un DDD rigoroso in posizione Qualsiasi chiamata per i dati verrà instradata tramite il livello aziendale e il livello di accesso ai dati."

Non credo che questo sia vero, e non è certamente pratico. Credo che questo dovrebbe leggere:

.

Ora con DDD rigoroso in posizione, qualsiasi chiamata per una transazione verrà instradata tramite il livello aziendale e il livello di accesso ai dati.

Non c'è nulla che dice che non è possibile chiamare direttamente il livello di accesso ai dati per recuperare qualsiasi dato di cui è necessario visualizzare sullo schermo. È solo quando è necessario modificare i dati che è necessario richiamare il tuo modello di dominio progettato in base al suo comportamento. A mio parere questa è una distinzione chiave. Se instrada tutto attraverso il tuo modello di dominio avrai tre problemi:

.
1. Tempo - Ci vorrà molto più a lungo per implementare funzionalità, senza alcun beneficio.
2. Design del modello - il tuo modello di dominio sarà inclinato per la forma per soddisfare le esigenze di interrogazione piuttosto che il comportamento.
3. Performance - non a causa di uno strato extra, ma perché non sarà in grado di ottenere i dati aggregati dal modello il più rapidamente possibile da una query. I.e. Considera il valore totale di tutti gli ordini effettuati per un particolare cliente - è molto più veloce scrivere una query per questo che recuperare tutte le entità dell'ordine per il cliente, iterano e sum.

   Come ha detto Chriseyre2000, i CQRS mira a risolvere questi problemi esatti.

Answer 3

L'utilizzo di DDD non dovrebbe avere implicazioni significative per prestazioni nello scenario.Quello che hai preoccupato per sembra più come un problema di accesso ai dati.Ti riferisci ad esso come

.

Inizializza un oggetto business e un oggetto di accesso ai dati

Perché è costoso 'inizializzando'?Quali meccanismi di accesso ai dati stai usando?

DDD con oggetti a lunga vita memorizzati in un database relazionale viene solitamente implementato con ORM. Se usato correttamente , Orm avrà molto poco, in caso di impatto sulle prestazioni per la maggior parte delle applicazioni.E puoi sempre tornare alla maggior parte delle parti più sensibili alle prestazioni dell'app a SQL grezze se c'è un collo di bottiglia comprovato.

Per ciò che vale, Nibernate deve essere solo inizializzato una volta sull'avvio dell'applicazione, dopo di che utilizza lo stesso pool di connessione ADO.NET come i tuoi lettori di dati regolari.Quindi tutto si riduce a una mappatura adeguata, alla recupero della strategia ed evitando gli errori classici di accesso ai dati come "n + 1 selects".