자주 피하는 디자인 패턴 : 리포지토리 패턴

디자인 패턴은 소프트웨어 디자인에서 직면 한 실제 문제에 대한 검증 된 솔루션을 제공합니다. 리포지토리 패턴은 애플리케이션에서 비즈니스 로직과 데이터 액세스 계층을 분리하는 데 사용됩니다.

데이터 액세스 계층에는 일반적으로 데이터 저장소에서 데이터를 처리하기위한 저장소 별 코드 및 메서드가 포함되어 있습니다. 리포지토리가 추상화하는 데이터 액세스 계층은 ORM (예 : Entity Framework 또는 NHibernate), XML 파일, 웹 서비스 등일 수 있습니다. SQL 문 모음 일 수도 있습니다.

리포지토리 디자인 패턴을 사용할 때 애플리케이션의 비즈니스 로직 계층은 그 아래에서 데이터 지속성이 어떻게 발생하는지에 대한 지식이 필요하지 않습니다. 기본적으로 리포지토리는 애플리케이션의 도메인과 데이터 매핑 계층 사이를 중재합니다. 데이터가 실제로 데이터 저장소 계층에 유지되는 방식에 대한 캡슐화를 제공해야합니다.

리포지토리 패턴은 엔터티가 많고 해당 엔터티와 작업 할 복잡한 쿼리가 많은 경우 유용 할 수 있습니다. 이 경우 추가 추상화 계층은 쿼리 논리의 중복을 제거하는 데 도움이 될 수 있습니다.

일반 저장소

일반 저장소는 CRUD 작업을 수행하기위한 일반 메소드 세트로 구성된 유형입니다. 그러나 이는 또 다른 안티 패턴이며 Entity Framework에서 자주 사용되어 데이터 액세스 계층에 대한 호출을 추상화합니다. 제 생각에는 일반 저장소를 사용하는 것은 너무 일반화입니다. 일반 리포지토리를 사용하여 Entity Framework에 대한 호출을 추상화하는 것은 좋지 않습니다.

예를 들어 설명하겠습니다.

다음 코드 목록은 일반 저장소를 보여줍니다. 여기에는 기본 CRUD 작업을 수행하기위한 일반 메서드가 포함되어 있습니다.

public interface IRepository

   {

       IEnumerable GetAll();

       T GetByID(int id);

       void Add(T item);

       void Update(T item);

       void Delete(T item);

   }

특정 저장소를 만들려면 아래 코드 목록에 표시된대로 일반 인터페이스를 구현해야합니다.

public class AuthorRepository : IRepository

   {

       //Implemented methods of the IRepository interface

   }

보시다시피 특정 저장소 클래스를 생성하려면 일반 저장소 인터페이스의 각 메소드를 구현해야합니다. 이 접근 방식의 주요 단점은 각 엔터티에 대해 새 저장소를 만들어야한다는 것입니다.

이 접근 방식의 또 다른 단점은 다음과 같습니다. 저장소 패턴의 기본 의도는 데이터 액세스 계층이 실제로 데이터를 유지하는 방식에서 도메인 계층을 분리하는 것입니다. 방금 생성 한 저장소 클래스의 업데이트 된 버전이 있습니다.

public class AuthorRepository : IRepository

   {

       private AuthorContext dbContext;

       //Methods of the IRepository interface

   }

이전에 제공된 코드 목록에서 볼 수 있듯이 AuthorRepository는 의도 된 CRUD 작업을 수행하기 위해 AuthorContext 인스턴스가 필요합니다. 그렇다면 디커플링은 어디에 있습니까? 이상적으로 도메인 계층은 지속성 논리에 대한 지식이 없어야합니다.

추가 추상화 계층

애플리케이션의 도메인 모델과 지속성 모델은 서로 다른 책임을 가지고 있습니다. 전자는 동작을 모델링합니다. 즉, 실제 문제와 해당 문제에 대한 솔루션을 모델링하는 반면, 후자는 애플리케이션의 데이터가 실제로 데이터 저장소에 저장되는 방식을 모델링하는 데 사용됩니다.

리포지토리 패턴의 의도는 지속성 논리를 추상화하고 데이터가 지속되는 방식의 내부 구현을 숨기는 것입니다. 저장소의 운영은 충분히 표현적이고 일반적이지 않아야합니다. 일반적인 저장소와 모든 시나리오에 맞는 작업을 포함 할 수있는 저장소는있을 수 없습니다. 이것은 불필요한 추상화가되어 일반 저장소 패턴을 안티 패턴으로 만듭니다. 모든 도메인 개체를 동일한 방식으로 모델링 할 수 있습니다. 일반 저장소는 의미있는 계약을 정의하지 않으므로 일반 저장소를 확장하고 해당 특정 엔터티에 의미있는 특정 작업 집합을 제공하는 특정 저장소가 다시 필요합니다.

이제 성숙 된 데이터 지속성 기술 (NHibernate, Entity Framework 등)이 꽤 많이 있으므로, 어쨌든이 추가 추상화 계층이 필요한 이유는 무엇입니까? 오늘날 사용 가능한 대부분의 성숙한 ORM 기술은 동일한 기능을 가지고 있습니다. 저장소를 사용하려고 할 때 이유없이 추상화 계층을 추가하기 만하면됩니다. 예를 들어 AuthorRepository에 대해 다음과 같은 메서드가 필요할 수 있습니다.

FindAuthorById()

FindAuthorByCountry()

점점 더 많은 방법과 복잡한 검색이 있으면 더 나빠집니다. 그 아래에서 사용중인 영구 저장소 레이어와 밀접하게 매핑되는 저장소를 갖게됩니다.