Repository multipli o singoli con LINQ

Question

Ho letto il capitolo 11 (Pattern di progettazione testabile) nel libro Professional ASP.NET MVC 1.0. Negli esempi di questo capitolo, l'accesso ai dati è suddiviso in un numero di repository: IOrderRepository, IProductRepository, ecc. Tutto ciò ha senso: un singolo repository per una singola classe di dati.

Tuttavia, ciò si interrompe per me quando si considerano i collegamenti tra le tabelle: un ordine contiene un numero di prodotti. Quando la classe Ordine viene creata da LINQ-to-SQL, la classe ordine avrà una raccolta Prodotti che enumera tutti i prodotti correlati a tale ordine. Quindi, usando questa collezione, stiamo bypassando il ProductRepository.

Pertanto, quando sto prendendo in giro, non ho intenzione di prendere in giro solo OrderRepository e ProductRepository, ma dovrò anche compilare la raccolta Prodotti negli oggetti Ordine restituito. Il che significa che il Repository Order deriso deve conoscere il ProductRepository deriso e così via.

Sembra uno spreco ignorare queste raccolte che LINQ ha creato così gentilmente per me, quindi la mia domanda è, in questo caso, un repository non ha più senso?

Answer 1

Altri fattori da considerare sono la probabile durata della vita del prodotto e la probabilità di dover cambiare da LINQ to SQL per qualche altro O/R mapper in qualsiasi punto nel corso della vita. Più piccolo è il progetto, meno critico è il prodotto, meno è necessario preoccuparsi di astrarre il minuto all'ennesima potenza.

Answer 2

La descrizione del problema è un tipico esempio da manuale di quando troppi blabla su "questo è buono, ciò che è male" diventa la ragione per cui uno sviluppatore crea il software nel modo in cui viene creato invece di esaminare il problema e creare software per risolvere questo problema.

Caso in questione: la descrizione del problema non è un problema da risolvere: hai un'applicazione da creare per il tuo cliente, questo è il problema che dovresti risolvere. Se la tua scelta di strumenti ti rende difficile la vita, buttali fuori e usa ciò che funziona: se il beffardo non funziona, perché preoccuparsi? Oh, perché qualcuno ha detto che il tuo software farà schifo se non ti prendi gioco? Perché?

Hai trovato alcune cose DDD qua e là, ma hai perso alcune parti importanti: il prodotto è una radice aggregata. Ciò significa che è necessario ottenere prodotti dal proprio repository. Sì, questo mitiga la funzione di navigazione nel modello, ma questo è DDD per te, SE crei i repository rigorosamente come sta dettando la seconda parte del libro di Evans. Ma ... dovresti?

Se non si riesce a rispondere perché il Prodotto ha il proprio repository, eppure è possibile accedere ai prodotti dall'Ordine, non è necessario creare repository per le root aggregate. PERCHÉ c'è quel repository lì? Se è lì, non dovrebbe essere l'UNICO punto in cui i prodotti sono ottenibili? (quindi anche non attraverso il caricamento pigro!).

Questo effettivamente creerà un sacco di spese generali e codice che probabilmente non serviranno (in modo così ironico, YAGNI in pieno effetto).

Ok, abbastanza ranting. DDD è tutto su che pensa. Quindi il dominio dovrebbe guidare il design e, praticandolo, otterrai un modello di dominio che rappresenta la realtà. Questo non vuol dire che dovresti implementare molto codice solo perché leggi da qualche parte dovresti. Invece, se hai riconosciuto gli elementi del dominio, le radici aggregate ecc., Devi quindi posizionare il comportamento per questi tipi da qualche parte, ad es. all'interno delle classi di dominio. È possibile inserire la logica di recupero in classi separate come la logica di recupero orientata all'ordine in un repository di ordini, ma non sarà un repository in senso stretto (ad esempio non ha una propria cache locale, ecc.). Non è così male, è tutto su ciò che dovresti creare per il tuo cliente.

Quindi, primo: pensa, secondo: pensa e terzo: pensa ... di nuovo. Cosa sembra logico per te. Fai una lista di pro/contro delle opzioni che hai e scegli quella che sembra la più giusta per te. Documenta quella scelta e perché hai scelto quella e non le alternative.Ciò dà più valore ai maintainer di qualsiasi altra fonte: documenti le alternative e perché non le hai raccolte, fai ricerche su ciò che funzionerà per te e ne hai scelto uno.

progettazione software non è difficile, è solo che al giorno d'oggi sembra la moda di fare semplicemente di prima e pensare in seguito, senza un adeguato ragionamento perché si potrebbe farlo in quel modo e non il contrario.

Buona fortuna :)