Я нахожусь в точке, где я должен принять решение о моделях.
Я знаю, что модели - это то, что вы используете для всех манипуляций с базой данных.
Но существуют ли модели, ограниченные этим?
Под этим я подразумеваю.
Они предназначены только для взаимодействия с базой данных, Или они предназначены для всех внешних манипуляций с данными (например, данные из внешних API и т.д.)?
Например, в Django модель представляет собой класс, который отображает отношение данных (таблица) и потенциально мостифицирует таблицы (например, для многих-многих отношений).
В том же классе могут быть методы манипуляций с соответствующими данными, могут быть дополнительные классы, которые сами не определяют модели, а методы доступа и фильтрации данных.
Но модель термина в MVC применима к описанию структур данных и методов доступа к ним в целом.
Структуры могут несколько искажать абстрактную терминологию. Например, то, что Django вызывает представления, фактически является функциями контроллера, а сущности, определяющие презентацию, называются шаблонами вместо представлений.
Парадигма MVC - это шаблон проектирования, в котором вы организуете свое приложение со следующей структурой.
Модель: здесь вы должны сохранить свою модель данных, алгоритмы. Например, если вы пишете приложение для работы с электронными таблицами, вы сохраните структуру данных своей электронной таблицы. У вас будет вычислительный движок в вашей модели, у вас будет код для сохранения и загрузки вашей таблицы в вашей модели. Этот класс моделей потенциально может быть повторно использован в других приложениях, например, если у вас есть код для сжатия данных.
Просмотр или представления: это часть вашего кода для визуализации данных (пользовательский интерфейс), для электронной таблицы у вас есть типичный вид электронных таблиц с ячейками от A1 до Z100 и т.д. Вы также можете визуализировать свои данные с помощью вида диаграммы, И т.п. Просмотр может быть повторно использован в другом приложении, а также, например, вы можете повторно использовать свое воображаемое представление диаграммы.
Контроллер - это то, что соединяет представления с моделью. Это, вероятно, наименее многоразовая деталь, контроллер знает о модели, знает, какие виды отображает. Обычно контроллер настраивает обратный вызов, который будет вызывать просмотр, когда пользователь взаимодействует с приложением. Затем контроллер получит информацию из модели и обновит представление.
Если вы будете следовать этим рекомендациям, вы можете изменить свою модель, например, изменить модель, которая сохраняет файлы на диск, в модель, которая сохраняет файлы в облаке без изменения пользовательского интерфейса... в теории. Вы также можете добавлять новые виды без изменения модели. Вы также можете написать модульные тесты или регрессионный тест для своих моделей.
Нет строгих правил, лучше всего использовать здравый смысл и собственное суждение.
Обновления/Переписана
Нет, они не ограничиваются доступом к базе данных.
В приложении MVC модель M обычно будет моделью вашего домена. Это означает, что он может инкапсулировать бизнес-логику и данные. Я бы предположил, что вы избежите модели анемичного домена. Вы даже можете настроить свою модель на ненадежность. Чтобы понять, что я имею в виду, посмотрите на этот разговор на Создание злобных доменных моделей.
На стороне View и Controller я рекомендую всегда использовать то, что называется View Model, даже если это похоже на сопоставление от 1 до 1. Рано или поздно вы обнаружите, что модели на самом деле разные, и вы не хотите давать больше никакой ответственности, а затем переводить простой View Model непосредственно в HTML или другой формат рендеринга.
Задача Controllers - это просто выполнить поведение модели и создать модели для представлений.