В конечном счете, нет идеального места для вашей бизнес-логики, кроме собственного уровня (как часть уровня «Модель»).Часто вы можете обойтись без другой реализации, но в каждом случае есть компромиссы.
Компромисс к созданию еще одного слоя для бизнес-логики заключается в том, что вы фактически должны инкапсулировать свой код.Если вы слишком агрессивны, вы также можете получить некоторое дублирование между вашими сущностями и моделью вашего домена (если реляционная семантика вашей БД уже позаботилась о вашей логике ведения бизнеса).
Просмотр
Представление является наиболее хрупкой частью вашего приложения, поскольку оно наиболее вероятно изменяется.
Также очень трудно получить правильную бизнес-логику в вашем представлении из-за необходимости поддержкивсе различные переходы состояний представлений.
В наши дни очень хорошо известно, что вы просто этого не делаете:)
Репозиторий
Здесь проблема заключается в поддержании и чистоте абстракции.Нарушение этого может сбить с толку людей и затруднить поддержку вашего приложения.
С из статьи EAA по шаблону репозитория :
Репозиторий является посредником междууровни отображения доменов и данных, действующие как коллекция объектов домена в памяти
Хранилище - это абстракция, представляющая хранилище данных в виде коллекции, в которой содержит объекты домена.
Никакая доменная логика не должна находиться в нем.Вместо этого он должен существовать в объектах вашего домена (по определению, поскольку ваша бизнес-логика является вашим доменом).
Чтобы сделать иначе (чтобы ваш репозиторий выполнял двойную функцию, а также проверял логику домена)) будет нарушением SRP ( принцип единой ответственности ) и будет пахнуть кодом.
У вас могут быть объекты домена более высокого уровня, которые работают с коллекциями объектов домена для проверки логики домена(например, зависимости в коллекции объектов, ограничения размера и т. д.).Они по-прежнему будут использовать ваши репозитории под прикрытием для окончательного хранения / извлечения объектов домена, поэтому они не будут выполнять двойную функцию (поэтому не будут нарушать SRP).
Контроллер
Контроллер также не подходит для размещения бизнес-логики.Задача контроллера - выполнять посредничество между контроллером и моделью.
Модель - это домен, а домен - это ваша бизнес-логика.
Entities
Возможно, вы захотите поместить данные домена в сущности.
Но вы должны быть осторожны при доступе к свойствам навигации, если сущности присоединены, так как вы можете инициировать непреднамеренные запросы или исключения БД (в зависимости от того, удаляется ли ваш контекст илине).Отсоединение их также является проблемой, так как оно разрушает ваш граф объектов, если вы явно не присоединяете объекты друг к другу после отсоединения их от контекста.
Если вы создаете отдельные классы модели предметной области, вы можете рассмотреть обработку сущностей как DTO * только 1060 *.
Редактировать: IValidatableObject
Я только что узнал о функции в Entity Framework 4.1, которую вы, возможно, захотите проверить:IValidatableObject interface.
Вы можете сделать ваши сущности частичными классами, а в частичном классе реализовать этот интерфейс.Когда вы это сделаете, Entity Framework при вызове вызовет Validate, и вы можете позвонить Validate всякий раз, когда это будет целесообразно для вас.
Это может помочь вам избежать отделения вашей модели персистентности от вашего домена.модель в дополнительных случаях.
См. эту статью: http://msdn.microsoft.com/en-us/data/gg193959
Примечание: виды / модели просмотра
Если вы думаете об этом, я предлагаю вам избежать соблазна передать сущности обратно в представление.Во многих случаях он ломается (например, сериализация Javascript для сохранения состояния просмотра) и в других случаях вызывает непреднамеренные запросы к БД.Вместо этого передайте простые типы (строки, целые, списки, хэш-наборы, словари и т. Д.) Или создайте классы модели представления для передачи в представление.