I repository sono più necessari in ASP.net 5 e EF7?

Ho inviato una domanda su github al team EF. Ho ricevuto una risposta dicendo che sarebbe meglio porre questa domanda qui, quindi la copierò e incollerò qui come noi in modo che altri possano vedere le poche risposte su GitHub.

Domanda: stavo facendo alcune ricerche e qualcuno ha sottolineato che la riga 24 della classe DBContext afferma

DbContext è una combinazione dei pattern Unit Of Work e Repository.

Ciò significa che non è più necessario estrarre EF in un repository e quindi utilizzare e l'interfaccia per iniettarlo nei controller?

Post originale su Github: https://github.com/aspnet/EntityFramework/issues/4899

Il motivo per cui lo chiedo è che mi sembra di entrare in un punto in cui sto aggiungendo molti metodi al repository come GetById, GetByName, GetWithIncludesABC, GetWithIncludes123, ecc. E sembra sporcare il repository nella mia mente

asp.net-mvc entity-framework repository

— Loren.Dorez
fonte

Cosa ne pensi della risposta di Rowanmiller? Mi sembra perfettamente ragionevole.

— Robert Harvey,

@RobertHarvey Sì, è stata una buona risposta, ma voglio vedere come si sentono gli altri sull'argomento prima di prendere una decisione sul repository oppure no

— Loren.Dorez,

vedi anche lostechies.com/jimmybogard/2009/09/11/wither-the-repository in cui Bogard discute allo stesso modo.

— Mcknz,

La mia opinione sul perché EF (e altri ORM) non sono repository .

— Eric King,

Un repository non avrebbe un metodo come GetWithIncludesABC. Il modello di repository è un'astrazione, in sostanza, di una tabella di database come raccolta. Di solito, è possibile eseguire una query sulla raccolta (ad esempio tramite LINQ) e il repository converte quindi la query in SQL. Quello di cui stai parlando sembra più un Data Gateway.

— Sig. Cochese,

Risposte:

Se stai aggiungendo metodi a un repository come

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Quindi è meglio passare a un livello di servizio e lasciare che il livello di servizio utilizzi direttamente EF. EF ha già funzionalità simili ai metodi di cui sopra che stai solo duplicando all'infinito.

Un livello di servizio espone i metodi del dominio aziendale e utilizza CRUD per implementarli. Ad esempio, potresti avere un metodo chiamato TransferMoney(A, B), in cui A e B stanno controllando i conti. Ciò ti consente di parlare la lingua del tuo dominio aziendale, mentre il livello di servizio gestisce il CRUD per te.

L'unico motivo convincente che mi viene in mente dove potresti voler avere un livello repository separato è in modo da poter deridere quel livello repository o sostituire una diversa origine dati a scopo di test.

— Robert Harvey
fonte

Tuttavia si può prendere in giro dbset ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx

— S1R-Lanzelot

Robert Harvey ha detto nella sua risposta:

L'unico motivo convincente che mi viene in mente dove potresti voler avere un livello repository separato è in modo da poter deridere quel livello repository o sostituire una diversa origine dati a scopo di test.

Questo è esattamente il motivo per cui il modello di deposito è ancora rilevante. Non sono inoltre d'accordo con l'affermazione dei team di Entity Framework secondo cui implementano il modello di deposito. Entity Framework è ancora molto legato a un database. Lo scopo del modello di repository è di disaccoppiare e sottrarre l'esatto meccanismo di persistenza utilizzato nell'applicazione, in modo che nulla dall'implementazione dell'accesso ai dati fuoriesca al di fuori del livello di repository.

Se si utilizza l'API della query EF al di fuori del "repository", come in un oggetto di servizio di qualche tipo, direi che stai interrompendo il modello.

Ora, se non è un problema catastrofico per la funzionalità del database come infiltrarsi nel tuo altro codice e puoi garantire che non dovrai spostare alcune delle tue operazioni CRUD su un servizio Web in futuro, allora l'utilizzo di EF direttamente sarebbe OK.

Fondamentalmente, Entity Framework prende il posto dell'oggetto Gateway nel modello di repository. Non lo vedo come un repository stesso.

— Greg Burghardt
fonte

In che modo Repository differisce da un aspetto del livello di servizio? da quello che posso trovare se sto restituendo IQueryable, quindi sono essenzialmente un repository se sto restituendo IEnumerable, quindi sto usando un livello di servizio. È corretto? I livelli di servizio e i modelli di repository sono simili?

— Loren.Dorez,

@ Loren.Dorez: un livello di servizio ha metodi specifici del dominio aziendale, come TransferFunds()e BuildWidget(). Un repository contiene solo metodi CRUD.

— Robert Harvey,

Quindi sia un livello di servizio che un repository accederanno direttamente a DBContext allora? Quindi inseriresti il CRUD nel metodo Repo e Get e altri metodi nel livello di servizio? Lo capisco correttamente?

— Loren.Dorez,

Il livello di servizio potrebbe accedere al repository, se ne hai uno, invece di EF direttamente.

— Robert Harvey,

@RobertHarvey Puoi mostrarmi un esempio usando Get Methds sopra? Come ora mi dispiace un po 'confuso.

— Loren.Dorez,

I repository non sembrano necessari: Microsoft nelle loro applicazioni di microservizi di back-end di esempio non li utilizza:

https://github.com/Microsoft/BikeSharing360_BackendServices

L'app BikeSharing di esempio è stata mostrata su Connect (); evento (penso che possa essere utilizzato come modello per progetti API):

https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/

— Pavel Biryukov
fonte