вопрос дизайна MVC

Question

Я использую Zend Framework и доктрину в этом приложении

В моем веб-приложении у меня есть различные отдельные модули, такие как события, конференции, тематические исследования ... так что сейчас я делаю дизайн контроллера. На рисунке ниже нормативным документом является контроллер, а его подчиненным - его действия. Таким образом, нормативные документы, видео, подкасты имеют практически одинаковую функциональность. так уместен ли этот дизайн ...? В mvc для каждого действия у меня будет отдельный вид. И по типу пользователя мне, возможно, придется поставить уровни доступа на эти модули. поэтому я сохранил отдельный контроллер, чтобы я мог легко управлять модулем для каждого типа пользователя. Но это приводит к дублированию кода.

Теперь я думаю сделать один родительский класс, и в этом у меня будут все общие методы. например. У меня будут общие ресурсы класса, и я буду хранить список, искать, предлагать, добавлять избранное и т. Д. И это будет родительским элементом для указанных выше контроллеров.

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

Answer 1

Я бы посоветовал сохранить все контроллеры, чтобы у них были хорошие URL и четкая структура в модулях, однако контроллеры должны быть тонкими. Поместите свою доменную логику в Службы или Объекты, поэтому дублирование кода (или просто меньшее) не требуется.

Подробнее:

• Уровень MVC + Service распространен в Zend или PHP?
• Как реализовать сервисный уровень в Zend Framework?

От DDD:

• http://domaindrivendesign.org/node/118

контроллеры относятся к прикладному уровню / логика домена принадлежит доменному уровню

Answer 2

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

Answer 3

Если я вас правильно понимаю, у вас есть ряд общих поведений среди ваших нормативных документов, видео и подкастов.

В этом случае вам, вероятно, следует попытаться абстрагировать общие черты в родительский класс, от которого наследуются эти три области.

В качестве примера, у меня есть своя собственная структура MVC, в которой я определяю суперкласс tnh_controller, от которого наследуются мои другие контроллеры (например, venue_controller, group_controller). В родительском контроллере я определяю методы header () и footer () и delete (). Затем я могу использовать их в детских классах и сэкономить немного усилий.

Вы также можете выполнить некоторые общие задачи для своих моделей (CRUD) в суперклассе моделей, переопределяя их только по мере необходимости. Большая часть логики для разных моделей основана на переменных класса (имена таблиц, имена столбцов и т. Д.).

Я бы не стал слишком беспокоиться о том, чтобы быть "строгим" MVC. Вместо этого попытайтесь решить, что сэкономит ваше время и сохранит ваш код организованным. Звучит так, будто вы на правильном пути, ведя подобное поведение на родительском уровне.

Answer 4

Проектирование MVC означает, что для каждого вида у вас есть контроллер и модель.Однако модели вообще не должны быть классами или иметь разные модели для каждого MVC.Обычно вы делите модель между несколькими MVC, или ваша модель может быть целочисленным значением, которое вы определяете в собственном контроллере.Обычно вы можете даже захотеть обмениваться данными между ними, тогда у вас будет одноэлементный режим:

http://www.galloway.me.uk/tutorials/singleton-classes/