ASP.NET MVC — модель в веб-проекте

Я новичок в ASP.NET MVC и унаследовал проект, использующий эту технологию.

Такой веб-проект содержит три папки: Views, Controllers и Model. Насколько я понимаю, Модель содержит по сути вашу доменную/бизнес-логику и вызывается вашими контроллерами. Сами контроллеры действуют как делегаторы между представлениями и моделью.

Теперь в типичной многоуровневой архитектуре ни в одном проекте не должно быть ссылок на проект Web/UI.

Я нахожу это довольно запутанным:
-> Пользовательский интерфейс содержит Модель, которая — в идеальном мире — основана на принципах «Domain Driven Design».
-> Слои поверх пользовательского интерфейса (Сервисы и DataAccess) не может иметь ссылку на пользовательский интерфейс

Как вы можете создавать эффективные сервисы и уровни доступа к данным, если они не знают вашу модель?

Что мне здесь не хватает? Отличается ли Web.Model от "DDD" и нужен ли мне отдельный проект BL? Если это так, то что должна содержать Web.Model?


person Laoujin    schedule 07.02.2013    source источник


Ответы (3)


Я рассматриваю Модель как концепцию. У вас может быть совершенно отдельный проект, содержащий ваш домен (ваши сущности, ваши службы и т. д.), и ссылаться на него в своем проекте "UI". В этом сценарии это будет ваша "Модель". Это то, что я обычно делаю. В папке "Модели" я храню "ViewModels", которые я использую для привязки/проверки (для пользовательского интерфейса). Например, если у меня есть сотрудник, но я не хочу использовать все его свойства (или, если уж на то пошло, разные свойства), я создам EmployeeViewModel настрою его так, как хочу, я добавлю проверку (если требуется) и я передам его своему представлению.

Это ни в коем случае не "правильный путь"/"единственный способ", но он работал у меня в прошлом, и я решил поделиться (к тому же, я довольно ужасен в объяснениях, поэтому я очень надеюсь, что этот пост имеет смысл, если это не так или нужны разъяснения - дайте мне знать).

person Dimitar Dimitrov    schedule 07.02.2013

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

Вот как я обычно настраиваю свои проекты

1) Проект пользовательского интерфейса. Это проект типа веб-приложения MVC, в котором у меня будут контроллеры, представления и другие элементы, связанные с пользовательским интерфейсом.

2) Бизнес-сущности. Это будет проект типа библиотеки классов, в котором я буду определять свои объекты домена (пример: клиент). В основном это похоже на то, как выглядит моя схема БД. Обычно это просто POCO, которые представляют мой модальный домен (я использую это для генерации базы данных CodeFirst).

3) Доступ к данным. Это будет еще один проект типа библиотеки классов, в котором есть классы доступа к данным. Обычно мой класс/интерфейсы репозитория, мой класс DBContext и другие классы доступа к данным будут в этом проекте.

4) Тесты — модульные тесты для проекта.

введите здесь описание изображения

Проект Business Entities был добавлен в качестве ссылки на проект доступа к данным, чтобы я мог использовать эти классы в своем коде доступа к данным.

Бизнес-сущности и проекты доступа к данным добавляются в качестве ссылок в проект пользовательского интерфейса. Я бы назвал методы доступа к данным из моих классов Controllers/Service.

Вы также можете добавить уровень сервисной/бизнес-логики между вашим контроллером и уровнем доступа к данным по мере необходимости.

У меня есть несколько классов ViewModel также в папке ViewModels моего проекта пользовательского интерфейса. Я использую это для некоторых экранов, где мне нужно показать данные из нескольких объектов домена. У меня есть класс сопоставления/обслуживания, который сопоставляет объект домена с объектом модели просмотра. Если ваш проект большой, вы можете сохранить его как отдельный проект с тем же решением.

person Shyju    schedule 07.02.2013

  • Представления содержат ваши макеты HTML
  • Контроллеры выполняют тяжелую работу по получению данных из моделей или самих моделей и передаче их в представления.
  • Модели используются для выполнения действий для вашего BL или извлечения данных.

Совет: вы можете использовать EntityFramework (я рекомендую его, потому что с ним легко начать работу) для извлечения ваших данных, и его очень просто настроить, что избавит вас от DAL и сэкономит ваше время от написания всего самостоятельно.

Сервисы: у вас могут быть контроллеры, которые возвращают XML/JSON (другой формат?), преобразовывая данные, полученные из БД, в XML/JSON и возвращая их вместо представления. Взгляните на MVC 4 WebApi для более подробной информации. Обратите внимание, что вы можете сделать то же самое и с mvc 3.

Также обратитесь к сайту asp.net/mvc, чтобы получить учебные пособия, которые помогут вам начать работу, они действительно полезны.

person Nikola Sivkov    schedule 07.02.2013