Os Repositórios são necessários por mais tempo no ASP.net 5 e EF7?

Publiquei uma pergunta no github para a equipe EF. Eu recebi uma resposta dizendo que seria melhor fazer esta pergunta aqui, então eu a copio e colo aqui como nós, como um link para que outros possam ver as poucas respostas no GitHub.

Pergunta: Eu estava pesquisando e alguém apontou que a Linha 24 da classe DBContext declara

DbContext é uma combinação dos padrões de Unidade de Trabalho e Repositório.

Isso significa que não precisamos mais abstrair o EF de um repositório e, em seguida, usar a Interface para injetá-lo nos controladores?

Post original no Github: https://github.com/aspnet/EntityFramework/issues/4899

A razão pela qual pergunto isso é que parece que estou adicionando muitos métodos ao repositório como GetById, GetByName, GetWithIncludesABC, GetWithIncludes123, etc. e parece estar sujando o repositório em minha mente

asp.net-mvc entity-framework repository

— Loren.Dorez
fonte

O que você acha da resposta que rowanmiller deu? Parece perfeitamente razoável para mim.

— Robert Harvey

@RobertHarvey Sim, foi uma resposta boa, mas eu quero ver como os outros se sentem sobre o assunto antes de tomar uma decisão de repositório ou não

— Loren.Dorez

veja também lostechies.com/jimmybogard/2009/09/11/wither-the-repository, onde Bogard discute da mesma forma.

— Mcknz

Minha opinião sobre por que EF (e outros ORMs) não são repositórios .

— Eric King

Um repositório não teria um método como GetWithIncludesABC. O padrão do repositório é uma abstração de, basicamente, uma tabela de banco de dados como uma coleção. Geralmente, é possível consultar a coleção (por exemplo, por LINQ), e o repositório converte a consulta em SQL. O que você está falando soa mais como um Data Gateway.

— Sr. Cochese

Respostas:

Se você estiver adicionando métodos a um repositório como

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

Então é melhor mudar para uma Camada de Serviço e permitir que a Camada de Serviço use EF diretamente. A EF já possui uma funcionalidade semelhante aos métodos acima, que você está duplicando infinitamente.

Uma camada de serviço expõe os métodos de domínio comercial e usa o CRUD para implementá-los. Por exemplo, você pode ter um método chamado TransferMoney(A, B), em que A e B estão em contas correntes. Isso permite que você fale o idioma do seu domínio comercial, enquanto a Camada de Serviço lida com o CRUD para você.

A única razão convincente em que posso pensar onde você pode querer ter uma Camada de Repositório separada é para poder zombar dessa camada de repositório ou substituir uma fonte de dados diferente para fins de teste.

— Robert Harvey
fonte

No entanto, você pode zombar dbset ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx

— S1R-Lanzelot

Robert Harvey disse em sua resposta:

A única razão convincente em que posso pensar onde você pode querer ter uma Camada de Repositório separada é para poder zombar dessa camada de repositório ou substituir uma fonte de dados diferente para fins de teste.

É exatamente por isso que o Padrão de Repositório ainda é relevante. Também discordo da afirmação das equipes do Entity Framework de que elas implementam o Padrão de Repositório. O Entity Framework ainda está muito vinculado a um banco de dados. Todo o objetivo do Padrão de Repositório é desacoplar e abstrair o mecanismo de persistência exato usado em seu aplicativo, para que nada da implementação do acesso a dados vaze fora da camada de repositório.

Se você estiver usando a API de consulta EF fora do "repositório", como em um objeto de serviço de algum tipo, eu diria que está quebrando o padrão.

Agora, se não for um problema catastrófico a funcionalidade de um banco de dados vazar para seu outro código, e você pode garantir que não precisará mover algumas de suas operações CRUD para um serviço da Web no futuro, usar o EF diretamente seria ESTÁ BEM.

Basicamente, o Entity Framework substitui o objeto Gateway no Repository Pattern. Não o vejo como um repositório em si.

— Greg Burghardt
fonte

Como o Repositório difere de um aspecto da Camada de Serviço? pelo que posso descobrir se estou retornando IQueryable, então sou essencialmente um Repositório se estou retornando IEnumerable e estou usando uma camada de serviço. Isso está correto? Os padrões da camada de serviço e do repositório são semelhantes?

— Loren.Dorez

@ Loren.Dorez: Uma Camada de Serviço possui métodos específicos de Domínio de Negócios, como TransferFunds()e BuildWidget(). Um Repositório contém apenas métodos CRUD.

— Robert Harvey

Então, tanto uma Camada de Serviço quanto um Repositório acessariam diretamente o DBContext? Então você colocaria o CRUD nos métodos Repo e Get e outros métodos na camada de serviço? Estou entendendo isso corretamente?

— Loren.Dorez

A Camada de Serviço pode acessar o Repositório, se você tiver um, em vez do EF diretamente.

— Robert Harvey

@RobertHarvey Você pode me mostrar um exemplo usando os métodos Get acima? Como agora estou um pouco confuso desculpe.

— Loren.Dorez

Os repositórios parecem não ser necessários - a Microsoft em seus aplicativos de microsserviços de amostra não os utiliza:

https://github.com/Microsoft/BikeSharing360_BackendServices

O aplicativo BikeSharing de amostra foi mostrado em Connect (); evento (acho que pode ser usado como modelo para projetos de API):

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

— Pavel Biryukov
fonte