Приложение MVC3 / Сервисный уровень / Уровень репозитория / Классы POCO / EF4 - Вопросы!

Question

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

Шаблон, который я использую, похож на этот и предполагает следующий процесс:

Приложение MVC
Контроллер (-ы) обрабатывают запрос / ответ от клиента для данного представления.Внутри методов действия контроллеров они связываются со службами (Service Layer) и либо запрашивают объекты для построения моделей представления, и отправляют объекты из моделей представления обратно.

Модели представления
Я использую строго типизированные модели представления для и из видов.

Являются ли модели видов DTO?Если они содержат только простые свойства, такие как Name, AddressLine1, Address City и т. Д., Или если они содержат сложные свойства, несколько объектов и т. Д.

Является ли проверка в модели представления.Если это так, будет ли это проверка, например, обязательные поля, длина поля и т. Д. Тогда проверка, такая как имя пользователя, уже существует, или где вам нужно будет взаимодействовать с другими объектами на уровне обслуживания?

Могут ли модели представления просто содержатьклассы POCO, возвращенные из EF, или я должен использовать AutoMapper?

Если используются AutoMapper и DTO, являются ли клоны DTO классами POCO?

Будете ли вы отображать в контроллере, просматривать модельили на уровне сервисов ниже?

Сервисы
Для меня сервис (ы) - это объекты, которые обращаются к репозиторию (ам) для получения объектов POCO из EF.Вот где вся моя бизнес-логика.Как только служба передает объект обратно в хранилище для сохранения в EF, они считаются допустимыми объектами.Это правильно?

Репозитории
В них нет бизнес-логики, они просто используются для транспортировки объектов между сервисом (ами) и EF.Это правильно?Я реализую интерфейсы здесь с общим хранилищем.Тогда вы могли бы расширить общий репозиторий для особых нужд?

Вопросы по терминологии
1) Соответствует ли бизнес-объект объекту домена?Сколько логики должно содержать объект домена?

2) Является ли модель домена моделью EF?Я использую подход Model-First.

3) Внедрение зависимостей - Должен ли я использовать это?Я понимаю, как это работает, просто не получаю реальную выгоду.Я играл с Ninject.

Я думаю, что сообщество получило бы пользу от какой-то вики, которая содержала бы все лучшие практики с примерами кода.Есть ли что-то подобное там?Многие примеры очень просты, и многие образцы Microsoft не используют этот шаблон, даже когда заявляют.

Заранее спасибо всем, кто имеет и поможет мне в этом.

Кстати: я думаю, что StackOverflow нужно немного нажать кнопку «Купить мне пиво» ​​рядом с флажком «Принять ответ»:)

Answer 1

Являются ли модели представления DTO?

Можно рассматривать как объект передачи данных между контроллером и представлением.

Должны ли они содержать простосвойства, такие как Name, AddressLine1, Address City и т. д., или они должны содержать сложные свойства, несколько объектов и т. д.

Идеально простые свойства, но они также могут объединять другие модели представления, но не модели (например:Модели EF).

Является ли проверка в модели представления.

Существует два типа логики проверки: проверка бизнеса (например, имя пользователя уже существует), которая входит всервисный уровень и проверка пользовательского интерфейса (например, требуется имя пользователя), которая входит в модель представления.

Могут ли модели представления просто содержать классы POCO, возвращенные из EF, или мне следует использовать AutoMapper?

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

Если используются AutoMapper и DTO, являются ли клоны DTO классов POCO?

Не уверен, что я понимаю этот вопрос.

Хотели бы вы отобразить карту в контроллере, посмотреть модель или в слое обслуживания ниже?

Контроллер.

Для меня сервис (ы) - это объекты, которые обращаются к репозиторию (ам) для получения объектов POCO из EF.Вот где вся моя бизнес-логика.Как только служба передает объект обратно в хранилище для сохранения в EF, они считаются допустимыми объектами.Это правильно?

Да.

Является ли модель домена моделью EF?

Если вы используете EF Code первым подходом, тода, в противном случае нет (если EF загрязняет домен определенными атрибутами и классами EF).

В них нет бизнес-логики, они просто используются для передачи объектов между службой (службами) иEF.Это правильно?

Да.

Я реализую здесь интерфейсы с общим репозиторием.Тогда вы могли бы расширить общий репозиторий для особых нужд?

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

Соответствует ли бизнес-объект объекту домена?

Да.

Сколько логики должно содержать объект домена?

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

Внедрение зависимостей - Должен ли я использовать это?

Да, абсолютно.

Я понимаю, как это работает, просто не понимаюВыгода

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

Я думаю, что сообщество будетвоспользоваться какой-то вики, которая содержит все лучшие практики с примерами кода.

Согласен.

Есть ли что-то подобное?

Я сомневаюсь в этом.

Кстати - мне кажется, StackOverflow нужно немного, кнопка "Купить мне пиво" рядом с флажком "Принять ответ"

Не могу согласиться.