Должны ли мы вызывать Web API из приложения MVC в том же решении?
Я работаю над проектом в MVC, в котором есть мобильное приложение, поэтому ясно одно, что мы должны использовать Web API, чтобы его можно было использовать в мобильном приложении.
После создания API, когда мы начали разрабатывать веб-сайт, мы растерялись и обсуждали, использовать ли API или иметь прямой доступ к бизнес-объекту. И в итоге мы получили от более опытного разработчика мнение о том, чтобы использовать веб-API вместо непосредственного использования бизнес-объекта.
У меня путаница в отношении этой структуры решения.
1) Почему мы должны использовать веб-API и сделать HTTP-запрос (который занимает много времени), чтобы получить или поместить данные вместо бизнес-объекта напрямую, который находится в том же решении.
2) После аргументов они сказали, что, если клиент хочет разместить API и веб-интерфейс на другом облачном сервере и применять масштабирование только для API, или, возможно, он хочет иметь разные URL-адреса для доступа к API-интерфейсу и веб-интерфейсу (что вполне логично). Таким образом, в этом случае мы должны вызвать веб-API из приложения MVC в том же решении?
3) Если мы размещаем API и Web на разных хостингах, это означает, что наш Web будет использовать WebClient и будет иметь HTTP-вызов для каждой навигации. Это правильно?
4) Если мы создадим бизнес-объект как API, так и веб-хостинг на другом сервере, то если что-то изменится в BL, потребуется обновить сборку на обоих серверах.
5) Или мы должны создать только один проект для API и можем добавить представления или HTML-страницы для разработки веб-интерфейса, чтобы таким образом мы могли напрямую вызывать API из ajax.
Насколько мне известно, #5 является лучшим решением или API только для стороннего доступа. Если у нас есть DB, EF, уровень данных и бизнес-уровень в одном решении, нам не следует использовать API для выполнения HTTP-вызовов и прямого доступа к бизнес-объекту. (поправьте меня, если я ошибаюсь) API необходим, когда мобильное приложение или настольный компьютер или кто-либо хочет получить доступ к приложению, чтобы у нас мог быть один и тот же уровень хранилища и данных.
В моем сценарии я должен создать API, поскольку у нас также есть мобильное приложение, а на стороне API проекта мы назвали бизнес-уровень (отдельный проект) и бизнес-уровень, связывающийся с уровнем доступа к данным (отдельный проект). Поэтому мой вопрос: если мы размещаем наш API и веб-интерфейс на разных серверах, то вызов API, который является HTTP-запросом, может занять больше времени, чем использование метода из бизнес-уровня, когда мы создаем проект, и у нас есть.dll бизнес-уровня. В контроллере API мы просто конвертируем бизнес в формат json.
Я искал в интернете, но не получил убедительного ответа. Я нашел блог http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx обсуждается тот же вопрос, но снова В этом блоге мой вопрос: почему мы должны рассмотреть сценарий № 3?
1 ответ
Я думаю, что вы ответили на свой вопрос в письменном виде, но на самом деле все сводится к тому, каковы ваши требования, и, возможно, что более важно, какова стратегия для вашего приложения.
Во-первых, использование Web Api для прямого доступа к бизнес-объектам (что я имею в виду под моделями представления и т. Д.) Имеет смысл, только если вы контролируете доступ на стороне клиента данных.
Если у вас есть требование только для потребления данных со стороны клиента в конкретном приложении, то размещение Web API в том же проекте имеет смысл. Иногда, например, при создании веб-приложения SPA или многофункционального клиента, достаточно использовать Web Api в рамках одного проекта, так как они предназначены только для использования этим приложением.
Если вы видите требование для разных версий одного и того же приложения (для мобильных устройств, планшетов, веб-сайтов и т. Д.), Тогда имеет смысл переместить Web Api в отдельный проект, поскольку каждое приложение может получить доступ к одному и тому же API. Этот веб-интерфейс будет содержать в себе уровни доступа к данным и бизнес-логики. Это позволяет полностью разделить ваши проекты и обеспечивает максимальное повторное использование, а также обеспечивает согласованность данных между различными версиями вашего проекта. Очевидно, что с этой настройкой ваш уровень Web Api является отдельным и может быть протестирован / развернут / масштабирован отдельно.
Итак, подведем итог, вам нужно рассмотреть ваши требования и оценить технологии, доступные вам для их достижения. Используя вышеизложенное, я надеюсь, что вы понимаете, где Web Api подходит и что он может предоставить.