github에 대한 질문을 EF 팀에 게시했습니다. 여기 에이 질문을하는 것이 더 낫다는 답장을 얻었으므로 다른 사람이 GitHub에 대한 몇 가지 답변을 볼 수 있도록 링크로 여기에 복사하여 붙여 넣을 것입니다.
질문 : 몇 가지 조사를하고 있는데 누군가 DBContext 클래스의 24 행에 나와 있습니다.
DbContext는 작업 단위 및 저장소 패턴의 조합입니다.
이는 더 이상 EF를 리포지토리로 추상화 한 다음 및 인터페이스를 사용하여 컨트롤러에 주입 할 필요가 없다는 것을 의미합니까?
Github의 원래 게시물 : https://github.com/aspnet/EntityFramework/issues/4899
내가 묻는 이유는 GetById, GetByName, GetWithIncludesABC, GetWithIncludes123 등과 같은 저장소에 많은 메소드를 추가하는 곳으로 들어가서 내 마음에 repo를 더럽히는 것처럼 보입니다.
답변
같은 저장소에 메소드를 추가하는 경우
GetById
GetByName
GetWithIncludesABC
GetWithIncludes123
그런 다음 서비스 계층으로 이동하여 서비스 계층에서 EF를 직접 사용하도록하는 것이 좋습니다 . EF는 이미 위의 방법과 비슷한 기능을 가지고 있으며 끝없이 복제하고 있습니다.
서비스 계층은 비즈니스 도메인 메소드를 노출하고 CRUD 를 사용 하여이를 구현합니다. 예를 들어, TransferMoney(A, B)A와 B가 계정을 확인하는 이라는 메소드가있을 수 있습니다. 이를 통해 비즈니스 도메인의 언어를 말할 수 있으며 서비스 계층은 CRUD를 처리합니다.
별도의 리포지토리 레이어를 원하는 위치를 생각할 수있는 유일한 이유는 해당 리포지토리 레이어를 조롱하거나 테스트 목적으로 다른 데이터 소스를 대체 할 수 있기 때문입니다.
답변
Robert Harvey는 그의 대답에서 다음과 같이 말했습니다.
별도의 리포지토리 레이어를 원하는 위치를 생각할 수있는 유일한 이유는 해당 리포지토리 레이어를 조롱하거나 테스트 목적으로 다른 데이터 소스를 대체 할 수 있기 때문입니다.
이것이 리포지토리 패턴이 여전히 관련이있는 이유입니다. 또한 리포지토리 패턴을 구현한다는 Entity Framework 팀의 주장에 동의하지 않습니다. Entity Framework는 여전히 데이터베이스와 밀접한 관련이 있습니다. 리포지토리 패턴의 전체 목적은 응용 프로그램에 사용 된 정확한 지속성 메커니즘을 분리하고 추상화하여 데이터 액세스 구현에서 리포지토리 계층 외부로 유출 되지 않도록하는 것 입니다.
일종의 서비스 객체와 같이 “리포지토리”외부에서 EF 쿼리 API를 사용하는 경우 패턴을 깨뜨리고 있다고 말할 수 있습니다.
이제 기능과 같은 데이터베이스가 다른 코드로 유출되는 것이 치명적인 문제가 아니며 향후 CRUD 작업 중 일부를 웹 서비스로 옮길 필요가 없다는 것을 보장 할 수 있다면 EF를 직접 사용하는 것이 확인.
기본적으로 Entity Framework는 리포지토리 패턴에서 게이트웨이 개체 를 대신합니다 . 나는 그것을 저장소 자체로 보지 않습니다.
답변
리포지토리가 필요하지 않은 것 같습니다. 샘플 백엔드 마이크로 서비스 응용 프로그램에서 Microsoft는 다음을 사용하지 않습니다.
https://github.com/Microsoft/BikeSharing360_BackendServices
샘플 BikeSharing 앱은 Connect ()에 표시되었습니다. 이벤트 (API 프로젝트의 템플릿으로 사용할 수 있다고 생각합니다) :
https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/