Я работаю над проектом в MVC, в котором есть мобильное приложение, поэтому ясно одно, что мы должны использовать веб-API, чтобы его можно было использовать в мобильном приложении.
После создания API, когда мы начали разрабатывать веб-сайт, мы растерялись и обсуждали, использовать ли API или иметь прямой доступ к объекту Business. И в итоге мы получили от более опытного разработчика мнение о том, чтобы использовать Web API вместо непосредственного использования Business object
У меня путаница в отношении этой структуры решения.
1) Почему мы должны использовать Web 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?
Обновление: у нас может быть другой проект API и проект MVC, и мы можем вызывать API из Интернета, используя jvascript или использовать шаблон MVVM.