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

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

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

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

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

Ответы на вопрос(8)

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

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

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

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

 lordcheeto15 апр. 2014 г., 02:39
Моя основная причина желать отдельных проектов заключается в том, что API нет действительно фронтэнд. Это'средний уровень. "
 Dan Bechard03 янв. 2017 г., 15:02
Новичку было бы трудно понять не является хорошей причиной для выбора одного подхода по сравнению с другим. Конечно, по возможности, делайте это просто, но сложные потребности часто требуют сложных решений. Вместо того, чтобы писать тупой код для обслуживания новичков, мы должны обучать новичков понимать и писать умный код.

В дополнение к настройке отдельной 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.

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

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

 Developer08 мая 2016 г., 15:01
Делай что хочешь. Я редактирую не голосами, а для лучшего взгляда. Преуспевать.
 Dan Bechard03 янв. 2017 г., 14:59
@CularBytes Вы можетеОтклонить изменения, но вы можете отредактировать их снова и откатить изменения. Это требует процесса экспертной оценки менее 2000 представителей, но у вас достаточно представителей, чтобы сделать это мгновенно. Я согласен, что редактирование не добавило ценности и откатило его для вас.
 CularBytes08 мая 2016 г., 13:54
Ну, @ Дими, этоЭто бесполезное редактирование, чтобы получить несколько голосов ... Как я могу отклонить это?

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

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

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

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

 David Peden19 мая 2015 г., 22:51
@ H.Johnson It 'Трудно дать общий совет, который имеет смысл, но кажется, что вы бы выиграли от наличия уровня обслуживания приложений, который инкапсулирует ваши сущности и репозитории, которые могут быть использованы обоими вашими пользовательскими интерфейсами (MVC и API).
 Ciaran Gallagher14 февр. 2013 г., 02:10
Я пытаюсь разобраться в вопросах, связанных с решением об интеграции Web API с моим MVC-приложением или в качестве отдельного проекта. Мне удалось успешно развернуть приложение HelloWorld Web API в поддомене на моем веб-хосте. Из этого отдельного проекта я, скорее всего, буду использовать Модель из моего веб-приложения MVC и вызывать код в этом отдельном проекте. Кажется, что было бы легче пойти по этому пути отдельного проекта, но как вы думаете, с какими проблемами я мог бы столкнуться при таком подходе?
 Willys19 мая 2015 г., 18:47
@DavidPeden Вы предлагаете создать новый отдельный проект для WebAPI. Это правда? С другой стороны, я создам новый отдельный проект для WebAPI (в настоящее время в моем приложении есть UI Layer (MVC) и Data Layer (Class Library)). Итак, я также использую DI, но мне интересно, могу ли я использовать те же сущности, репозитории, интерфейсы и абстрактные классы на уровне данных для вновь созданного проекта WebAPI, и единственное, что мне нужно сделать, - это создать контроллеры WebAPI? Или я также создаю их все (сущности, репозитории, интерфейсы и аннотации)? классы) снова для WebAPI? Любая помощь, пожалуйста?
 David Peden14 февр. 2013 г., 18:02
Лично я бы не использовал вашу модель представления в качестве DTO для вашего API. Я ожидаю, что это решение вызовет у вас серьезные проблемы, поскольку ваши модели представлений и сигнатуры API расходятся. SoC (en.wikipedia.org/wiki/Separation_of_concerns) очень важно.
Решение Вопроса

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

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

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

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

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

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

 Filip W18 окт. 2012 г., 01:49
Да, в таком сценарии просто запустите новый проект MVC4 в Visual Studio, а при появлении запроса на шаблон проекта (второй экран) просто выберите Web API. Это установит Web API из Nuget, и в случае, который вы описали, все будет в порядке. Вы получаете отдельный файл конфигурации Web API, подключенный к Global.asax. Кроме того, вы можете захотеть разделить контроллеры API в отдельную папку (по умолчанию они вместе с контроллерами MVC). Наконец, маршруты по умолчанию явно настраиваются отдельно и не мешают друг другу
 Willys19 мая 2015 г., 18:52
@FilipW Спасибо за хорошие объяснения. У меня также есть приложение MVC, и я буду использовать WebAPI2 для использования сервиса для приложений Android. С другой стороны, как говорит Дэвид Педен ниже,безопасность, обслуживание и развертывание Это также очень важно при принятии решения о создании нового отдельного проекта для WebAPI. В таком случае, учитывая их, что бы вы предложили? Чтобы создать новый отдельный проект для WebAPI или использовать текущий проект MVC? Заранее спасибо.
 amateur18 окт. 2012 г., 00:53
Спасибо за такой подробный ответ. Я создаю новое веб-приложение, использующее контроллеры mvc для предоставления контента моим представлениям. Мой план состоит в том, чтобы использовать веб-API для обработки связи с клиентской стороны JS (сайт содержит некоторые богатые функции) с сервером через веб-API. Некоторые третьи лица создают компоненты для сайта, которые будут интегрированы в сайт и будут использовать веб-API для связи с сервером. Итак, из того, что я прочитал, будет ли ваше предложение для такой установки иметь mvc и web api в одном проекте? Может быть, есть веб-API в "апи» папка.
 Billdr03 янв. 2013 г., 17:14
Я хотел бы, чтобы мой руководитель прочитал этот пост до того, как он разработал наш текущий проект.
 ozzy43283607 нояб. 2017 г., 14:42
Отлично "Я бы выделил веб-API в отдельный проект только в том случае, если вы собираетесь создать надлежащий API-интерфейс для своего онлайн-сервиса - возможно, для использования внешними клиентами или различными устройствами - например, для подпитки ваших мобильных приложений ». ударить ногтем по голове и позволяет легко определить, каким образом это сделать.
 VJAI16 окт. 2012 г., 14:14
+1 Отличный ответ. Сначала я думал, что и MVC, и WebAPI могут совместно использовать часть кода, особенно в случае фильтров, привязки модели и т. Д., Но они совершенно разные.

Ваш ответ на вопрос