Чи варто закликати веб-API з програми MVC у тому самому рішенні?

Я працюю над проектом у MVC, який має мобільний додаток, так що одне зрозуміло, що ми маємо використовувати Web API, щоб він міг використовуватися в мобільному додатку.

Після створення API, коли ми почали розробляти веб-сайт, ми розгубилися та обговорили, чи використовувати API чи безпосередньо мати доступ до бізнес-об’єкта. І ми закінчилися після формування думки більш досвідченого розробника, щоб споживати веб-API, а не використовувати бізнес-об’єкт безпосередньо.

У мене виникає плутанина щодо цієї структури рішення.

1) Чому ми повинні використовувати веб-API і робити HTTP-запит (що займає багато часу), щоб отримати або поставити дані замість бізнес-об’єкта безпосередньо, що знаходиться в тому ж самому рішенні.

2) Після аргументів вони сказали, що робити, якщо клієнт хоче розмістити API та веб-сайти на різних хмарних серверах і застосувати масштабування лише на API, або він може мати різний URL для доступу до API та Web (що є певним, що є логічним). Тож у такому разі ми повинні викликати Web 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-шаблон.

Чудове запитання! Я завжди шукаю кращого способу структурування моїх проектів. Кожна точка, на яку ви звертаєтесь, заслуговує і досліджуючи різноманітні структури рішень, я мушу сказати, що я згоден на більшість коментарів тут: ідеального рішення немає. Кілька речей, які слід задати собі, стикаючись з подібною проблемою: Наскільки складною є ця програма? Скільки систем мені потрібно буде інтегрувати - або скільки систем знадобиться для інтеграції з цією системою? Скільки тестування я планую зробити? Чи є окрема команда проектування / інтерфейсу користувача? Чи потрібно нам масштабувати? Що являє собою сеанс?

Давайте розглянемо кілька сценаріїв і способів використання трохи розумної інженерії, щоб зробити речі справді хитними (і кілька хитрощів, щоб полегшити справи).

Розміщення як API, так і веб-сайту в одному проекті
У цьому випадку ви можете мати єдине рішення з нульовими або більше проектами бізнес-рівня та одним гібридним проектом MVC / WebAPI (а також іншими проектами - утилітами тощо).

Pro
все все в одному місці. Не потрібно взувати ріг у складні повідомлення (дзвінки HttpClient), ви можете мати загальний стан сеансу (клієнт і сервер через файли cookie, InProc / OutOfProc сесії тощо), об'єднання з'єднань, спільна логіка тощо Розгортання не може бути більш простим.

Con's
Все знаходиться в одному місці. Це, мабуть, найбільш монолітна структура. Немає чітко визначених інтерфейсів між вашими шарами. У вас закінчується висока згуртованість . Ледачі розробники уникатимуть інтерфейсів при роботі з цим типом архітектури, що робить тестування величезним болем. Масштабування / локалізація програми буде складно.

Використання
Я використовував би цю структуру проекту для разового, внутрішнього або простого застосування. Побудова швидкої системи для відстеження реєстрації в баскетбольний табір у місцевому Y? Це ваша архітектура!

WebAPI та Веб-сайт у різних проектах
я, як правило, віддаю перевагу цьому випадку. У вас є єдине рішення з одним (або більше) проектами MVC та одним проектом WebAPI.

Модуляризація Pro ! Вільна муфта! Кожен проект може стояти окремо, проходити тестування окремо і ним можна керувати по-різному. Це дозволяє легше реалізовувати різні стратегії кешування залежно від ваших потреб. Дотримуючись суцільних меж між вашими різними системами, ви можете легше встановлювати договори, які дозволяють застосовувати конкретні схеми використання та зменшувати можливі тертя (читайте: менше помилок із меншою можливістю зловживати API). Масштабування трохи простіше, оскільки вам потрібно лише масштабувати шматочки, які бачать велике навантаження. Інтеграція стає трохи легшою в обробці, тому що вам потрібно буде мати уявлення про те, як виглядатиме ваш API з самого початку.

Технічне обслуговування Con трохи складніше. Кілька проектів означають, що вам знадобляться власники проектів / функцій, щоб слідкувати за злиттями, контрактами (інтерфейсами), розгортанням тощо. Утримання коду, технічна заборгованість , відстеження помилок, управління державою - все це викликає занепокоєння, оскільки їх, можливо, потрібно буде реалізовувати по-різному на ваші потреби. Такі програми також потребують найбільш планування та курітування під час їх зростання.

Використовує
Створення програми, яка могла б мати 100 користувачів сьогодні та 100 000 на наступному тижні / місяць? Чи потрібно додатку надсилати сповіщення, керувати складними робочими потоками та мати кілька інтерфейсів (веб + мобільний додаток + SharePoint)? У вас багато часу на руках і ви любите вирішувати 5000+ пазлів у вихідні? Це архітектура для вас!

Поради
Виклавши вищесказане, я можу зрозуміти, як ваш наступний проект може виглядати трохи непросто. Не хвилюйтесь, ось кілька хитрощів, яких я навчився за ці роки.

1. Спробуйте використовувати сеанси без громадянства. У менших системах це може означати збереження зашифрованого файлу cookie, що містить принаймні внутрішній ідентифікатор поточного користувача та тайм-аут. Більш масштабні системи можуть означати збереження зашифрованого файлу cookie з простим ідентифікатором сеансу, який може бути отриманий з сховища даних (redis, зберігання таблиць, DHT тощо). Якщо ви можете зберігати достатньо інформації, щоб вам не довелося переходити до основної бази даних за кожним запитом ви будете в хорошому місці - але намагайтеся тримати файли cookie менше 1 к.
2. Майте на увазі, що напевно буде більше однієї моделі. Спробуйте подумати з точки зору моделей та проекцій (посилання, які я знайшов тут, були .. недобре .. подумайте: товарний інвентар одного чоловіка - це позиція другого порядку в порядку замовлення чоловіка - така ж основна основна структура, але різні погляди). Деякі проекти мають іншу модель для кожного логічного / концептуального кордону (тобто використовують конкретну модель для спілкування з конкретним API.
3. API скрізь! Щоразу, коли об’єкт / клас / структура виявляє будь-які дані чи поведінку, ви створюєте API. Майте на увазі, як інші суб'єкти чи залежності будуть використовувати цей API. Подумайте, як ви можете протестувати цей API. Поміркуйте, що може говорити з цим API (інші об'єкти за допомогою коду? Інші системи через протокол?) І як ці дані піддаються (сильно набрані? JSON? * Кашель * XML?).
4. Будуйте для того, що у вас є, а не на тому, що ви уявляєте, що через два роки у вас буде. Ще одна відповідь на відповідь YAGNI - вони абсолютно правильні! Вирішення уявних проблем робить ваш термін уявним. Поставте тверді цілі для своїх ітерацій і виконайте їх. Розгорнути! Проект в розробці - це проект, у якого лише один користувач - ви!
5. YMMV (Ваша пробіг може змінюватися). Тут є лише один абсолют: є проблема, ви будуєте рішення. Все інше повністю в повітрі. Обидва рішення вище можуть досягти дикого успіху - і невдалого смоктання. Все залежить від вас, ваших інструментів та способів їх використання. Легко ступайте, товариш розробник!

Безпосередній доступ до об'єктів вашого бізнесу (я вважаю, ви маєте на увазі у своєму контролері) буде швидшим та простішим.

що робити, якщо клієнт хоче розмістити API та веб-сайти на різних хмарних серверах і застосувати масштабування лише на API, або він може мати різні URL-адреси для доступу до API та Web (що дещо логічно)

Тоді вам потрібно буде розмістити їх окремо ... але це для мене не дуже логічно. Ви впевнені, що потрібно задовольнити цю вимогу? Це звучить як надмірність. Пам'ятайте YAGNI - якщо він вам не потрібен, не будуйте його. Коли вам це потрібно, будуйте його.

Якби це я, я буду створювати сайт за допомогою технології, яка найкраще підходить до сайту, тоді, коли (якщо) вам потрібна послуга, яку можуть викликати інші люди, будувати її окремо.

Я б сказав; віддайте перевагу MVC виклику WebAPI через HTTPClient. Це надзвичайна логіка "core dll" логіки, але головна перевага полягає в тому, що ваша загальна система матиме єдиний точковий доступ до об’єктів домену на HTTP ... У будь-якому разі вниз .. з підбору мікро-архітектури служби та додатків, які вже переходять на Рамки клієнта на стороні (AngularJS тощо) .... краще ставитися до MVC як до іншого клієнта ... і навчати свою команду добре керувати API ...

ЗБЕРІГУЙТЕ ПРОСТО. Сподіваюся, що це допоможе. Спасибі..