Перечитав ваш вопрос несколько раз и немного подумав, я думаю, что суммировал бы ситуацию следующим образом:
М "отсутствует" в вашем "MVC".
На данный момент вы создали схему реляционной базы данных вручную, так что она имеет отображение 1: 1 с вашей моделью домена.И это здорово, это делает сопоставление очень простым, но набор записей все еще не является классом домена.
Термин Модель в контексте MVC относится к модели домена , а не реляционная модель .Если у вас есть реляционная база данных, поддерживающая это приложение, то вам нужно какое-то отображение.Это не значит, что вам нужна полноценная платформа ORM, такая как Doctrine - хотя я нахожу, что эти инструменты значительно облегчают мою жизнь, даже для небольших проектов - но вам нужно что-то .На самом деле Zend Framework даже подробно описывает отображение модели домена в Quick Start .
Я не думаю, что вам нужно удалять TDG.Абстракции хороши.Я хотел бы сравнить его с тем, чтобы сделать ваше приложение немного более компактным, и пойти в офисное здание и разорвать телефонную систему на том основании, что сотрудники могут просто использовать свои мобильные телефоны.Они могут , но вы не хотите их, точно так же, как вы не хотите, чтобы ваши представления бросали запросы SQL непосредственно в базу данных.Это неэффективно и, как правило, трудно управляемо.
Моя версия архитектуры будет выглядеть следующим образом:
Request --> Controller
| <--> sanitizes and returns Request params
| ---> Facade (encapsulates steps to fetch View Data)
| | <--> Table Data Gateway builds Query for requested View
| | <--> Query Decorator applies User/Client settings
| | <--> DB Adapter fetches RecordSet from decorated Query
*** | | <--> Mapping layer converts RecordSet to Domain Model
*** | <----returns Model
*** | <--> applies Model to View
*** | <--> Data-Aware ViewHelper render Model (and View)
Response <--returns rendered View
Я пометил строки изменений как ***.Действительно, единственное, что я изменил, это то, что вместо того, чтобы собирать набор записей с фасада, он выбирает модель (вероятно, массив классов домена) и применяет , что , к представлению.
Вместо таких терминов, как $row['Status'] в вашем View [Helper], у вас будет $event->status, что безопаснее и проще в долгосрочной перспективе.Там нет названия столбца, только свойство.
Теперь вы прямо упомянули в самом верху своего вопроса, что у вас нет ORM, поэтому я думаю, что вы, вероятно, знаете о большей части этого и, возможно,просто нужен толчок.Вероятно, эти ноющие сомнения в вашем уме имеют вид: Что, если он не всегда доступен только для чтения?Что если модель данных станет более сложной?Что, если люди начнут запрашивать более сложные отчеты?
Все это является причиной, по которой у вас есть модель предметной области, почему она фактически является фундаментальным строительным блоком MVC: в конечном счете, ментальная модель вашейу пользователей будет не синхронизироваться с моделью данных по ряду причин, о которых я не буду здесь говорить.Дело в том, что это почти всегда происходит.
Я уверен, что это необходимо?Я уверен, что это не просто излишество, куча ритуальных заклинаний, которые не имеют смысла для такого маленького проекта?
Нет, я не такой.Только вы можете решить это.Что я могу сказать вам, так это то, что парадигма MVC как специфической архитектуры не принесет вам большой пользы без правильной доменной модели.Это немного лучше, но не , что намного лучше, чем просто наличие встроенных запросов или фасадных вызовов на каждой странице.Без модели MVC - это не более, чем причудливая схема перезаписи URL.
Может быть, вам нужен этот уровень абстракции, а может и нет;но я предполагаю, что вы, вероятно, подозреваете, что могли бы, иначе вы бы не задали вопрос.Подумайте об этом, проанализируйте текущие требования и область применения, спросите себя, какие изменения вероятны, и если текущая архитектура кажется слишком хрупкой, чтобы приспособиться к этому, тогда следующим логическим шагом будет модель предметной области - даже если сегодня это просто точное зеркало реляционной модели.Завтра это может быть не так.
Надеюсь, что это именно тот ответ, который вы искали!