MVC - доменная служба берет на себя ответственность за фильтрацию или уровень репозитория?

Question

Должен ли я фильтровать результаты IQueryable в доменной службе?

Например ... Мои 3 порталы (сайты) доступ к той же службы домена слой, в зависимости от типа пользователя, то есть, я называю конкретный метод хранилища и возвращает результат,

Текущий Repository слой:

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

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

было бы лучше всего сделать это в Repository Layer:

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

Тогда в службу домена, я просто сделать фильтр т.е.

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

ПРИМЕЧАНИЕ. У меня есть сеанс и сессия только для чтения, которая включает CRUD в пределах уровня хранилища, поэтому, пожалуйста, имейте это в виду при ответе.

Второй вопрос: Должен ли я вообще выполнять фильтрацию на уровне службы домена? Этот слой является единственным слоем, чем может изменить объект, т. Е. Product.Price == 25.00; Это не делегируется слою репозитория.

Answer 1

Обычно я использую слой репозитория для выполнения простой работы с CRUD, а уровень домена выполняет любую бизнес-логику или в вашем случае любую фильтрацию, которая необходима, прежде чем передавать эти данные обратно на уровень пользовательского интерфейса.

Разделение логики бизнеса/фильтрации с уровня хранилища поможет сохранить чистоту. Кроме того, в будущем, если вы перейдете к другому типу доступа к данным, вам не придется изменять способ работы этого кода, поскольку он будет разделен на вашем доменном уровне.

Answer 2

Харун,

Я использую методы расширения на IQueryable<Classes> СНАРУЖИ репо. на самом деле, у меня есть набор классов, которые я называю «Filters», и они, как правило, что-то вдоль этих линий:

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"); 

Я считаю, это хорошее разделение логики и держит репо чистый. И в ответ на второй вопрос, да, используйте эту логику фильтра/расширения внутри уровня сервиса, а не репо.

Answer 3

У меня был такой же вопрос. Моя нерешительность заключается в том, что в некоторых случаях процесс фильтрации мог удалить большую часть записей, возвращаемых из репо, и я не хотел извлекать больше данных, чем необходимо из базы данных.

Я переехал в NHibernate, и мои методы хранилища принимали аргументы DetachedCriteria. Затем я передал пользовательскую информацию на уровень сервиса и выполнял фильтрацию, не манипулируя IQueryable, а создавая объект DetachedCriteria и передавая его вместе с репо, тем самым изменяя SQL и ограничивая работу базы данных.

До сих пор это работало очень хорошо, и «чувствует» себя правильно, так как у меня есть моя логика довольно прочно в сервисном слое с репо, выполняющим только базовый CRUD.