Архитектура MVC и слабо типизированные языки (например, PHP) Модель не нужна?

Есть некоторые неправильные представления о термине модель. Платформа Microsoft MVC3 имеет концепцию модели представления, которая представляет собой просто данные, которые вы используете для визуализации своих представлений. Однако это не то, что означает буква M в MVC. Модель включает в себя ваши бизнес-объекты. У нас есть тонкие контроллеры и толстые модели, но очень тонкие модели просмотра. Наши контроллеры вызывают сервисы, выполняющие бизнес-логику, и сами контроллеры никогда не выполняют эту логику. Затем мы переводим наши бизнес-сущности (наши модели данных) и преобразовываем их в облегченную модель представления, которую можно использовать для рендеринга представления.

Итак, чтобы ответить на ваш вопрос

Разве модель не должна просто описывать данные, которые будут передаваться от контроллера к представлению?

Тогда, возможно, вы действительно спрашиваете, не являются ли модели просмотра ненужными? Я не уверен, почему ты так думаешь. Представление модели + представление делает результат. В PHP может быть полезно определить класс с легкодоступными свойствами. Это просто полезно для уточнения ваших ожиданий и предотвращения вызова методов с ужасно длинными наборами или аргументами. В JavaScript нет необходимости определять модель представления как таковую, вы просто добавляете свойства в новый объект и передаете его вместе с представлением в логику рендеринга представления. Это скорее отражение шаблона объектно-ориентированного программирования, который используют эти языки, а не тот факт, что они слабо типизированы.

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

Модель является полезным концептуальным инструментом, даже если в PHP нет строгой необходимости отделять ее от кода БД, например. вы можете иметь объект данных, связанный с каждой таблицей, который инкапсулирует некоторую бизнес-логику, или определить набор бизнес-сущностей, которые объединяют данные по таблицам в объекты, специфичные для предметной области, которые затем могут использовать контроллеры, или просто иметь один монстр-объект БД, который имеет все функции доступа и возвращает сущности. Это имеет определенные преимущества перед тем, как код БД непосредственно используется контроллерами:

• Если вы определяете сложные структуры данных, которые работают в таблицах БД, вы не хотите делать это в коде контроллера из-за риска дублирования — гораздо лучше иметь единое определение, обеспечивающее согласованность во всей системе. Хотя это может привести к зависимостям, наличие одной функции/объекта, определяющей эти данные, позволяет легко выяснить, где используются данные, чтобы вы могли что-то исправить.
• Стороннее обслуживание намного проще, если есть одно место, где можно найти все определения структуры данных.
• Модульное тестирование упрощается, если вы можете поменять всю модель или ее части и заменить их фиктивными объектами, которые будут предоставлять тестовые данные.
• Это делает контроллеры более легкими и, следовательно, более удобными для чтения и обслуживания.

Так что можно возразить, что это не обязательно, но очень помогает.

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

Пока у вас есть некоторая абстракция поставщика данных. Некоторые модели будут выполнять низкоуровневую проверку (тесно связанную с механизмом хранения - нулевые проверки и т. д.), но контроллер «должен» выполнять всю бизнес-логику/проверку.

Лично у меня есть класс с тонкой структурой, который сопоставляется с каждой таблицей (все они реализуют IDataStruct). Эта структура или ее набор — единственное, что перемещается между DomainObject и DataProvider. Затем я могу через свой интерфейс указать, какую структуру данных я должен получать. Это не серебряная пуля, но я обнаружил, что она хорошо работает (упрощает такие вещи, как кэширование и модульное тестирование).

Я надеюсь, что это не запутало проблему.