Как объединить Web Api и MVC лучше всего в одном веб-приложении

Я собираюсь создать простое веб-приложение, и мне интересно, следует ли использовать новую функцию ASP.NET MVC 4 Web API.

Какой лучший способ сделать это?

Я провел несколько исследований, и я узнал, что есть два варианта:

Option 1

Сделайте Web Api своим уровнем обслуживания и вызовите его из контроллера для чтения/записи данных и визуализации представления с использованием моделей представления и бритвы.

Option 2

Сделайте Web Api своим уровнем обслуживания и вызовите его непосредственно из представления с помощью Javascript.

Я не большой поклонник Option 2, так как я чувствую, что пренебрегаю контроллером, который будет использоваться только для перенаправления между страницами. Кроме того, я предпочитаю использовать бритву, а не Javascript.

И если я выберу Option 1, мне нужно сделать экземпляр одного веб-API в контроллере? потому что это похоже на то, что я делаю что-то неправильно.

Какой лучший вариант? Есть ли другие варианты, которые я не рассматривал?

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

Спасибо.

Ответ 1

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

Таким образом, оба контроллера MVC и API-контроллеров используют этот слой; который сохраняет применение в сухом состоянии.

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

Итак, вы, MVC-контроллеры, собираетесь создавать эти бизнес-сервисы (или они будут введены в ваши контроллеры, если вы используете IoC). Для операций чтения вы можете перейти прямо к своему уровню устойчивости или использовать другую стратегию чтения.

То же самое произойдет с вашими контроллерами API, они будут использовать этот "общий" уровень сервисов.

Вам не нужно создавать экземпляры своих контроллеров API на своих контроллерах MVC. Потребление ваших Web-контроллеров Api через AJAX в порядке, если вы разрабатываете SPA или аналогичный.

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

Если вы планируете вводить тесты в свои приложения (и вам нужно:)); то вы должны структурировать его так, как легко проверить каждую его часть.

Только мои 2 цента.

Ответ 2

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

Обратите внимание, что, когда речь идет о веб-API, чаще всего люди говорят об ApiControllers, а не о базовых MVC-контроллерах, которые берут маршруты и превращают их в Views.

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

I, и многие считают, что ApiControllers не следует смешивать с вашим приложением MVC. Имейте в виду, что MVC плохо сочетается с Web API. Как говорит Филипп:

Многие из концепций, используемых веб-API и MVC, хотя и похожи на первый взгляд, на самом деле несовместимы. Например, веб-интерфейс атрибутами являются атрибуты System.Web.Http.Filters.Filter и MVC. System.Web.Mvc.Filter - и они не взаимозаменяемы.

Самый гибкий ответ

Итак, что вы делаете, создайте субдомен с именем api.YourWebsite.com и создайте там новый проект API ApiController. Этот веб-проект API должен делать НИЧЕГО больше, чем создавать экземпляры и публиковать бизнес-логику через ApiControllers и Injection Dependency.

Альтернатива 1

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

Создайте свой логический уровень Businessines как другой проект и получите доступ к нему непосредственно из своего веб-приложения. Когда ваши Javascript (Angular/Razor?) Контроллеры совершают вызов, они могут вызывать ваши ViewModels и/или Codebehind или что-то подобное, что может создавать бизнес-логику и напрямую обращаться к ней. Нет необходимости в услугах, если все там прямо и не будет использоваться повторно.

Альтернатива 2

Идем дальше и помещаем ваш API API ApiControllers в тот же проект. Но не забудьте их разделить на разные папки с помощью MVC "Контроллеры". Тем не менее, когда ваши Javascript-контроллеры совершают вызов, они будут совершать вызовы Routing на ваш сайт для возврата без гражданства. Не смешивайте антивирусные ApiControllers с вашими ViewModels и другим кодом MVC.

Недостатком этого является отсутствие SOC. Теперь у вас смешанный слой Service-Layer и UI-Layer, и ваш пользовательский интерфейс вынужден получить доступ к вашему бизнес-логическому уровню (DLL). Что случилось с этим, если это сделал Alternative 1?

Хорошо, что не так, что Alternative 1 - небольшое приложение, в котором нет места для роста. Что-нибудь еще (в первоначальном плане или альтернативе 2 здесь) должен быть пользовательский интерфейс, который не имеет понятия, что Business Logic (или Persistence) даже существует. Они должны идти о своих действиях, не подозревающих о бэкэнд-мире.