Как Вы смоделировали бы это приложение?

Перечитав свой вопрос несколько раз и немного поразмыслив над ним, Я считаю, что резюмирую ситуацию следующим образом:

Буква «M» отсутствует в вашем «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

Я пометил строки изменений *** . На самом деле, единственное, что я изменил, это то, что вместо того, чтобы брать набор записей с фасада, он выбирает модель (вероятно, массив классов предметной области) и применяет , что к View.

Вместо таких терминов, как $ row ['Status'] в вашем представлении [Helper], у вас будет $ event-> status , что безопаснее и проще в обслуживании. в долгосрочной перспективе. Там нет имени столбца, только свойство.

Теперь вы прямо упомянули в самом начале своего вопроса, что у вас нет ORM, поэтому я думаю, что вы, вероятно, знаете о большей части этого и, возможно, вам просто нужно подтолкнуть.Эти мучительные сомнения в вашей голове, вероятно, примерно такие: Что, если он не всегда доступен только для чтения? Что, если модель данных станет более сложной? Что, если люди начнут запрашивать более сложные отчеты?

Все это является причиной того, почему у вас есть модель предметной области, почему она фактически является фундаментальным строительным блоком MVC: в конце концов, ментальная модель ваших пользователей будет не синхронизируются с моделью данных по ряду причин, которые я здесь не буду вдаваться. Дело в том, что это происходит почти всегда.

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

Нет, нет. Только вы можете это решить. Я могу сказать вам, что парадигма MVC как специфическая архитектура не принесет вам много пользы без правильной модели предметной области. Это немного лучше, но не , что намного лучше, чем просто встроенные запросы или вызовы фасадов на каждой странице. Без модели MVC - не более чем модная схема перезаписи URL.

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

Надеюсь, что это именно тот ответ, который вы искали!