Должна ли модель совершать сервисные звонки для получения данных

Question

Мы создаем сайт, используя шаблон MVC. До сих пор на всех построенных нами страницах использовались модели, которые должны были работать со справочными данными (которые кэшируются при первой загрузке веб-сайта). Но теперь мы достигли той стадии потока, где нам приходится иметь дело с данными транзакций (которые специфичны для этого потока). До сих пор мы создавали классы моделей, предоставляя им все данные, поскольку они все уже были кэшированы. Но теперь, когда нам приходится иметь дело с транзакционными данными, мы должны сделать то же самое, когда мы получим все данные заранее и создать объект модели, или мы должны заставить класс модели получить данные, делая вызовы службы.

Answer 1

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

Answer 2

В настоящем MVC модель отвечает за обновление в ответ на инструкцию от контроллера. Как таковой, да. Модель и только Модель должны звонить в сервис

Answer 3

Объекты модели строятся посредством запросов к базе данных. Это общий подход.

Объекты модели могут создаваться посредством запросов веб-служб к другим серверам и базам данных. Это почти то же самое.

Если - для некоторой настройки производительности - вы предварительно строите все объекты модели, хорошо. Это особый случай.

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

Answer 4

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