Бизнес-логика в конроллере или модели?

Question

[endo]

Возник такой спор с коллегами, где же правильно размещать логику приложения.



Что можете подсказать?

Comments

[endo]

правильно написал, что логика приложения состоит из логик контроллера, модели и вида. Но в данном случае интересует именно моменты, не связанные с их непосредственными действиями, например, аналитическая обработка данных, связанная с работой нескольких моделей. Если эта логика находится в контроллере, то он вызывает обе модели и получает результат, а если в модели, то она (модель) вызывает другую модель и возвращает результат контроллеру.

[endo]

Нашел хорошее и подробное описание, с которым полностью согласен code.google.com/p/yii/source/detail?r=2672

Answer 1

[helios]

Как и в любом религиозном споре, тут нет одного правильного ответа. Существует два подхода к этому вопросу: толстые контроллеры и тонкие модели, и наоборот. В первом случае, как нетрудно догадаться, бизнес-логика располагается в контроллерах, во втором — в моделях.

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

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

Comments

[endo]

Спасибо =)

Answer 2

[Владимир Чернышев]

Не знаю как правильно, но я размещаю так:
— логика приложения (она же системная): роутинг, логи, проверка параметров, прав, сохранение и получение данных (вызов всяких load и save), обработка форм, выбор способа отображения (html, xml, json, редиректы, ...), кэширование и т. п. — контроллеры (включая фронтконтроллер)
— логика модели (она же бизнес-логика): действия с данными без учёта их способа хранения (выставить или оплатить счёт, атаковать кого-то или построить здание) — как не странно, модели
— логика отображения: вывести сообщения системы (если они есть, формируются в контроллерах) раскрасить по разному чётные и не чётные строки таблицы, вывести дополнительные блоки (как правило для сайд-баров через вызов других контроллеров) — отображения (шаблоны)

То есть получается, что в модели сосредоточен код, который ничего не знает ни о http-запросах и ответах, ни о БД (или другом способе хранения). Контроллеры просто создают объекты модели, заполняют их, если нужно, данными из хранилища/запроса, вызывает, если требуется, методы модели, и если состояние объектов модели изменилось сохраняет их, после чего передаёт объекты в нужное отображение. Если приложение простое (только CRUD действия), то в модели вообще нет методов, кроме геттеров/сеттеров/делетеров (а иногда и их нет, только данные)

Answer 3

[markeev]

«логику приложения» — это, скорей всего, конроллер. Не принято называть «логикой», хоть она таковой и является, логику хранения и отображения (паттерн MVC). Так что мой ответ в конроллере, а прочее не логика.

Comments

[Владимир Чернышев]

Видимо, потому что «не принято» и «прочее не логика».

Answer 4

[Vasya_Sh]

Где должна быть логика, наглядно иллюстрирует классическая схема:

Answer 5

[Vasya_Sh]

В подлиннике примерно так — «архитектура MVC позволяет отделить бизнес-логику от представления». Модель и поведение вместе составляют бизнес-логику.
Модель иногда приравнивают к данным, это в корне неверно. В модель заложена логика для доступа к данным. Состояние модели — это состояние приложения.

Answer 6

[tzlom]

бизнес-логика — в домене

Answer 7

[shsmad]

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

Comments

[endo]

Коллеги считают, что подход, используемый в Rails правильный:
The bulk of your application’s business logic will be concentrated in the models. (http://guides.rubyonrails.org/getting_started.html)

Answer 8

[casey]

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