Разделение проекта WebApi и проекта FrontEnd в решении

У меня есть решение для мобильного приложения, которое я создаю - пока это состоит из двух проектов:

   1) WebAPI for API / DAL / SQL etc
   2) Web for single-page front-end

Веб-проект выполняет вызовы в проект WebAPI. Планируется создание другого проекта для приложения Windows 8, другого для приложения WP8 и т.д.

Это хорошо работает при разработке, но оно стало довольно сложным с CORS, развертываниями и т.д. (Web обслуживается с другой конечной точки, чем WebAPI - два веб-сайта Azure). Мой вопрос: при разработке решения, поддерживаемого REST-ish API, когда разумно/неразумно разбить решение на несколько проектов?

Ответ 1

Я всегда разделяю API и front-end на отдельные проекты по нескольким причинам:

Внешние зависимости (jquery, нокаут, angular....) делают api более тяжелым, чем необходимо. Просеивание кода для типа проекта "Другой" может замедлить разработку.

Управление версиями может немного запутываться при совершении двух функционально отдельных проектов в рамках одного проекта. Если вы измените API и сайт в пределах одного коммита, но затем хотите вернуть один из них в более ранний момент времени (или продвигать их отдельно), это станет головной болью.

Объединяя проекты вместе, вы должны обновлять общие зависимости все сразу (обновление до новой версии .NET?). Если ваш код для вашего API имеет зависимости от обесцененного кода, обновление может быть затруднено, и обновление вашего сайта может быть сдержанным (или наоборот).

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

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

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

Так как шаблон MVAP webapi предоставляет все зависимости и конфигурации для интерфейсного интерфейса, может показаться логичным объединить их, но только потому, что они упростили это, это не значит, что это должно быть сделано таким образом. Я обычно разделяю интерфейс, который представлен в этом шаблоне, и превращаю его в простую страницу, чтобы описать, как использовать API.

В конце концов, MVC сама по себе - это разделение проблем и чистое развитие. Я бы сказал, что разделение типов проектов следует этой логике.

Ответ 2

Я не могу думать о технической причине для разделения решения Visual Studio на "клиентское" решение и "сервисное" решение. Однако в моей нынешней работе мы разделили наше решение на два, потому что это были две отдельные команды, работающие над требованиями. Таким образом, это было чисто организационное решение для нас.