Назначение сервисного уровня и ASP.NET MVC 2

Question

Чтобы понять MVC 2 и заставить мою компанию принять его в качестве жизнеспособной платформы для будущего развития, в последнее время я много читал. Проработав с ASP.NET исключительно в течение последних нескольких лет, мне пришлось наверстать упущенное.

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

Первый - это шаблон уровня сервиса. Я прочитал много постов и вопросов в блоге здесь о переполнении стека, но я до сих пор не до конца понимаю цель этого шаблона. Я посмотрел всю серию видео на MVCCentral в приложении Golf Tracker, а также посмотрел демонстрационный код, который он разместил, и мне кажется, что сервисный слой - это просто еще одна оболочка для шаблона репозитория, которая вообще не выполняет никакой работы.

Я также читал этот пост: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx, и он, похоже, несколько ответил на мой вопрос, однако, если вы используете аннотации данных для проверки, это кажется ненужным.

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

Может ли кто-нибудь предоставить мне причину 2-го класса (хорошо, возможно, 5-го класса), чтобы использовать этот шаблон, что я потеряю, если я не буду, и что я получу, если я сделаю?

Answer 1

В схеме MVC у вас есть обязанности, разделенные между 3 игроками: Модель, Вид и Контроллер.

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

Модель обычно резервируется базой данных, поэтому у вас есть доступ к ней некоторых DAO. Ваш бизнес делает некоторые ... ну ... дела и хранит или получает данные в / из базы данных.

Но кто координирует DAO? Контроллер? Нет! Модель должна.

Войдите в сервисный слой. Уровень обслуживания обеспечит высокий уровень обслуживания контроллера и будет управлять другими (более низкого уровня) игроками (DAO, другими службами и т. Д.) За кулисами. Содержит бизнес-логику вашего приложения.

Что произойдет, если вы его не используете?

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

Если контроллер является веб-ориентированным, он должен будет получать свои входные данные и предоставлять ответ в виде HTTP-запросов, ответов. Но что если я захочу вызвать свое приложение (и получить доступ к бизнесу, который оно предоставляет) из приложения Windows, которое взаимодействует с RPC или каким-либо другим способом? Что тогда?

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

Сервисный уровень обеспечивает связь с DTO, которые не привязаны к конкретной реализации контроллера. Если контроллер (независимо от того, какой тип контроллера) предоставляет соответствующие данные (независимо от источника), ваш уровень обслуживания выполнит свою задачу, предоставляя услугу вызывающей стороне и скрывая ее от всех обязанностей соответствующей бизнес-логики.

Answer 2

Я должен сказать, что я согласен с dpb с вышеизложенным: оболочка, т. Е. Service Layer, многократно используется, может использоваться, я в настоящее время нахожусь в процессе включения этого слоя в мое приложение ... вот некоторые из вопросов / требований, которые я Я размышляю (очень быстро: p), что может помочь тебе ...
1. Несколько порталов (например, портал Bloggers, клиентский портал, внутренний портал), к которым могут обращаться многие разные пользователи. Все они должны быть отдельными приложениями ASP.NET MVC (важное требование)
2. В самих приложениях некоторые вызовы к базе данных будут схожими, методы и способы обработки данных из уровня Repository. Без сомнения, некоторые контроллеры из каждого модуля / портала будут делать точно или перегруженную версию одного и того же вызова, поэтому возможна потребность в слое обслуживания (код для интерфейсов), который я затем скомпилирую в отдельном проекте класса.
3. Если я создаю отдельный проект класса для своего сервисного уровня, мне может потребоваться сделать то же самое для уровня данных или объединить его с сервисным уровнем и сохранить модель вдали от самого веб-проекта. По крайней мере, так по мере роста моего проекта я могу выбросить слой доступа к данным (то есть LinqToSql -> NHibernate), или член команды может, не работая над каким-либо кодом в любом другом проекте. Недостатком может быть то, что они могут взорвать все, смеется ...