http://www.martinfowler.com/bliki/AnemicDomainModel.html

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

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

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

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

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

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

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

Ответы на вопрос(2)

Решение Вопроса

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

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

да

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

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

 Xeoncross14 февр. 2012 г., 23:33
Автор блога пишет победный ответ FTW!
 andyk25 янв. 2009 г., 20:17
красиво положил. И хороший пост в блоге тоже.

чтобы проверить, правильная ли моя логика:

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

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

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

Ваш ответ на вопрос