Толстые модели, тонкие контроллеры и шаблон проектирования MVC
Я только что прочитал Сообщение блога, который объясняет MVC с банковской аналогией. У меня есть несколько месяцев опыта разработки веб-приложений с фреймворком MVC (CakePHP), поэтому я получил основы, но я начал видеть тему, которая заставила меня подумать, что я использую ошибочный подход к тому, куда я помещаю свою логику:
- Толстые модели, худые контроллеры
- Сохраняйте в моделях как можно больше бизнес-логики
В моем приложении модели страдают анорексией, а контролеры страдают ожирением. У меня есть вся бизнес-логика в контроллерах и ничего, кроме ассоциаций и правил проверки в моделях.
Просматривая свои контроллеры, я теперь могу определить много логики, которая, вероятно, должна входить в модель:
- В приложении есть списки, которые содержат элементы, и элементы можно ранжировать. Логика сортировки, которая помещает список в ранжированный порядок, находится в контроллере.
- Точно так же предметы (модель предмета) также имеют изображения (модель изображения). Каждый элемент может иметь изображение по умолчанию (обозначенное image_id в таблице элементов). Когда элемент отображается с его изображениями, сначала должно появиться изображение по умолчанию. У меня есть логика, которая делает это в контроллере.
- Когда отображается список, связанные списки отображаются на боковой панели. Логика определения связанных списков находится в контроллере.
Теперь к моим вопросам:
- С примерами, которые я привел выше, правильно ли я считаю, что это экземпляры логики в контроллере, который принадлежит модели?
- Какие еще области логики, общие для веб-приложений, должны входить в модели?
- Я уверен, что выявить эту проблему и изменить свой шаблон проектирования - это половина дела, но даже если я решу взять те примеры, которые я привел выше, и попытаться перенести эту логику в модель, я бы не знал, с чего начать. Может ли кто-нибудь указать мне в правильном направлении, разместив здесь код или сославшись на хорошие учебные ресурсы? Специальная помощь CakePHP была бы отличной, но я уверен, что всего MVC будет достаточно.
Ответы 2
Я использую по крайней мере эти два «теста», чтобы проверить правильность моей логики:
1) Если я напишу unittest, легко создать только один «настоящий» объект для тестирования (= объект, который вы используете в производстве) и не включать множество других, за исключением, возможно, некоторых объектов значений. Необходимость как фактического объекта модели, так и фактического объекта контроллера для выполнения теста может быть сигналом, что вам нужно переместить функциональность.
2) Задайте себе вопрос: что, если я добавлю еще один способ использования этих классов, мне нужно будет дублировать функциональность почти копипастом? ... Вероятно, это также хорошая причина для переноса этой функции.
тоже интересно: http://www.martinfowler.com/bliki/AnemicDomainModel.html
Сложно дать вам «правильные» ответы, поскольку некоторые из них связаны со спецификой фреймворка (независимо от того, с чем вы работаете).
По крайней мере, с точки зрения CakePHP:
да
Все, что связано с данными или манипулированием данными, должно быть в модели. Что насчет простого метода find () с точки зрения CakePHP? ... Если есть шанс, что он сделает что-то «особенное» (например, вызовет определенный набор «условий»), который может вам понадобиться где-то еще, это хороший повод для обертывания внутри метода модели.
К сожалению, никогда не бывает простого ответа, а рефакторинг кода - естественный процесс. Иногда просто просыпаешься и говоришь: «Святые макароны ... это должно быть в модели!» (ну, может, ты этого не делаешь, но у меня есть :))
Автор блога пишет победный ответ FTW!
Обо всем этом слышал раньше :)