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

Ответ 1

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

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

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

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

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

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

Ответ 2

IMO, безопасность и развертывание должны принять ваше решение. Например, если ваше приложение MVC использует проверку подлинности с помощью форм, но вы заинтересованы в использовании базовой проверки подлинности (с SSL) для вашего API, отдельные проекты сделают вашу жизнь проще. Если вы хотите разместить сайт yout на веб-сайте www.example.com, но размещаете свой API как api.example.com(по сравнению с www.example.com/api), отдельные проекты облегчат вашу жизнь. Если вы отделите свои проекты и поддомен им соответственно, и вы намереваетесь использовать свой собственный API из своего приложения MVC, вам придется выяснить, как справиться с Same Origin Policy для клиентских вызовов вашего API. Общим решением для этого является использование jsonp или CORS (желательно если вы можете).

Обновление (3/26/2013): ожидается официальная поддержка CORS: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API

Ответ 3

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

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

Для моего javascript/jquery api вызывает мое приложение mvc, мне нравится держать все в порядке, поэтому я включаю веб-api внутри моего приложения MVC. Я не намерен иметь аутентификацию на токенах с помощью java-скриптов api, потому что он в одном приложении. Я могу просто использовать атрибут [authorize] на конечной точке API, когда пользователь не войдет в систему, он не получит данные.

Кроме того, при работе с корзинами покупок и вы хотите хранить корзину пользователя в сеансе (хотя и не вошли в систему), вам также нужно иметь это в своем API, если вы добавляете/удаляете продукты через код javascript. Это наверняка сделает ваш API завершенным, но также уменьшит сложность вашего MVC-API.

Ответ 4

Стивен из SimpleInjector (IoC framework) советует два отдельных проекта: В чем разница между DependencyResolver.SetResolver и HttpConfiguration.DependencyResolver в WebAPI

Ответ 5

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

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

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

В AssemblyInfo.cs проекта MVC 4 добавьте аналогичную строку кода

[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]

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

public class LibraryRegistrator
    {
        public static void Register()
        {
            BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
        }
    }

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

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

Ответ 6

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

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

Ответ 7

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

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

• Создать проект
• Nugget WebActivatorEx

• Создайте класс Метод, который нужно вызвать в app_start

  [сборка: WebActivatorEx.PostApplicationStartMethod(typeof (API.AppWebActivator), "Пуск" )]

  [сборка: WebActivatorEx.ApplicationShutdownMethod(typeof (API.AppWebActivator), "Shutdown" )]

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

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

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

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

Ответ 8

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

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