La mia architettura ha un problema con le viste che richiedevano informazioni da oggetti diversi. Come posso risolvere questo?

I mappatori relazionali agli oggetti come NHibernate vogliono che tu faccia tutto il tuo trattamento dei dati usando oggetti di business. Tuttavia, come hai riconosciuto, estrai un intero aggregato dal repository è un'operazione costosa quando tutto ciò che vuoi è un aspetto di esso. Perché reidratare un intero Customer , inclusi tutti i relativi Order s e così via - potenzialmente unendo un certo numero di tabelle - quando tutto ciò che devi visualizzare sullo schermo è un FirstName ? I palloncini problema quando hai bisogno di un po 'di informazioni da un sacco di aggregati.

La soluzione è Segregazione di responsabilità di comando / query . (Credo che l'idea sia dovuta a Greg Young.) Una visione individuale ha bisogno di un insieme molto specifico di informazioni che un ORM può lottare per fornire in modo efficiente. Quindi, perché non scrivere query specifiche della vista che ignorano l'ORM, utilizzando un linguaggio progettato per l'interrogazione efficiente ed espressiva? (È possibile utilizzare SQL diretto, stored procedure, LINQ-to-SQL , HQL , o qualche altra lingua dichiarativa.) Questo In questo modo, puoi ottimizzare le tue query ai nini quando necessario, dopotutto, leggere i dati è molto più comune della scrittura dei dati.

In un'architettura CQRS, il modello di dominio (e NHibernate) esiste solo per facilitare scrivere . Il suo intero compito è proteggere gli invarianti di business e mantenere il database in uno stato coerente. La lettura dal database viene gestita in una parte completamente separata della tua applicazione, nota come Thin Read Layer, che non utilizza affatto il modello di dominio.

In genere, nel tuo livello di lettura sottile, avrai una query specializzata per visualizzazione. Questo può sembrare uno spreco ma come dicono Kent Beck e Martin Fowler , " Pensiamo che il riutilizzo sia sopravvalutato (lo usiamo solo). " Il sottile strato di lettura è sottile: estrae solo un set specifico di dati dal DB il più velocemente possibile. Quindi le query sono facili da scrivere, il che a sua volta le rende economiche da buttare via quando cambia la vista.

Quando prendi sul serio l'ottimizzazione della tua applicazione per la lettura, puoi realizzare che lo schema del tuo database ti trattiene e devi eseguire alcuni denormalizzazione . Tuttavia, la denormalizzazione può avere l'effetto di rendere le scritture nel database in modo inesplicabilmente complesso, rendendo il tuo modello di dominio lento e più difficile da mantenere. Quindi, alcune persone spostano l'intera query in un database separato! Questo potrebbe assumere la forma di un database SQL ottimizzato per la lettura, ma non è necessario utilizzare SQL: le tue visualizzazioni potrebbero essere più efficienti con qualcosa come Mongo o Lucene.

In questo tipo di sistema, il livello di lettura sottile deve controllare le modifiche nel modello di dominio. In genere, questo viene implementato utilizzando un modello di pubblicazione / sottoscrizione asincrono - il modello di dominio genera eventi a cui il read-side si iscrive per aggiornare la sua cache. Devi impostare il broker dei messaggi per registrare i tuoi eventi, in modo da poter ricostruire sempre le tue proiezioni nel caso qualcosa vada storto o devi creare una nuova istanza.

Questa architettura è facile da distribuire, quando arriva il momento di ingrandire la tua app. Avresti creato un database sul lato scrittura (con un modello di dominio) come "fonte di verità" e molti strati di lettura sottili posti sopra le cache di tutto il mondo.

Potrebbe essere utile esaminare il criterio Segregazione di responsabilità della query di comando . In sostanza, si introducono nuovi modelli per abbinare il modo in cui viene utilizzato il sistema. Potresti avere ad es. un modello di registrazione delle iscrizioni per gestire la tua query, mentre usi modelli di studenti, corsi, ecc. per le tue operazioni CRUD di base.

Non sono sicuro di seguirlo completamente, fammi vedere se ho questo diritto.

Il View Layer ha componenti che generano DTO per l'interfaccia utente, ma generano BO per chiamare i componenti nel livello aziendale. I componenti nel livello aziendale li consegnano ai componenti nel livello del repository per la memorizzazione / il recupero.

Se questo è il caso, allora non sono davvero sicuro del punto del livello aziendale. È difficile dire le sue responsabilità dalla descrizione. Se i componenti del livello vista sono quelli che creano BO, allora ha una conoscenza abbastanza complessa di quelli.

Potresti voler inserire tutte le costruzioni e la gestione BO in componenti nel livello aziendale. Sembra che il livello aziendale dovrebbe essere l'adattatore. (Questo di solito è ciò che la logica aziendale è per.) Mi aspetterei che i componenti del livello aziendale consumino richieste di dati dai componenti di visualizzazione (ad esempio, ottenere informazioni dallo studente) e creare oggetti completi (studente, età, corso, ecc. ) assemblando i dati dai componenti nel livello repository. Mi aspetterei che il tipo (e le qualità) degli oggetti che fluiscono tra i diversi livelli sia diverso in questo caso.

Puoi spiegare un po 'di più su cosa stai inviando tra i componenti?