Подтвердить что ты не робот

Цель уровня обслуживания и ASP.NET MVC 2

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

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

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

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

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

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

4b9b3361

Ответ 1

В шаблоне MVC у вас есть обязанности, разделенные между тремя игроками: Model, View и Controller.

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

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

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

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

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

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

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

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

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

Ответ 2

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