Buon modello di progettazione per linq a sql

0

Al momento ho un progetto da linq a sql che è stato utilizzato per un progetto e non è stato inserito molto lavoro, sono stati utilizzati solo il contesto e le entità generate. Da allora il progetto ha iniziato a diventare referenziato in altri progetti e sta crescendo piuttosto rapidamente. La mia preoccupazione all'inizio era il codice duplicato, ad esempio:

using (DataContext dc = new DataContext())
{
    User myUser = dc.Users.Where(u => u.UserId == 1).SingleOrDefault();
}

Questo potrebbe essere usato nel mio progetto, ma anche usato nel progetto di qualcun altro. Non voglio progetti puzzolenti ...

Ultimamente abbiamo iniziato a implementare la progettazione del repository, quindi abbiamo anche un singolo repository in grado di gestire più entità, quindi ora le query vanno direttamente al repository piuttosto che al contesto dati.

Abbiamo implementato un repository generico con metodi come All() e FindAll() ecc ... ma la mia domanda è quando arriviamo a fare cose più complesse come la creazione di un record che comporta la creazione di numerose entità diverse, questo va in il livello del repository o devo iniziare a guardare un altro modello di progettazione?

    
posta KnottytOmo 07.11.2014 - 19:51
fonte

1 risposta

1

Un metodo Save () per un oggetto complesso passerebbe all'interfaccia del modello del repository. No, non è necessario utilizzare un modello diverso.

Un repository dovrebbe idealmente astrarre tutti i dettagli di implementazione dello storage sottostante (cioè DB, raccolta di memoria, file XML ecc.) dal modello a oggetti con cui funziona. Quindi, se stai creando un oggetto complesso che ha relazioni tra entità diverse, modellalo come un insieme di classi e scrivi un metodo sul tuo repository per accettare quel tipo e fare il lavoro sporco di creare le classi nel tuo dispositivo fisico (qualunque sia quello può essere).

    
risposta data 27.11.2014 - 14:46
fonte

Leggi altre domande sui tag