ASP.net 5 및 EF7에서 더 이상 리포지토리가 필요합니까?

github에 대한 질문을 EF 팀에 게시했습니다. 여기 에이 질문을하는 것이 더 낫다는 답장을 얻었으므로 다른 사람이 GitHub에 대한 몇 가지 답변을 볼 수 있도록 링크로 여기에 복사하여 붙여 넣을 것입니다.

질문 : 몇 가지 조사를하고 있는데 누군가 DBContext 클래스의 24 행에 나와 있습니다.

DbContext는 작업 단위 및 저장소 패턴의 조합입니다.

이는 더 이상 EF를 리포지토리로 추상화 한 다음 및 인터페이스를 사용하여 컨트롤러에 주입 할 필요가 없다는 것을 의미합니까?

Github의 원래 게시물 : https://github.com/aspnet/EntityFramework/issues/4899

내가 묻는 이유는 GetById, GetByName, GetWithIncludesABC, GetWithIncludes123 등과 같은 저장소에 많은 메소드를 추가하는 곳으로 들어가서 내 마음에 repo를 더럽히는 것처럼 보입니다.

asp.net-mvc entity-framework repository

— 로렌 도레 스
소스

rowanmiller가 준 대답에 대해 어떻게 생각 하십니까? 나에게 완벽하게 합당한 것 같습니다.

— Robert Harvey

@RobertHarvey 그렇습니다. 좋은 답변 이었지만 저장소에 대한 결정을 내리기 전에 다른 사람들

— 이이

Bogard가 비슷한 주장을하는 lostechies.com/jimmybogard/2009/09/11/wither-the-repository 도 참조하십시오 .

— mcknz

EF (및 기타 ORM) 가 리포지토리가 아닌 이유에 대해 설명 합니다 .

— Eric King

저장소에는 GetWithIncludesABC와 같은 메소드가 없습니다. 저장소 패턴은 기본적으로 데이터베이스 테이블을 콜렉션으로 추상화 한 것입니다. 일반적으로 컬렉션을 쿼리 할 수 있으며 (예 : LINQ) 리포지토리는 쿼리를 SQL로 변환합니다. 당신이 말하는 것은 데이터 게이트웨이처럼 들립니다.

— Mr Cochese

답변:

같은 저장소에 메소드를 추가하는 경우

GetById 
GetByName 
GetWithIncludesABC
GetWithIncludes123

그런 다음 서비스 계층으로 이동하여 서비스 계층에서 EF를 직접 사용하도록하는 것이 좋습니다 . EF는 이미 위의 방법과 비슷한 기능을 가지고 있으며 끝없이 복제하고 있습니다.

서비스 계층은 비즈니스 도메인 메소드를 노출하고 CRUD 를 사용 하여이를 구현합니다. 예를 들어, TransferMoney(A, B)A와 B가 계정을 확인하는 이라는 메소드가있을 수 있습니다. 이를 통해 비즈니스 도메인의 언어를 말할 수 있으며 서비스 계층은 CRUD를 처리합니다.

별도의 리포지토리 레이어를 원하는 위치를 생각할 수있는 유일한 이유는 해당 리포지토리 레이어를 조롱하거나 테스트 목적으로 다른 데이터 소스를 대체 할 수 있기 때문입니다.

— 로버트 하비
소스

그러나 당신은 dbset을 조롱 할 수 있습니다 ... msdn.microsoft.com/en-us/library/dn314429(v=vs.113).aspx

— S1r-Lanzelot

Robert Harvey는 그의 대답에서 다음과 같이 말했습니다.

별도의 리포지토리 레이어를 원하는 위치를 생각할 수있는 유일한 이유는 해당 리포지토리 레이어를 조롱하거나 테스트 목적으로 다른 데이터 소스를 대체 할 수 있기 때문입니다.

이것이 리포지토리 패턴이 여전히 관련이있는 이유입니다. 또한 리포지토리 패턴을 구현한다는 Entity Framework 팀의 주장에 동의하지 않습니다. Entity Framework는 여전히 데이터베이스와 밀접한 관련이 있습니다. 리포지토리 패턴의 전체 목적은 응용 프로그램에 사용 된 정확한 지속성 메커니즘을 분리하고 추상화하여 데이터 액세스 구현에서 리포지토리 계층 외부로 유출 되지 않도록하는 것 입니다.

일종의 서비스 객체와 같이 "리포지토리"외부에서 EF 쿼리 API를 사용하는 경우 패턴을 깨뜨리고 있다고 말할 수 있습니다.

이제 기능과 같은 데이터베이스가 다른 코드로 유출되는 것이 치명적인 문제가 아니며 향후 CRUD 작업 중 일부를 웹 서비스로 옮길 필요가 없다는 것을 보장 할 수 있다면 EF를 직접 사용하는 것이 확인.

기본적으로 Entity Framework는 리포지토리 패턴에서 게이트웨이 개체 를 대신합니다 . 나는 그것을 저장소 자체로 보지 않습니다.

— 그렉 버거 트
소스

리포지토리는 서비스 계층 측면과 어떻게 다릅니 까? 내가 IQueryable을 반환하는 경우 찾을 수있는 것에서 IEnumerable을 반환하는 경우 본질적으로 리포지토리이고 서비스 계층을 사용하여 메신저입니다. 이 올바른지? 서비스 계층 및 리포지토리 패턴은 유사합니까?

— Loren.Dorez

@ Loren.Dorez : 서비스 계층에는 및과 같은 비즈니스 도메인 별 방법이 있습니다. 리포지토리에는 CRUD 메소드 만 포함됩니다. TransferFunds()BuildWidget()

— Robert Harvey

그렇다면 서비스 계층과 리포지토리 모두 DBContext에 직접 액세스합니까? 따라서 CRUD를 Repo 및 Get Methods에 그리고 서비스 계층의 다른 메소드에 넣을 것입니까? 나는 이것을 올바르게 이해하고 있습니까?

— Loren.Dorez

서비스 계층 (있는 경우)은 EF 대신 직접 리포지토리에 액세스 할 수 있습니다.

— Robert Harvey

@RobertHarvey 위의 Get Methds를 사용하여 예를 보여줄 수 있습니까? 지금은 조금 혼란스러워 죄송합니다.

— Loren.Dorez

리포지토리가 필요하지 않은 것 같습니다. 샘플 백엔드 마이크로 서비스 응용 프로그램에서 Microsoft는 다음을 사용하지 않습니다.

https://github.com/Microsoft/BikeSharing360_BackendServices

샘플 BikeSharing 앱은 Connect ()에 표시되었습니다. 이벤트 (API 프로젝트의 템플릿으로 사용할 수 있다고 생각합니다) :

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

— 파벨 비류 코프
소스