ASP.NET MVC и веб-службы
Разрушает ли добавление веб-службы в мой проект ASP.NET MVC всю концепцию MVC?
Эта веб-служба (WCF) зависит от уровня модели из моего проекта MVC для связи с серверной частью (поэтому мне кажется, что она должна быть частью решения MVC).
Должен ли я добавить это на уровень контроллера или модели?
Ответы 7
Есть ли конкретная причина, по которой вам нужно добавить веб-сервисы в ваше приложение MVC? Если нет конкретной причины, вам следует использовать свои контроллеры в режиме RESTful так же, как и в веб-службе RESTful.
Прочтите этот пост Роба Коннери для получения дополнительной информации: ASP.Net MVC: использование архитектуры RESTful
Ссылка не работает, и мне не удалось найти обновленную ссылку. Контент доступен на Wayback Machine: web.archive.org/web/20130119131317/http://wekeroad.com/2007/ 12 /…
Я добавил в свое приложение веб-службы, и оно работает хорошо. Я не считаю, что это нарушает MVC, потому что это альтернативный интерфейс для вашей модели. MVC не подходит для веб-служб, поскольку веб-службы не имеют представления.
Веб-сервисы могут быть созданы с использованием MVC так же, как веб-сайты или RSS-каналы. Фактически, это одна из сильных сторон концепции MVC - одно и то же действие контроллера может передавать данные в любое представление - веб-служба выводит данные, поэтому это является представление. :)
Похоже, вы должны разделить свою модель на отдельную сборку и ссылаться на нее из своего MVC-приложения и WCF-приложения.
- YourApp.Data - общая модель и доступ к данным, возможно
- YourApp.Web - если вы хотите поделиться большей информацией через свои веб-приложения
- YourApp.Web.Mvc
- YourApp.Web.WebService
Если вы хотите использовать WebServices в стиле MVC, возможно, вам следует использовать MVC для создания собственного REST-приложения.
Тогда не могли бы вы дублировать логику контроллера в сервисе? И ничего не экономить, используя модель, поскольку вы в конечном итоге дважды пишете код контроллера.
@Rob, нет, потому что код контроллера для просмотра веб-страницы должен иметь дело с представлениями, проверкой моделей и т. д. В идеале спокойный контроллер api будет выдавать json и данные форматирования.
Я не думаю, что разделение модели на ее собственную сборку имеет какое-либо отношение к тому, используете ли вы MVC или нет, у вас все еще есть модель. Где это неактуально обязательно?
Разделение модели на отдельный проект не нарушает шаблон «MVC». Во-первых, это просто узор. Цель шаблона MVC - четко разграничить ваши данные, обработчики данных и докладчиков, а также способ взаимодействия между ними. Лучше всего это сделать так, как предложил Себ:
- YourApp.Data
- YourApp.Web.Mvc
- YourApp.Web.WebService
Что-то, что может вам помочь, - это витрина MVC, которую собрал Роб Конери. Смотрите видео здесь:
Серия видеороликов о витрине MVC
И если вы хотите посмотреть на реальный код в своем браузере, чтобы быстро увидеть, как он это сделал, перейдите сюда: Обозреватель кода Codeplex витрины MVC
Я попробовал это сделать.
Смотрите мой результат на мой блог
ps: Я не верю, что это нарушит концепцию MVC, если вы думаете, что веб-служба является моделью репозитория, потому что все, что делает веб-служба, возвращает дамп XML.
Думайте о веб-сервисах и базах данных как об одном и том же. В соответствии с этой аналогией, я думаю, имеет смысл разместить ваши взаимодействия с веб-сервисами там, где вы размещаете логику базы данных.
Это довольно давно, но у вас может быть ответ на мой вопрос. У меня сложилось впечатление, что для динамической загрузки, скажем, раскрывающегося списка со значениями, которые меняются при изменении другого раскрывающегося списка, мне понадобится веб-сервис. Вот как я бы сделал это в webForms. Как это делается в MVC?