Как и в любом религиозном споре, тут нет одного правильного ответа. Существует два подхода к этому вопросу: толстые контроллеры и тонкие модели, и наоборот. В первом случае, как нетрудно догадаться, бизнес-логика располагается в контроллерах, во втором — в моделях.
Споры о том, какой из подходов более правильный, ведутся давно и стороны могут нагородить кучу аргументов как за, так и против любой из сторон.
На мой взгляд — оба подхода имеют право на жизнь, но главное не мешать их в одном приложении: выбрать для него какой-то один стандарт и ему соответствовать.
Не знаю как правильно, но я размещаю так:
— логика приложения (она же системная): роутинг, логи, проверка параметров, прав, сохранение и получение данных (вызов всяких load и save), обработка форм, выбор способа отображения (html, xml, json, редиректы, ...), кэширование и т. п. — контроллеры (включая фронтконтроллер)
— логика модели (она же бизнес-логика): действия с данными без учёта их способа хранения (выставить или оплатить счёт, атаковать кого-то или построить здание) — как не странно, модели
— логика отображения: вывести сообщения системы (если они есть, формируются в контроллерах) раскрасить по разному чётные и не чётные строки таблицы, вывести дополнительные блоки (как правило для сайд-баров через вызов других контроллеров) — отображения (шаблоны)
То есть получается, что в модели сосредоточен код, который ничего не знает ни о http-запросах и ответах, ни о БД (или другом способе хранения). Контроллеры просто создают объекты модели, заполняют их, если нужно, данными из хранилища/запроса, вызывает, если требуется, методы модели, и если состояние объектов модели изменилось сохраняет их, после чего передаёт объекты в нужное отображение. Если приложение простое (только CRUD действия), то в модели вообще нет методов, кроме геттеров/сеттеров/делетеров (а иногда и их нет, только данные)
«логику приложения» — это, скорей всего, конроллер. Не принято называть «логикой», хоть она таковой и является, логику хранения и отображения (паттерн MVC). Так что мой ответ в конроллере, а прочее не логика.
В подлиннике примерно так — «архитектура MVC позволяет отделить бизнес-логику от представления». Модель и поведение вместе составляют бизнес-логику.
Модель иногда приравнивают к данным, это в корне неверно. В модель заложена логика для доступа к данным. Состояние модели — это состояние приложения.
логика приложения включает в себя И логику поведения приложения в качестве реакции на действия пользователя (контроллеры), И логику реализации неких алгоритмов (библиотеки), И логику взаимодействия абстракций данных (например классы в моделях). А еще можно приписать логику отображения данных (вьюхи). Так что либо все правы, либо уточните, что вы понимаете под логикой приложения
Строго говоря, бизнес-логика это и управляющая логика контроллеров, и функциональная логика моделей, и эргономическая логика представления. Исходя из этого и надо «разбрасывать» код — по контроллерам, моделям и отображениям.
My<cod/>.net
