Принципы MVC во фреймворке HLEB2

25 Февраля (ред)

Структура проекта, объявленная как Model-View-Controller (Модель-Вид-Контроллер) давно не нова, к тому же, часто неправильно трактуется при использовании в Web, особенно в отношении backend.

Классическое взаимодействие подразумевает круговорот между этими частями приложения, по отношению к backend-фреймворку это означает следующее: сначала запрашивается Контроллер, затем при помощи Модели данные запроса преобразуются в данные ответа, а затем данные ответа преобразуются в нужный формат через Вид. При этом последовательность здесь скорее CMV, а не MVC, также может быть задействован только Контроллер для отдачи результата или только Вид для простых ответов, без участия Модели.

Существует более подходящий для такой разработки принцип Action-Domain-Responder (Действие-Домен-Ответчик), и при соответствии Controller→Action, Model→Domain, View→Responder видно, что их порядок здесь уже более подходящий под Веб. Об ADR можно достаточно много найти информации в сети Интернет.

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

Непонимание это может возникать из-за того, что сам фреймворк реализует MVC для простого «Hello world» без особых проблем, во фреймворке нет и не должно быть логики конкретного приложения. Поэтому возникает вопрос — где она должна находиться. Так как всем известно, что Контроллер и Вид совсем для этого не подходят, остаётся только Модель.

При этом понимание Модели может быть как смесь «объектной модели данных»(Data Mapper) и «доменной модели», где первое составляющее будет проекция доменной модели в некий репозиторий, второе - логическое представление некоего процесса или структуры, не привязанное к технической реализации своего функционирования. «Доменная модель» — здесь образ реального процесса, который нужно имитировать в логике приложения. В ADR Модель именно поэтому и названа Доменом. Если мы разделим Домен на данные его состояния и логику работы, то выясним, что для взаимодействия с данными(в объектно-ориентированном стиле) больше подходит Модель, а для логики какая-либо иная структура, которая может называться как угодно, в зависимости от того, для чего данное приложение предназначено. Мы можем назвать её Logic, но это понятие не будет характеризовать абсолютно любое приложение на основе фреймворка.

В силу этих противоречий можно как угодно трактовать понятие Модели, так как при инициализации фреймворка демонстрационный класс DefaultModel только предлагает реализацию, не делая её обязательной. Вообще, при создании фреймворка не учитывалось, что он каким либо образом будет влиять на архитектуру приложения, созданную на основе этого фреймворка.

Проще говоря, Модель во фреймворке HLEB2 - это обёртка над базой данных, которая может использоваться в логике приложения. Логика приложения отдаёт данные в контроллер и далее формируется Вид. Мы не могли бы назвать Моделями все части(классы) логики, поэтому в данном случае под Моделью подразумевается объектно-ориентированная модель данных, которая также, как Контроллер и Вид, не может включать в себя реализацию логики работы приложения.

Это статья является дополнением к объяснению принципов MVC для первой версии фреймворка.

fomiash fomiash + 200
Опубликовано в PHP фреймворк HLEB
Для ответа вы можете авторизоваться


Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.