구체적인 서비스가 구체적인 저장소 또는 인터페이스에 의존해야합니까?

Question

저는 ASP.net MVC 및 Entity Framework를 사용하면서 한동안 저장소 및 서비스 패턴을 구현하는 데 어려움을 겪었습니다.

리포지토리 패턴의 목적과 리포지토리 패턴이 테스트에 도움이되는 방식을 이해하고 데이터 계층을 상호 교환 가능하게 만듭니다. 그러나 Entity Framework는 이미 저장소/작업 단위 패턴입니다. 필자가 보았던 저장소 패턴의 모든 구현은 EF를 제거하거나 유용한 기능을 제공하거나 IQueryable<T> 속성을 구현하여 순수 주의자들을 싫어하게 만듭니다.

내 서비스 계층에 대한 인터페이스를 작성한 경우 해당 서비스의 구체적인 버전을 구현하면 해당 서비스에서 직접 데이터 계층으로 Entity Framework를 사용하면 안되는 이유가 있습니다 (리포지토리에 배치하는 것과 반대)/작업 패턴의 단위와 종속성 삽입)? 예를 들어, IService 인터페이스를 생성 할 수 없으며 구체적인 EfService (Entity Framework) 또는 NhService (NHibernate 버전) 구현을 만들 수 있습니까?

그런 다음 원하는 IoC 컨테이너를 사용하여 원하는 서비스 및 데이터 컨텍스트를 주입 할 수 있습니다. https://github.com/sweeperq/Monona

방법 패턴이 구현되는 의미인가요 : 여기

---

함께 내가 세르게이의 의견에 따라 올 것을의 예입니다?

Answer 1

항상 저장소 인터페이스로 이동합니다.

첫 번째 이유는 테스트 가능성입니다. DbContext 및 DbSet<T>은 모의하기가 어렵습니다. 따라서 서비스의 단위 테스트는 가능하다면 정말 어려워집니다.

두 번째 이유는 EF에 노출 된 IQueryable<T>입니다. 이로 인해 데이터 액세스 로직이 전체 애플리케이션에 확산되어 SRP를 위반하고 수정 문제를 더욱 어렵게 만듭니다.

세 번째 이유는 실제 개체 및 모의뿐만 아니라 다른 데이터 액세스 프레임 워크와 함께 인터페이스 구현을 전환 할 수있는 능력이 그다지 중요하지 않을 수 있습니다. 당신은 항상 "아니오, 나는 분명히 EF를 고수 할 것입니다"라고 생각합니다. 하지만 현실 세계에서 성능 문제와 개발 용이성으로 인해 Dapper로 전환 한 경험이 있습니다. 그리고 일단 메모리 내 데이터 스토리지에서 EF로 전환 한 경험이있었습니다. 따라서 프레임 워크 별 API에 의존하는 대신 해당 옵션을 사용하는 것이 좋습니다.

네 번째 이유는 리포지토리가 제공하는 훌륭한 도메인 별 API입니다. db.Orders.Where(o => o.Category == "Food")과 같은 것 대신에 repository.GetOrdersByCategory이라는 좋은 방법이 있습니다.

또 다른 이유는 데이터 액세스 논리가 한 곳에서 제공된다는 것입니다. 중복 없음. 위의 예제에서 동일한 쿼리를 사용하여 범주별로 주문을 필터링하는 응용 프로그램의 5 개 위치를 가질 수 있습니다. 리포지토리를 사용하면 5 가지 위치에서 호출 될 단일 메서드가 있습니다. 비즈니스 규칙이 변경되면 어떻게해야합니까? 예 : 카테고리가 활성화되어 있는지 확인해야합니다.

UoW 및 Repository 기본 클래스와 인터페이스가 있으면 다른 프로젝트에서 다시 사용할 수 있습니다.