7

Ho un ordine standard/OrderLineItem.DDD/DI (Unity)/.NET/Composizione Root - Servizi di dominio

Un numero di rimborsi viene generato durante il giorno che viene mantenuto durante il giorno, il rimborso consiste in un ID ordine e 1 o più IDItemi. Ho bisogno di consolidare questi (in un servizio di Windows) alla fine della giornata di rimborso a carte di credito, carte regalo, carte premio ecc. A seconda dei casi.

Ho letto Mark Seemann's book e posso vedere il vantaggio di utilizzare un Composition Root per far frusciare un grafico oggetto.

Il processo di consolidamento è il punto in cui è necessario eseguire la maggior parte della composizione.

Quello che non capisco è esattamente dove dovrebbe finire questa logica di consolidamento? Posso supporre che, indipendentemente da dove finisce la logica di consolidamento, utilizzo ancora qualcosa come Unity nella composizione root e che la composizione dovrebbe avvenire molto presto?

Felice di fornire maggiori informazioni o chiarire se necessario!

risposta

3

Il processo di consolidamento è il punto in cui è necessario eseguire la maggior parte della composizione.

Quindi, vuoi dire che il processo di creazione dei dati nel tuo sistema è dove verrà creato la maggior parte degli oggetti del dominio?

Questo ha senso ed è in linea con la maggior parte delle applicazioni.

Quello che non capisco è esattamente dove dovrebbe finire questa logica di consolidamento?

La logica consolidamento sarà fornito da uno o più componenti di servizio, che probabilmente utilizza uno o più componenti repository e uno o più componenti unit of work. Tale servizio sarà composto nella radice della composizione, così come qualsiasi repository/unità di lavoro che si finisce per creare.

I dati stessi sono completamente dinamici. Non puoi strutturare la tua applicazione per conoscere il layout dei dati in modo statico, quindi non puoi comporlo nella tua composizione radice. Né dovresti provare a.Invece il tuo codice potrebbe utilizzare un ORM per definire o mappare lo schema relazionale tra i tuoi oggetti di dati del dominio.

Quindi è possibile utilizzare il repository/unità di lavoro per recuperare i dati dalla memoria. Inoltre, l'utente utilizza l'interfaccia utente/servizio per creare nuovi dati utilizzando new, senza vergogna per gli oggetti di dominio puramente dati e che non hanno alcuna dipendenza. Persistere dati nuovi o modificati nel repository/unità di lavoro.

Se questo ti fa rabbrividire, puoi sempre usare un modello di fabbrica che viene iniettato dalla radice di composizione per creare quegli oggetti. Ma se hai strutturato i tuoi oggetti di dominio di basso livello come DTOs, questo non ti comprerà molto, semmai.

Quindi non è necessario utilizzare Unity per fornire tutto e non è necessario creare assolutamente ogni oggetto nel sistema nella radice di composizione. Ma dovresti provare a comporre pezzi statici del tuo sistema, o anche pezzi dinamici configurabili staticamente del tuo sistema nella radice della composizione. Questo funziona molto bene con i contenitori DI come Unity.

+0

Grazie per la risposta. Ho una domanda basata su ciò che hai detto sopra ... dovrei sempre usare un servizio di chiamata che a sua volta utilizza un repository invece di utilizzare direttamente qualsiasi repository? – inthegarden

+0

@inthegarden: non è possibile esporre i repository direttamente sulla skin di un servizio e non è possibile restituire le entità direttamente all'interfaccia utente. Quindi al livello più alto della tua app ti servirà * qualche * tipo di livello. Se questo completamente si associa a un livello di servizio richiamabile esternamente, è grandioso. Ma non inserirò tutti i ganci di servizio in tutto ciò a quel livello * a meno che * non volessi esporre ogni singolo elemento della funzionalità dell'interfaccia utente alle persone che chiamano un servizio web. Il servizio è un insieme separato di requisiti dell'interfaccia utente, quindi non essere troppo zelante nel far sì che tutto venga eseguito. –

3

Nel caso in cui i tuoi articoli di rimborso siano solo contenitori di dati o entità che non hanno alcuna dipendenza dai servizi, puoi semplicemente creare un'istanza usando new.

Se hanno dipendenze e devono essere create dal contenitore IoC e non è possibile eseguire all'avvio di quanto si vorrebbe utilizzare un'interfaccia di fabbrica. Questa interfaccia di fabbrica contiene un metodo CreateRefund che prende tutti i parametri richiesti che si desidera passare all'istanza creata. Questa interfaccia è definita nello spazio dei nomi/assembly del suo consumatore.

L'implementazione di questa interfaccia dipende dal contenitore IoC. Alcuni contenitori forniscono la funzionalità che l'interfaccia viene implementata automaticamente dal contenitore semplicemente specificandolo nella configurazione. Altri come Unity richiedono un'implementazione manuale. Questa implementazione risiede nella Composizione Root come parte della configurazione del contenitore. Lascia che l'implementazione prenda un'istanza del contenitore e la utilizzi per creare l'istanza di rimborso richiesta.

In questo modo l'unica posizione in cui si accede al contenitore si trova nella Composizione radice.