Где я должен разместить запрос 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 и т. Д. Для косвенного опроса конечной точки.