저장소 패턴의 제네릭을 사용하는 다형성

Question

특히 Façade 패턴을 구현하려고 할 때 C#의 저장소 패턴을 사용하는 데 문제가 있습니다. 내 개념은 다음과 같습니다.

처음으로 일반 저장소를 시작했을 때 모든 CRUD 작업이 하나의 파일 (및 관련 인터페이스가 별도의 단일 파일에 있음)로 시작했습니다. 하지만 솔리드 원칙과 특히 ISP 원칙 때문에 모든 인터페이스를 별도의 파일로 분리하고 클래스와 마찬가지로 수행하기로 결정했습니다.

예를 들어 하나의 파일에서 다양한 Create, Read ... 메소드 및 다른 GenericRepo와 함께 IGenericRepo를 사용하는 대신. 나는 공통점이있는 모든 것을하기 위해 기지 레포를 가지고 그들 모두를 분리했다. 그래서 나는 ICreateRepo, IReadOneRepo, IReadManyRepo ... 등으로 끝났습니다. ,

 public T Read(int id) 

을

• 을 지정된 ID로 하나의 레코드를 읽기 : 시간이 경과으로

  는 내 프로젝트의 요구가 성장하고, 나 자신이 작업은 "읽기"여러 필요 발견

  • 여러 값으로 전달해야하는 복합 원자가있을 수있는 단일 레코드를 읽습니다. EF Find Method ...와 같이 작동합니다.

     public T Read(params object[] keyValues) 
    

    • 반환

    EF의 같은 모든 필드에서 검색을 기반으로 최초의 기록을 ... 어디 매개 변수와 같은했다 방법, ...

   public T Read(Expression<Func<T>,bool>> predicate) 
  

  내가 필요한 상황을 발견 할 때까지는 괜찮 았어. 여러 레코드를 읽고 해당 조건과 일치하는 모든 레코드 목록을 반환합니다. 본질적으로 읽기 연산은 마지막에 언급 한 것과 동일한 메소드 서명을 가지며 리턴 유형 만 다릅니다. 하나는 단일 엔티티를 반환하고 다른 엔티티는 일치하는 엔티티 목록을 반환했습니다.

  고유 한 클래스로 구분되는 동안 아무런 문제가 없습니다. 그러나 나는 MVC를 사용하는 컨트롤러에서 6 개 또는 9 개의 저장소에 대한 긴 목록을 발견했으며,이를 단일 일반에 대한 것과 같이 단순화하고자했습니다. 그래서 저는 Façade 패턴으로 돌아 섰습니다.

  이제 읽기 기능을 가져 오면 서명이 동일하기 때문에 다형성 문제가 발생합니다.

  //ReadOne 1 
      public T Read(int id) 
      { } 
      //ReadOne 2 
      public T Read(params object[] keyValues) 
      { } 
      //ReadOne 3 *** Signature same as search except for return type. 
      public T Read(Expression<Func<T, bool>> predicate) 
      { 
       //SingleOrDefault used purposefully instead of FirstOrDefault to cause exception if 
       //there is more than one instance that meets the predicate. 
       return dbSet.Where(predicate).SingleOrDefault<TEntity>(); 
      } 
  
      //Search 
      public IQueryable<T> Read(Expression<Func<T, bool>> predicate) 
      { 
       return dbSet.Where(predicate); 
      } 
  
      //ReadAll 
      public IQueryable<T> Read() 
      { } 
  

  언급 한 바와 같이 ... 별도의 파일로 분리 된 경우 필요에 따라 명시 적으로 호출되므로 별개의 파일로 구분됩니다. 그러나 Façade 패턴을 사용하여 코드를 단순화하고자합니다.

  나는 물론 반환 유형에 따라 다형성이 없다는 문제가 있습니다. 나는 이것을 이해하고 그 이유를 충분히 이해한다.

  검색 끝에 선택적 bool 매개 변수를 추가하려고 생각했습니다. 그러나 그것은 어떤 이유로 든 기분이 좋지 않습니다. 뭔가가 ...

  //Search 
      public IQueryable<T> Read(Expression<Func<T, bool>> predicate, bool returnOne = false) 
      { } 
  

  내 질문은이 제한 사항을 해결하는 방법에 대한 아이디어가 있습니까?

Answer 1

Read을 반환하는 단일 엔터티 이름을 ReadSingle으로 바꿀 수 있습니다. 이는 조건자를 매개 변수로 사용하더라도 단일 엔터티 만 반환한다는 것을 명확히합니다. 의 이름을 먼저 변경하려고합니다..

다른 옵션을 원하면 매개 변수의 메소드 서명을 구분할 수 있습니다. 당신은 단일 반환 괴짜 경우에 대한 술어 래퍼 유형을 만들 수 있습니다 변환 연산자 감안할 때

public class ExpressionToFindSingle<T> { 
    private Expression<Func<T, bool>> predicate; 
    public ExpressionToFindSingle(Expression<Func<T, bool>> predicate) { 
    this.predicate = predicate; 
    } 
    public static implicit operator Expression<Func<T, bool>>(ExpressionToFindSingle<T> wrapper) { 
    return wrapper.predicate; 
    } 
} 

, 당신은 직접 술어로 래퍼를 사용할 수 있습니다. 발신자 이후

T Read(ExpressionToFindSingle<T> predicate); 

IQueryable<T> Read(Expression<Func<T, bool>> predicate); 

Answer 2

IQueryable 만 반환합니다. 엔티티가 하나만 반환되는 경우도 있습니다. IQueryable에 하나의 레코드 만 있으면 어떻게됩니까? 나는 내가 추측 할 필요성을 보지 않고있다 ..

당신의 매개 변수와 같은 것. 왜 당신은 단일 대 배열에 대한 명시적인 경우가 필요합니까? 그냥 배열을 가지고.

returnOne 플래그는 전혀 의미가 없습니다. 이쪽을 봐 ... 네가 돌아올 수 있을까? 두? returnThree? 아니오. 그 시점에서 디자인에 결함이 있기 때문입니다. 또한 이것이 패턴을 참조 할 필요가 없다는 다른 의견에 동의합니다. 실제로 이것은 모범 사례 문제입니다.