Жирные модели, узкие контроллеры и шаблон дизайна MVC

Question

Я только что прочитал сообщение в блоге , которое объясняет MVC банковской аналогией. У меня есть несколько месяцев опыта в разработке веб-приложений с использованием инфраструктуры MVC (CakePHP), поэтому я получил основы, но я начал видеть тему, которая заставила меня думать, что я придерживаюсь некорректного подхода к тому, где я изложил свою логику:

• Толстые модели, тощие контроллеры
• Сохраняйте как можно больше бизнес-логики в моделях

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

Сканируя мои контроллеры, я теперь могу определить много логики, которая, вероятно, должна идти в модели:

• Приложение имеет списки, которые содержат элементы, и элементы могут быть ранжированы. Логика сортировки, которая размещает список в ранжированном порядке, находится в контроллере.
• Аналогично, элементы (модель элемента) также имеют изображения (модель изображения). Каждый элемент может иметь изображение по умолчанию (обозначается как image_id в таблице элементов). Когда элемент отображается с его изображениями, изображение по умолчанию должно появляться первым. У меня есть логика, которая делает это в контроллере.
• Когда отображается список, связанные списки отображаются на боковой панели. Логика для определения того, какие списки связаны, находится в контроллере.

Теперь на мои вопросы:

1. С примерами, которые я привел выше, я на правильном пути, думая, что это примеры логики в настоящее время в контроллере, который принадлежит модели?
2. Какие еще области логики, общие для веб-приложений, должны использоваться в моделях?
3. Я уверен, что выявить эту проблему и изменить мой шаблон проектирования - полдела, но даже если я решу взять те примеры, которые я привел выше, и попытаться перенести эту логику в модель, я не знаю, с чего начать , Может ли кто-нибудь указать мне правильное направление, разместив здесь некоторый код или ссылки на хорошие учебные ресурсы? Специальная помощь для CakePHP была бы полезна, но я уверен, что чего-нибудь MVC будет достаточно.

Answer 1

Немного сложно дать вам «правильные» ответы, поскольку некоторые из них имеют дело со спецификой структуры (независимо от тех, с которыми вы работаете).

По крайней мере, с точки зрения CakePHP:

1. * 1006 Да *

2. Все, что связано с данными или манипулированием данными, должно быть в модели. С точки зрения CakePHP, как насчет простого метода find ()? ... Если есть вероятность, что он сделает что-то «особенное» (то есть напомнит конкретный набор «условий»), который вам может понадобиться в другом месте, это хороший повод для включения в метод модели. *

3. К сожалению, простого ответа никогда не бывает, и рефакторинг кода является естественным процессом. Иногда вы просто просыпаетесь и говорите: "Святые макароны ... это должно быть в модели!" (ну, может быть, вы этого не делаете, но у меня есть:))

Answer 2

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

1) Если я напишу юнит-тест, то легко создать только один «реальный» объект для тестирования (= объект, который вы используете в производстве) и не включать в себя множество других, за исключением, возможно, некоторых ценные объекты. Потребность как в реальном объекте модели, так и в фактическом объекте контроллера для выполнения теста может быть сигналом о необходимости перемещения функциональности.

2) Задайте себе вопрос: что, если бы я добавил другой способ использования этих классов, нужно ли мне дублировать функциональность почти так же, как копировать-вставить? ... Это также, вероятно, веская причина для перемещения этой функциональности.

также интересно: http://www.martinfowler.com/bliki/AnemicDomainModel.html