Приложение MVC3/уровень службы/уровень репозитория/классы POCO/EF4 — вопросы!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


person Sam    schedule 27.02.2011    source источник


Ответы (1)


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

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

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

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

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

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

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

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

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

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

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

Контроллер.

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

да.

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

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

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

да.

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

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

Равен ли бизнес-объект объекту предметной области?

да.

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

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

Внедрение зависимостей — стоит ли мне это использовать?

Да, конечно.

Я понимаю, как это работает, просто не получаю реальной пользы

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

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

Я согласен.

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

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

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

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

person Darin Dimitrov    schedule 27.02.2011
comment
arin - Если вы используете AutoMapper и DTO, являются ли DTO клонами классов POCO? Я имею в виду, что если бы, скажем, у меня было представление, которое собиралось отображать основную информацию о клиенте с набором адресов и заказов, я бы предположил, что модель представления будет иметь основные свойства клиента, а затем набор адресов и заказы. Будут ли эти коллекции свойствами объектов POCO, или мне нужно создать класс в приложении MVC, который имитирует классы порядка и адресов из POCO, и использовать их в модели представления? - person Sam; 28.02.2011
comment
@Darin - Является ли использование сгенерированных POCO классов из EF с использованием подхода «сначала модель» таким же, как и метод «сначала код», или слишком близко к нему? Классы POCO довольно голые. Посмотрите здесь: striano.net/Customer.vb.txt, это загрязнено ? - person Sam; 28.02.2011
comment
@Sam, если вам нужно представление, которое будет отображать основную информацию о клиенте с набором адресов и заказов, вы должны создать CustomerViewModel, которая будет содержать основные свойства, а также AddressViewModel и OrderViewModel, которые будут содержать свойства, которые вы хотели бы показать для данного клиента его адреса и заказы, а затем CustomerViewModel может иметь два свойства коллекции AddressViewModel и OrderViewModel. - person Darin Dimitrov; 28.02.2011
comment
Что касается моделей предметной области, то лично я определяю их вручную при анализе требований моего проекта и никогда не использую в качестве модели предметной области ничего автогенерируемого. Если вы используете что-то, что сгенерировано автоматически, это означает, что вы основываете свою логику домена на этом что-то, что, ИМХО, не очень хорошо. Вам решать проанализировать требования проекта и определить объекты предметной области. На более позднем этапе вы можете решить сопоставить свои модели с реляционной базой данных или приобрести API стороннего сервиса в Интернете или что-то еще. - person Darin Dimitrov; 28.02.2011
comment
@Darin - Значит, в случае заказов и адресов клиентов каждая запись получает модель представления? - person Sam; 28.02.2011
comment
@Darin - Помимо основ (имя, название компании, телефон, адрес электронной почты и т. д.), что еще вы бы добавили в объект домена клиента? - person Sam; 28.02.2011
comment
@Sam, в случае клиентов, заказов и адресов ваша модель просмотра может выглядеть так: public class CustomerViewModel { public string FirstName { get; set; } public IEnumerable<AddressViewModel> Addresses { get; set; } public IEnumerable<OrderViewModel> Orders { get; set; } }. А что касается объекта пользовательского домена, то это сложнее сказать, и это действительно будет зависеть от требований проекта или любой существующей кодовой базы, которую следует принимать во внимание. Если вы разрабатываете совершенно новое приложение, просто включите свойства, которые, по вашему мнению, будут полезны. - person Darin Dimitrov; 28.02.2011
comment
Также может помочь: weblogs.asp.net/shijuvarghese/archive/2011/01/13/ - person stormwild; 07.12.2011