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

Se stai aggiungendo metodi a un repository come

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Quindi è meglio che si sposti su Service Layer, e che il livello di servizio utilizzi direttamente EF. EF ha già funzionalità simili ai metodi precedenti che stai duplicando all'infinito.

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

L'unica ragione convincente che riesco a pensare a dove potresti voler avere un livello di repository separato è che puoi prendere in giro quel livello di repository o sostituire una fonte di dati diversa a scopo di test.

Robert Harvey ha detto nella sua risposta:

The only compelling reason I can think of where you might want to have a separate Repository Layer is so that you can mock that repository layer or substitute a different data source for testing purposes.

Questo è esattamente il motivo per cui il modello di deposito è ancora pertinente. Inoltre, non sono d'accordo con l'affermazione dei team di Entity Framework che implementano il Pattern del repository. Entity Framework è ancora molto legato a un database. L'intero scopo del modello di repository è quello di disaccoppiare e astrarre il meccanismo esatto di persistenza utilizzato nell'applicazione, in modo che nulla dall'implementazione di perdite di accesso ai dati al di fuori del livello del repository.

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

Ora, se non è un problema catastrofico per la funzionalità di database come perdite nell'altro codice, e puoi garantire che non dovrai spostare alcune delle tue operazioni CRUD in un servizio web in futuro, quindi utilizzare EF direttamente sarebbe OK.

In sostanza, Entity Framework prende il posto del oggetto Gateway in il modello di deposito. Non lo vedo come repository stesso.

I repository non sembrano necessari - Microsoft nelle loro applicazioni di microservizi di backend di esempio non li usa:

link

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

link