Жирные модели, тощие контроллеры и шаблон проектирования MVC

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

  • Да

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

    /li >

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

Ответ 2

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

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

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

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