MVC: repository e servizi

Question

Sono confuso riguardo ai limiti di ciò che viene definito nei Repository e cosa lasciare ai Servizi. Il repository dovrebbe creare solo entità semplici corrispondenti alle tabelle dal database o può creare oggetti personalizzati complessi con combinazioni di tali entità?

in altre parole: i servizi dovrebbero eseguire varie query da Linq a SQL sul repository? O tutte le query dovrebbero essere predefinite nel repository e la logica aziendale dovrebbe semplicemente decidere quale metodo chiamare?

Answer 1

Qui hai effettivamente sollevato una domanda che attualmente sta generando molte discussioni nella comunità degli sviluppatori - vedi i commenti di follow-up a Il mio repository dovrebbe esporre IQueryable?

Il repository può - e dovrebbe - creare oggetti combinazione complessi contenenti più entità associate. Nella progettazione guidata dal dominio, questi sono chiamati aggregati : raccolte di oggetti associati organizzate in una struttura coesiva. Il tuo codice non deve chiamare GetCustomer () , GetOrdersForCustomer () , GetInvoicesForCustomer () separatamente - devi solo chiamare myCustomerRepository. Carica (customerId) e ottieni un oggetto cliente profondo con quelle proprietà già istanziate. Dovrei anche aggiungere che se stai restituendo singoli oggetti basati su specifiche tabelle di database, questo è un approccio perfettamente valido, ma in realtà non è un repository per s & # 233; - è solo un accesso ai dati livello.

Da un lato, c'è un argomento convincente che gli oggetti Linq-to-SQL, con le loro proprietà 'intelligenti' e la loro esecuzione differita (cioè non caricano il Cliente.Gli ordini fino a quando non lo usi effettivamente) sono un'implementazione completamente valida del modello di repository, poiché in realtà non si esegue il codice del database, si eseguono istruzioni LINQ (che vengono quindi tradotte in codice DB dal provider LINQ sottostante)

D'altra parte, come sottolinea il post di Matt Briggs, L2S è abbastanza strettamente accoppiato alla struttura del tuo database (una classe per tabella) e presenta dei limiti (ad esempio non ci sono molte mappe, e potresti essere migliore utilizzando L2S per l'accesso ai dati all'interno del repository, ma quindi mappare gli oggetti L2S sui propri oggetti del modello di dominio e restituirli.

Answer 2

Un repository dovrebbe essere l'unico pezzo dell'applicazione che sa qualcosa sulla tua tecnologia di accesso ai dati. Quindi non dovrebbe assolutamente restituire oggetti generati da L2S, ma mappare quelle proprietà per modellare oggetti propri.

Se stai usando questo tipo di pattern, potresti voler pensare a L2S. Genera un livello di accesso ai dati per te, ma in realtà non gestisce la mancata corrispondenza dell'impedenza, devi farlo manualmente. Se osservi qualcosa come NHibernate, tale mappatura viene eseguita in modo più robusto. L2S è più per un'applicazione a 2 livelli, dove vuoi un DAL veloce e sporco che puoi estendere facilmente.

Answer 3

Se stai usando LINQ, la mia convinzione è che il repository dovrebbe essere un contenitore per la tua sintassi LINQ. Ciò fornisce un livello di astrazione delle routine di accesso al database dall'interfaccia dell'oggetto modello. Come Dylan menziona sopra, ci sono altre opinioni sull'argomento, ad alcune persone piace restituire IQueryable in modo che possano continuare a interrogare il database in un secondo momento dopo il repository. Non c'è niente di sbagliato in nessuno di questi approcci, purché tu sia chiaro nei tuoi standard per la tua applicazione. Sono disponibili ulteriori informazioni sulle migliori pratiche che utilizzo per i repository LINQ qui.