Биз логика в репозитории / модели окей? - PullRequest
Новая
       22

Биз логика в репозитории / модели окей?

3 голосов
/ 21 февраля 2012

Если у вас есть бизнес-правило, согласно которому первые 30 элементов в таблице никогда не будут видны пользователю (или пользовательскому интерфейсу), следует ли поместить этот фильтр в GetAll () репозитория?Имеется в виду, будет ли репозиторий обрабатывать фильтрацию данных, формирование данных для передачи обратно вызывающей стороне, как ViewModel или Controller?Я слышал, что модели должны быть толстыми, а контроллеры / vms должны быть легкими.

Проблема, с которой я сталкиваюсь, заключается в том, что другой разработчик, который делится со мной проектом, заставил все свои репозитории (по одному на таблицу) просто использовать одну и ту же реализацию, которая просто копирует свойства типа LinqToSql в доментип.В самом хранилище нет логики, кроме обновления и удаления или получения данных с помощью поставляемого Func.

С другой стороны, я создал репозиторий (который унаследован от IRepository of T) для каждой таблицы и поместил определенную логику в некоторые (не все), где я чувствовал, что логика необходима для возврата объектов домена.

Таким образом, в моем случае бизнес-логика может быть сделана в хранилище, в его случае это должен делать пользователь, который может быть службой или ViewModel напрямую.Что является более предпочтительным?

1 Ответ

6 голосов
/ 21 февраля 2012

Если у вас есть бизнес-правило, согласно которому первые 30 элементов в таблице никогда не будут видны пользователю (или пользовательскому интерфейсу), следует ли поместить этот фильтр в GetAll () репозитория?

Прежде всего, это не похоже на правило business . Бизнес-правила выражены на вездесущем языке , и в этом языке нет таких слов, как «таблица», если вы не работаете с ядром базы данных.

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

Домен: 

// repository interface:
public interface Orders{ 
   IList<Order> GetDelinquent();
}

Доступ к данным: 

public SqlOrders : Orders{ 
   IList<Order> GetDelinquent(){
      // do whatever needs to be done to find
      // delinquent orders in sql database.
      // filter first 30 records for example
   }
}

Обратите внимание, что интерфейс репозитория фокусирует домен (мы не говорим ' все, кроме первых 30 записей ', мы говорим ' delinquent ').

Проблема, с которой я сталкиваюсь, заключается в том, что другой разработчик, который делится со мной проектом, заставил все его репозитории (по одному на таблицу) просто использовать одну и ту же реализацию, которая просто копирует свойства типа LinqToSql в тип домена. В самом хранилище нет логики, кроме обновления, удаления или получения данных с помощью поставляемого Func.

С другой стороны, я создал репозиторий (который унаследован от IRepository of T) для каждой таблицы и поместил определенную логику в некоторые (не во все), где я чувствовал, что логика необходима для возврата объектов домена.

Общий интерфейс репозитория обычно плохая идея, он слишком ориентирован на данные, слишком CRUDy, пожалуйста, смотрите этот ответ для деталей и ссылок.

Так, в моем случае, бизнес-логика могла бы быть сделана в хранилище, в его случае это должен был сделать пользователь, который мог бы быть службой или ViewModel напрямую. Что является более предпочтительным?

Существует большая разница между бизнес-логикой и логикой доступа к данным. Вы хотите избежать использования бизнес-логики в реализации репозитория. Эта логика принадлежит объектам домена.

...