MVC - 도메인 서비스가 필터링을 담당하거나 저장소 계층을 수행합니까?

Question

도메인 서비스에서 IQueryable 결과를 필터링해야합니까? 예를 들어

... 내 3 개 포털 (웹 사이트), 그것은, 내가 특정 저장소 메서드를 호출하고 결과를 돌려 주어 사용자의 유형에 따라

현재 저장소 레이어 같은 도메인 서비스 레이어에 액세스 : 내가즉 필터를 할 간단하고, 도메인 서비스에서 다음

IQueryable<Products> GetAllProducts(); 
    Products GetAProduct(product id); 

:

IQueryable<Products> GetAllProductsForCrazyUserNow(CrazyUser id); 
    Products GetAProductForCrazyUserNow(CrazyUser id,product id); 

    IQueryable<Products> GetProductsForNiceUserNow(NiceUser id); 
    Products GetProductsForNiceUserNow(NiceUser id,product id); 

은 그냥 저장소 계층에서이 작업을 수행하는 가장 좋은 것입니다

var Niceman = IQueryable<Products> GetAllProducts().Where(u=> u.Name == "Nice"); 

참고 : Repository Layer 내에 CRUD가 포함 된 읽기 전용 세션 및 세션이 있으므로 응답 할 때 유의하시기 바랍니다.

두 번째 질문 : 도메인 서비스 계층에서 필터링을해야합니까? 이 바로 레이어는 엔티티 즉 Product.Price == 25.00을 수정할 수있는 유일한 레이어입니다. 이것은 저장소 계층에 위임되지 않습니다.

Answer 1

일반적으로 저장소 계층을 사용하여 간단한 CRUD 작업을 수행하고 도메인 계층에서 비즈니스 로직을 수행하거나 사용자의 경우 해당 데이터를 UI 계층으로 다시 전달하기 전에 필요한 필터링을 수행해야합니다.

리포지토리 계층에서 비즈니스/필터링 논리를 분리하면 일을 깨끗하게 유지하는 데 도움이됩니다. 또한 앞으로 다른 유형의 데이터 액세스 패턴으로 이동하면 코드가 도메인 계층에서 분리되어 작동하는 방식을 변경할 필요가 없습니다.

Answer 2

하운,

은 내가 REPO의 IQueryable<Classes> 외부에 확장 방법을 사용합니다. 사실, 나는 '필터'를 부르는 클래스의 집합을 가지고 그들은 일반적으로이 라인을 따라 뭔가 있습니다

가

public static class ProductFilters 
{ 
    public static IQueryable<Products> NiceMan(
     this IQueryable<Products> customQuery, string filterName) 
    { 
     if (!string.IsNullOrEmpty(filterName)) 
      customQuery = customQuery.Where(u => u.Name == filterName); 
     return customQuery; 
    } 
    // create lots of other Products based filters here 
    // and repeat with seperate IQueryable<Classes> per type 
} 

사용 :

var Niceman = IQueryable<Products> GetAllProducts().NiceMan("Nice"); 

나는이에게 논리의 좋은 분리를 발견하고는 유지 레포는 깨끗해. 그리고 두 번째 질문에 대한 답변으로, 예, repo가 ​​아닌 서비스 계층 내부에서이 필터/확장 논리를 사용하십시오.

Answer 3

나는 이와 동일한 질문을 스스로했습니다. 서비스 레이어에 넣는 것에 주저함은 어떤 경우 필터링 프로세스가 repo에서 반환 된 대량의 레코드를 제거 할 수 있으며 데이터베이스에서 필요한 것보다 많은 데이터를 가져 오지 않기를 바랬다는 것입니다.

나는 NHibernate로 옮겨 갔고, 내 저장소 메소드는 DetachedCriteria 인수를 받아 들였다. 그런 다음 사용자 정보를 서비스 계층에 전달하고 IQueryable을 조작하지 않고 DetachedCriteria 개체를 생성하고 repo에 전달하여 SQL을 수정하고 데이터베이스 작업을 제한함으로써 필터링을 수행했습니다.

지금까지는 기본 CRUD를 수행하는 repo를 사용하여 서비스 계층에서 내 논리를 견고하게 유지했기 때문에 꽤 잘 작동하고 "느낀다"고 생각됩니다.