Понимание нового подхода Web API

Question

Я знаю, что не все используют тщательную архитектуру при разработке приложения MVC, но давайте предположим, что у меня есть следующая архитектура:

App.Core --> Class Library (POCO or Domain objects)
App.Data --> Class Library (Repository and Entity Framework)
App.Service --> Class Library (Service layer with all business logic)
App.Web --> asp.net MVC 3.0 project

---

App.Data --> Has a reference to App.Core
App.Service --> Has a reference to App.Core and App.Data
App.Web --> Has a reference to App.Core and App.Service

Внутри нашего приложения MVC мы стараемся придерживаться этого подхода:

• Внутри нашего Контроллера (внутри метода) мы создаем экземпляр ViewModel.
• Мы заполняем эти вызывающие методы ViewModel из нашего уровня App.Service
• Как только ViewModel заполнен, мы возвращаем его в View (таким образом, представление теперь строго набрано).

Это происходит в 99,9% случаев. Он чистый, нам нравится, и он довольно хорошо себя использует ... и т.д.!

Теперь мой вопрос следующий:

Если мы решим переместить наше приложение в MVC 4.0 и начать использовать новый Web API подход, я не уверен, что полностью понимаю, где (или как) это будет соответствовать нашей нынешней архитектуре?

Имейте в виду, что мы открыты, чтобы изменить это вокруг!

Должны ли мы создать новый слой App.WebAPI, который находится между App.Service и App.Web? Это означает, что внутри наших контроллеров нам больше не нужно напрямую вызывать App.Service, а вместо этого новый слой App.WebAPI?

Или оставить Web API внутри слоя App.Web и заставить контроллеры вызывать другие APIControllers, которые, в свою очередь, будут вызывать слой App.Service?

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

Спасибо

Answer 1

Необходимо рассмотреть несколько случаев:

Хотите ли вы, чтобы этот веб-API служил уровнем обслуживания и доступом к данным для вашего приложения MVC?Если да, то вам следует полностью удалить все ссылки на App.Service из проекта ASP.NET MVC и заставить его запрашивать Web API вместо извлечения данных.В этом случае Web API находится между вашим приложением ASP.NET MVC и доступом к данным.Это веб-API, который взаимодействует со служебным уровнем и предоставляет его по протоколу HTTP.

Или вы хотите предоставить дополнительный API для вашего веб-сайта, который может использоваться другими клиентами (кроме веб-браузеров).)?В этом случае приложение ASP.NET MVC и веб-API находятся на одном уровне.Оба запрашивают уровень Service для заполнения моделей представлений, просто в случае приложения MVC вы передаете эти модели представлений представлениям, которые, в свою очередь, преобразуют их в HTML, тогда как в слое Web API вы, вероятно, используете слегка отличающиеся модели представлений, новсе еще заполняются из уровня обслуживания и передаются клиенту с использованием соответствующего механизма сериализации (JSON, XML, ...)

Answer 2

Я знаю, что уже поздно, но я действительно искал тот же совет, и я нашел этот пост.

Не было бы ", и MVC, и Web API находятся в одном слое"означает больше работы по обслуживанию кода или, возможно, дублирование кода?разве mvc web не рассматривается как клиент браузера?... для меня имеет смысл сделать WebAPI вашим единственным слоем для всех остальных, и, в свою очередь, он вызовет ваш уровень обслуживания для обработки.

Какая выгода от того, что и веб-API, и MVC общаются напрямую с сервисным уровнем?Разве веб-API не может быть оболочкой для сервисного уровня?