Какова разбивка всех уровней, требуемых / рекомендуемых для приложения Asp.Net Mvc в соответствии с лучшими практиками программирования? - PullRequest
8 голосов
/ 14 июля 2009

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

Это начинает немного сбивать с толку, потому что некоторые новые слои, кажется, не вписываются так же легко, как другие, которые я выучил. Поэтому я просто хотел, чтобы кто-то прошел через все необходимые / рекомендуемые уровни для приложения Asp.Net MVC - для чего они служат и как взаимодействуют с другими уровнями.

Вот несколько слоев, которые я нашел, и как они соединяются: (Некоторые из них могут ошибаться)

View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB

Может ли кто-нибудь пройтись по тем, кого я могу пропустить, как они все связаны и каковы их цели?

Спасибо,
Matt

Ответы [ 2 ]

2 голосов
/ 14 июля 2009

Хороший вопрос, я думаю, что вы покрыли все слои, которые я видел: Модальное связующее и служебный слой не являются обязательными.

Возможно, вы можете добавить еще один слой обработки ошибок, например elmah .

  • Просмотр / UI -> Вы поместили свою HTML-разметку / код Javascript.
  • Model Binder -> Вы выполняете магию, чтобы связать свой ввод с параметрами действия, обычно вы используете связыватель по умолчанию, поэтому вам не нужно об этом беспокоиться. Однако вы можете переопределить это с помощью своего собственного связывателя и выполнить проверку в этом слое. Вот хороший пример на этом.
  • Контроллер -> Достаточно документации онлайн.
  • Сервисный уровень -> Многие люди выполняют проверку и другую обработку бизнес-логики здесь перед отправкой в ​​хранилище. Пример менеджера контактов Asp.net mvc имеет хороший пример здесь. Это также слой для фактической работы с вашим модом.
  • Репозиторий -> Простая операция чтения / записи.
  • Entity Framework / LINQ to SQL -> DB - собственно запись в базу данных. Nhibernate является еще одним хорошим кандидатом здесь.
0 голосов
/ 14 июля 2009

Прежде всего, я думаю, что программное обеспечение и шаблоны имеют тенденцию усложнять вещи. Как следует из названия ASP, основная идея фреймворка - Model-View-Controller (MVC). Вы можете быть в состоянии поместить много вещей между этими компонентами, включая БД, Сервисы, API и т. Д. Однако основная концепция шаблона Model-View-Controller довольно проста: разделите эти функции на модули, чтобы проект мог быть легче поддерживать

MVC может применяться для ЛЮБОГО программирования или написания сценариев. Даже для сценария оболочки MVC может быть полезным. Вот несколько примеров каждого из них:

  • Просмотр - вот как пользователь взаимодействует. Это может быть веб-страница, форма Windows или интерфейс командной строки.
  • Контроллер - Мозги программы, она должна знать обо всем, но должна быть довольно простой. Он в основном получает сообщения или события из представления и / или модели и решает, что делать. Хорошие контролеры - это в основном диспетчер событий. В зависимости от событий, это вызывает представление или методы модели. В ASP MVC контроллер предоставляет ActionResults для представления и взаимодействует с моделью.
  • Модель - это, в основном, где данные. Это может быть БД, файловая система, веб-сессия или память.

Теперь хорошая часть. Контроллеру не важно, как View управляет взаимодействием с пользователем. Это может быть интерфейс командной строки или веб-форма. Контроллер не знает, как хранятся данные, не имеет значения, является ли это БД или файлом. Он просто запрашивает данные и передает их в View. Не его дело знать, как представление получает входные данные, или моделировать данные.

Тогда вопрос: какого черта мы хотим слишком усложнять вещи с помощью этого паттерна? Хорошо, представьте, что у вас есть приложение MVC, использующее БД MySQL, и вы знаете, что хотите использовать SQL Server. Какой модуль вы должны изменить? Очевидно, что модель является одной из затронутых. Контроллер и представление не должны иметь каких-либо серьезных последствий. Теперь представьте, что у вас есть другое приложение MVC, использующее Windows Forms, и теперь вы хотите изменить его на Web Forms? Ну, в основном это будет вид, который будет затронут (и некоторые части контроллера), но ваша Модель должна быть такой же.

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

...