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

ИМО, безопасность и развертывание должны управлять вашим решением. Например, если ваше приложение MVC использует проверку подлинности форм, но вы заинтересованы в использовании обычной проверки подлинности (с SSL) для вашего API, отдельные проекты сделают вашу жизнь проще. Если вы хотите разместить свой сайт по адресу www.example.com но разместите свой API как api.example.com (vs. www.example.com/api), отдельные проекты сделают вашу жизнь проще. Если вы разделите свои проекты и поддомен их соответственно, и вы намерены использовать ваш собственный API из вашего приложения MVC, вам придется выяснить, как бороться с Та Же Политика Происхождения проблема для клиентских вызовов вашего API. Общие решения для этого использовать jsonp или CORS (желательно, если вы можете).

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

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

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

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

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

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

недавно я сделал почти то же самое: я начал с нового проекта веб-приложения 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.)

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

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

в дополнение к настройке отдельной библиотеки DLL для Интернета.Прикладной программный интерфейс.

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

1. создать проект
2. Самородок WebActivatorEx

3. создайте метод класса a, который будет вызван на app_start

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

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

4. Регистрация веб.маршруты api внутри метода Start

   публичный статический пустота начала() { GlobalConfiguration.Настроить(WebApiConfig.Реестр); }

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

надеюсь, что это помогает.

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

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