Куди слід поставити запит API в MVC?

Я будую веб-додаток за допомогою шаблону MVC. Слідуючи такому типу архітектури, ми бачимо, що всі методи, що використовуються для взаємодії з базою даних, реалізовані в моделі .

Але що трапиться, якщо мені доведеться зателефонувати в службу, яку відкрили інші в Інтернеті? Наприклад, я хотів би отримати доступ до API Facebook, щоб отримати весь підписник моєї сторінки, тож, куди я кладу ці методи?

Очевидно, що представлення не є хорошою ідеєю, оскільки цей модуль присвячений презентації, контролер не повинен використовуватися для отримання даних, але модель зазвичай присвячена лише взаємодії з базою даних.

Отже, чи можете ви дати мені якусь підказку щодо цього? І будь ласка, чи можете ви сказати мені, чи роблю я якісь помилки щодо архітектури MVC?

Модель не обмежується взаємодією з базою даних, модель відповідає за отримання та маніпулювання даними.

Отже, для вашого перегляду та контролера це не має значення, якщо дані надходять із бази даних або з веб-сервісу або навіть абсолютно випадкові, тому вам слід це робити в моделі.

MVC - це схема презентації, яка розділяє лише різні шари представлення.

Це не означає, що модель повинна бути рівномірним безладом коду спагетті. Ваша модель також може бути шаруватою, але контролер не повинен знати, звідки беруться дані.

Публічний метод у вашій моделі може бути структурований так (Псевдокод), який може викликати ваш контролер:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebServiceі ORMможуть знадобитися екземпляри інтерфейсів, які можна замінити макетами за допомогою введення залежності, але ваші контролери та представлення не повинні змінюватись для тестування.

Існує поширене (навмисне?) Непорозуміння щодо того, що таке M, V і C. Чи не про роль , яку вони приймають, але то , що це вони.

У початковому настільному графічному визначенні MVC вони були модулями . Зазвичай у додатку було декілька з них, іноді працюючи в трійках, іноді маючи різноманітні види та моделі, які кілька контролерів могли змішувати та співставляти.

У веб-рамках, OTOH, вони, як правило, розглядаються як шари , де вони є лише одним з кожного, і йдеться переважно про покриття деякого підрядного рівня абстракції: "шар моделі абстрагує базу даних", "шар перегляду реалізує презентацію", "контролер рівень обробляє введення користувача ".

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

Частина труднощів у будь-якій дискусії про MVC полягає в тому, що різні групи кооптували це, щоб означати різні речі. Реалізація MVC, яка використовується, скажімо, у програмі Rails, була б майже не впізнаваною для того, хто пише програму Swing. Оскільки MVC все ще є чітко визначеною річчю, це більше набір керівних принципів (відокремте основний додаток від його візуального подання, забезпечте гнучкі механізми, що дозволяють обом прокладатись разом), які можуть бути реалізовані в різних способи.

Дійсно, є тенденція до надання різним іменам MVC конструкцій різних імен (див. Цю статтю Мартіна Фаулера для детального обговорення цього питання), або навіть відмовитися від точного іменування - наприклад, AngularJS описує себе як модель-перегляд-що б там не було рамки.

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

Тут модель описана так:

Модель зберігає дані, які отримуються в контролер і відображаються у вікні перегляду. Щоразу, коли відбувається зміна даних, вони оновлюються контролером.

Я б сказав, що контролер або включає логіку виклику служби, або викликає окремий Serviceоб'єкт. Якщо служба окрема, ви можете легше створити тести, скажімо, якщо підключення до послуги через мережу неможливе, деякі TestServiceможуть надати відповіді на Serviceмісцях.

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

Ваша модель ніколи не повинна містити фактичного коду, і її слід розглядати як більше повідомлення або структуру, яка використовується для управління вмістом, що маніпулює контролером і відображається представленням зображення.

Ваш контролер повинен нести відповідальність за зв'язок з будь-якими API, базами даних, службами тощо ..., вимагаючи зміни та керування будь-якими необхідними оновленнями моделі.

Вся міцність шаблону MVC полягає в тому, що він відокремлює логіку (контролер) від подання та стану (модель). Тим самим вам гарантовано, що тільки код у контролері може створювати побічні ефекти, оскільки представлення та модель просто не дозволяють вносити зміни.

Це також дозволяє краще використовувати код, оскільки модель може ділитися між різними контролерами та видами.

Тут може бути далеко, але я так думаю про WebApps та роботу з [складними] віддаленими API в багатьох випадках:

Я б зробив це класом (тобто бібліотекою методів пом’якшення даних) замість моделі (тобто, стека функцій пом'якшення даних). Схоже, це діятиме більш прозоро, більш логічно / схематично, і ви можете використовувати його куди завгодно, не завантажуючи-> викликаючи модель / контролер кожного разу, коли захочете його використовувати. Логіка все ще відокремлена, точка даних все ще гнучка, і вона здається більш відкритою для сумісності у дивних випадках, таких як укладання clientAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON тощо для опосередкованого запитання кінцевої точки.