Веб API в MVC решении в отдельном проекте
=========================================

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

Когда я настраиваю приложения, мне нравится разделять компоненты на проекты. Мой план состоял в том, чтобы иметь проект MVC и проект веб-API. Но я столкнулся с проблемами. Например, у меня было 2 приложения как таковых, отдельная настройка маршрутизации и т. Д. И т. Д.

Поэтому мой вопрос заключается в том, должна ли в приложении MVC структура веб-API находиться в одном проекте или же веб-интерфейс API должен быть разделен на собственный проект и обходить проблемы?

К сожалению, вы не правы в этом -Я предполагаю, что могу разделить все свои атрибуты и т. Д. Между контроллерами web api и mvc, так что, на первый взгляд, это не кажется мне серьезным изменением.

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

То же самое относится ко многим другим концепциям - привязке модели (совершенно разные механизмы), маршрутам (веб-API использует HTTPRoutes, а не Routes, даже если они оба работают на одном базовом RouteTable), преобразователю зависимостей (не совместим) и многим другим, даже если они похожи на Поверхность, очень разные на практике. Более того, в Web API нет понятия областей.

В конечном счете, если все, что вы пытаетесь сделать, это иметь "новый, модный " способ подачи контента JSON - дважды подумайте, прежде чем идти по этому пути. Я бы точно неМы рекомендуем рефакторинг любого существующего кода, если вы действительно не хотите использовать HTTP и создавать свое приложение RESTful способом.

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

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



Я попытался разделить контроллеры API в новый проект. Все яМы сделали, чтобы создать новый проект библиотеки, переместили контроллеры в папку с именем API. Затем добавили ссылку на проект библиотеки в проект MVC.

Конфигурация webAPI остается в самом проекте MVC. Работает нормально.



Даже если ваш проект настолько сложен, чтобы оправдать два "фронт " тогда я бы все еще рассматривал возможность разделения webapi на отдельный проект в качестве крайней меры. У вас будут головные боли при развертывании, и новичку будет трудно понять структуру вашего решения. Не говоря уже о проблемах маршрутизации.

Я хотел бы сохранить изолированное пространство имен system.web в одном "презентационный слой », Несмотря на то, что вебапи непрезентационный это все еще часть интерфейса вашего приложения. Пока вы сохраняете логику в своем домене, а не в своих контроллерах, вы не должны сталкиваться с слишком большим количеством проблем. Кроме того, нене забудьте использовать области.



В дополнение к настройке отдельной DLL для Web.Api.

Просто предложение:

Создать проектNugget WebActivatorExСоздайте метод класса, который будет вызываться при app\_start

[сборка: WebActivatorEx.PostApplicationStartMethod (typeof (API.AppWebActivator), "Начните")]

[сборка: WebActivatorEx.ApplicationShutdownMethod (typeof (API.AppWebActivator), "Неисправность")]

Зарегистрируйте маршруты web.api внутри метода запуска

public static void Start () {GlobalConfiguration.Configure (WebApiConfig.Register); }

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

Надеюсь это поможет.



После некоторой степени опыта (создание API для приложений и для MVC). Я в основном делаю и то и другое.

Я создаю отдельный проект для вызовов API, поступающих с других клиентов или других устройств (приложений Android / IOS). Одна из причин заключается в том, что аутентификация отличается, она основана на токене (чтобы сохранить ее без сохранения состояния). Я не хочу смешивать это в моем приложении MVC.



Недавно я сделал почти то же самое: я начал с нового проекта веб-приложения MVC 4, выбрав шаблон веб-API в VS2012.

Это создаст веб-API, размещенный в том же приложении, что и MVC.

Я хотел переместить ApiControllers в отдельный проект библиотеки классов. Это было довольно легко, но решение было немного скрытым.

В AssemblyInfo.cs проекта MVC 4 добавьте похожую строку кода

Теперь вам нужен класс LibraryRegistrator (не стесняйтесь называть его как угодно)

В проекте MVC 4 также добавьте ссылку на библиотеку Api.

Теперь вы можете добавить контроллеры Api в свою собственную библиотеку классов (yourown.dll).



Стивен из SimpleInjector (IoC framework) рекомендует два отдельных проекта:[В чем разница между DependencyResolver.SetResolver и HttpConfiguration.DependencyResolver в WebAPI](https://stackoverflow.com/questions/15494920/what-is-the-difference-between-dependencyresolver-setresolver-and-httpconfigurat/15495934#15495934)



ИМО, безопасность и развертывание должны определять ваше решение. Например, если ваше приложение MVC использует проверку подлинности с помощью форм, но выЗаинтересовавшись использованием базовой аутентификации (с SSL) для вашего API, отдельные проекты сделают вашу жизнь проще. Если вы хотите разместить свой сайт по адресу www.example.com, но разместить свой API как api.example.com (вместо www.example.com/api), отдельные проекты сделают вашу жизнь проще. Если вы разделили свои проекты и поддомены соответствующим образом, и вы намереваетесь использовать свой собственный API из своего приложения MVC, вам придется выяснить, как обращаться с[Политика единого происхождения](https://en.wikipedia.org/wiki/Same_origin_policy) проблема для вызовов на стороне клиента к вашему API. Общие решения для этого должны использовать[JSONP](https://stackoverflow.com/questions/9421312/jsonp-with-asp-net-web-api) или же[CORS](https://blogs.msdn.com/b/carlosfigueira/archive/2012/07/02/cors-support-in-asp-net-web-api-rc-version.aspx) (желательно, если вы можете).

Обновление (26.03.2013): Официальная поддержка CORS:[http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20APII»](https://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API)