Где я должен поместить запрос API в MVC?

Я создаю веб-приложение с использованием шаблона MVC. Следуя такой архитектуре, мы видим, что все методы, используемые для взаимодействия с базой данных, реализованы в модели .

Но что произойдет, если мне нужно вызвать услугу, открытую другими в Интернете? Например, я хотел бы получить доступ к API Facebook, чтобы получить всех последователей моей страницы, поэтому, где я помещаю эти методы?

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

Итак, можете ли вы рассказать мне об этом? И, пожалуйста, можете ли вы сказать мне, если я ошибаюсь в архитектуре MVC?

20 голосов | спросил Ema.jar 10 PM00000030000000031 2015, 15:36:00

5 ответов


31

Модель не ограничивается взаимодействием с базой данных, модель отвечает за получение и управление данными.

Итак, вашему виду и контроллеру не должно быть никакого значения, если данные поступают из базы данных или из веб-службы или даже полностью случайны, поэтому вы должны сделать это в модели.

MVC - это шаблон представления, который разделяет только разные уровни представления.

Это не значит, что эта модель должна быть единым беспорядком спагетти-кода. Сама модель также может быть многослойной, но контроллер не должен знать, откуда берутся данные.

Открытый метод в вашей модели может быть структурирован таким образом (псевдокод), который может вызываться вашим контроллером:

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

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

ответил Residuum 10 PM00000040000004131 2015, 16:01:41
12

Есть общее (намеренное?) непонимание того, что такое M, V и C. Не о тех ролях, которые они берут, а о том, что они .

В исходном определении GUI рабочего стола MVC они были modules . Обычно в приложении было несколько из них, иногда работавших в тройках, иногда имеющих множество представлений и моделей, которые несколько контроллеров могли смешивать и сопоставлять.

В веб-фреймах OTOH они, как правило, рассматриваются как layers , где они являются только одним из них и в основном касаются покрытия некоторого уровня абстракции: «модельный слой абстрагирует базу данных», уровень представления реализует представление »,« уровень контроллера обрабатывает пользовательский ввод ».

Итак, я бы сказал, что у вас уже есть модель a , посвященная взаимодействию с базой данных, и теперь вам просто нужно создать другую модель, чтобы иметь дело с вашим исходный API. Если вы сделаете их как можно более похожими, то большая часть кода контроллера и просмотра может работать без проблем с любой моделью.

ответил Javier 10 PM00000050000002231 2015, 17:42:22
5

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

В самом деле, существует тенденция к тому, чтобы разные проекты, созданные MVC, имели разные имена (см. эту статью Мартина Фаулера для некоторых обсуждение этого) или даже отказаться от точного наименования - например, AngularJS описывает себя как модель-представление-безотносительно рамки.

Итак, трудно ответить, не зная, с какой версией «MVC» вы работаете. Тем не менее, запрос API обычно будет частью основного приложения (часть, которая не должна изменяться, если вы решите использовать другое визуальное представление), которое во многих реализациях будет содержаться полностью в пределах модели.

ответил James_pic 11 PM000000120000001031 2015, 12:26:10
1

Здесь , модель описывается следующим образом:

  

В модели хранятся данные, которые извлекаются на контроллер и отображаются в представлении. Всякий раз, когда происходит изменение данных, он обновляется контроллером.

Я бы сказал, что контроллер либо включает в себя логику вызова службы, либо вызывает отдельный объект Service. Если служба является отдельной, вы можете более легко создавать тесты, например, если соединение с сетью не возможно, некоторые TestService может предоставлять ответы от Service локально.

Также проверьте этот ответ, который предполагает, что контроллер вызывает службу.

ответил null 10 PM00000040000000331 2015, 16:41:03
1

Возможно, это далеко не так, но я так часто отношусь к WebApps и работаю с [сложными] удаленными API-интерфейсами:

Я бы сделал его классом (т. е. библиотекой методов смягчения данных) вместо модели (т. е. стека функций смягчения данных). Похоже, что он будет действовать более прозрачным, более логичным /схематическим агностиком, и вы можете использовать его везде, где без загрузки -> вызов самой модели /контроллера каждый раз, когда вы хотите его использовать. Логика все еще разделена, datapoint по-прежнему гибкая, и кажется более открытой для взаимодействия в таких странных случаях, как стекирование clientAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON и т. Д. Для косвенного опроса конечной точки.

ответил dhaupin 10 PM00000090000000731 2015, 21:30:07

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132