Бизнес-логика в MVC

контроллер ? хотя там есть всякие вещи типа хелперов, дополнительных библиотек итд.

>контроллер ?

Как вариант, но часто слышал что контроллеры призваны быть длиной пару строк и просто реагирую на запросы пользователя дрегать бизнес слой. Хотя у меня впечатление что это придумали те, кто ничего кроме работы с БД в приложении не выполняет.

Воображение рисует Model разбитую на 2 подслоя: слой DataAcces и слой BuisenessLogic, вот только как они должны взаимодействовать (да и вообще как непревратить код в хлам) непонятно.

У меня назревает идея забить на MVC и просто использовать - View на клиенте, вызывающее на сервере определенные методы, в которых все - и запросы к бд и логика =)

В модели. man ORM.
И модель вовсе не обязана быть просто дергалкой базы. Её задача - отдать данные обратно в контроллер. А уж откуда данные - из базы, аль вычислениями полученные - не столь важно.

> Как вариант, но часто слышал что контроллеры призваны быть длиной пару строк и просто реагирую на запросы пользователя дрегать бизнес слой. Хотя у меня впечатление что это придумали те, кто ничего кроме работы с БД в приложении не выполняет.

Ну вообще используй где удобней. Мне приятнее в контроллере, кому-то в модели. Стараюсь правда что бы модель отдавала только готовые данные, которые бы контроллер тупо отдавал шаблонизатору во View

>И модель вовсе не обязана быть просто дергалкой базы

Это вроде как понятно, но вот примеров и статей в инете на эту тему не нашел. Обычно для простоты считают модель дергалкой базы. Не кинете ссылочкой?

м. боюсь, что нет. точнее, сомневаюсь, что вам пригодится вики и документация к перловому каталисту.

>А что если мне нужно не просто делать CRUD над БД, а постоянно анализировать данные, изменять, делать вычисления и прочее.

А ничего. Модель - это не только "модель доступа к данным". Описал нужные тебе интерфейсы и поведение - и используй откуда хочешь.

>(то, что касается трансформации данных) в контроллеры

Приведи пример. Если трансформация идет в бэкграунде, скажем по крону, то так запускаешь какой-нибудь Client.do_this_thing, если идет в ответ на действия пользователя - вызываешь его же в контроллере. Контроллер остается девственно чист. Угу?

В контроллере, хотя тоже часто приходится глядеть по ситуации)

Твой вопрос также некорректен, как "на каком уровне модели OSI находтся протокол имярек". MVC всего лишь модель.

Если ты оперируешь понятием "бизнес-логика", то наверно тебе лучше рассматривать 3-звенные ИС с их логикой-хранения, бизнес-логикой и логикой представления. Или как-то иначе в соответствии с модной сейчас идеологии "серверов приложений".

Взаимоотношение компонентов MVC упирается в pull-, push- и query модели... А выбор конкретной зависит от твоей предметной области.

Спасибо за интересный ответ! Да, наверное та самая 3-х звенка мне и подойдет. Не подскажите где найти инфу (паттерны, примеры кода желательно). Загуглили по "three-tiered architecture" и что-то как-то не густо.

Отбой. Нашел архитектуру бизнес-приложений фаулера. Читаю=)

> Так вот вопрос - где собственном место бизнес-логике? В модели?

Представь себе — да.

> Но в веб-приложениях обычно модель это модель доступа к данным, т.е. к БД.

Тебе наврали дядьки с квадратно-гнездовыми мозгами. Если бы мне выдали автомат, их бы я расстрелял первыми.

> а частично (то, что касается трансформации данных) в контроллеры.

Заноси обратно в модель. Вот прикинь, что однажды твое приложение перестает быть «веб» и контроллер с представлением отваливаются. Где будет твоя бизнес-лохика?

>Отбой. Нашел архитектуру бизнес-приложений фаулера. Читаю=)

Как страшно жить. Вместо того чтобы читать - надо писать код. Деньги то платят не за прочитанные книги, а за написанные килобайты кода и главное рабочего кода. Бизнес логика, контроллеры, слои сервисов, трехзвенка бла бла бла... а то что в некоторых случаях - довольно простых приложениях, которым я подозреваю ты и занимаешься, это приводит токо к разсиранию кода то никто не говорит. Я бы тебе рекомендовал так: 1. Вьюха 2. Котроллеры 3. Они же (контроллеры лазят в базу и держат весь код) 4. Утилитные классы.

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

>1. Вьюха 2. Котроллеры

В данном случае модель, как тот суслик: его не видно, а он есть. Если используется какой-нибудь ORM, то ты просто перекладываешь на него обязанности по поддержанию модели, а если в "контроллерах" пытаешься обращаться к БД, то со временем утеряешь контроль над обращениями.

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

Если нужно что-то проще, то тогда уже забираться в области event-driven программирования.

>Вместо того чтобы читать - надо писать код.

man "Sharpen the Saw"

> 3. Они же (контроллеры лазят в базу и держат весь код) 4. Утилитные классы.

Приезжай к нам, давно хотели тебе руки поотрывать с особым цинизмом и наслаждением.

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

Так, полистал фаулера. Теперь +100 к чсв )))

> 1. Вьюха 2. Котроллеры 3. Они же (контроллеры лазят в базу и держат весь код) 4. Утилитные классы.

Эта модель у фаулера описывается как Transaction Script. Вполне себе вариант, ведь приложение и правда не сложное.

http://folk.uio.no/trygver/themes/mvc/mvc-index.html . Если анализировать структуру проекта с точки зрения роли обрабатываемых данных, то слоев может получиться гораздо больше: контроль доступа, бизнес-логика, источники данных, диспетчер запросов, представления, шаблоны и т.п. — каждый из которых содержит модели определенного вида.

View > Controller > Service > DAL > Model

в зависимости от сложности приложения можно выкидывать слои. в сложных приложениях BL = service layer

Кароче кому интересно исчерпывающая картина здесь:

http://apparch.codeplex.com/Wiki/View.aspx?title=App%20Pattern%20-%20Four-Tie...(Table%20Module

После N-й итерации прочтения Фаулера вычитал вот что:
В Service Layer в простых случаях можно запихнуть бизнес-логику, тогда он гордо именуется Transaction Script, по сути паттерн Command. Одна операция пользователя, одна комманда с одной транзакцией со всеми нужными действиями внутри.

DAL должен быть отделен от всего остального. Лучше этому следовать всегда.

В простых приложениях с одним вариантом использования (например веб-приложение) допустимо Service Layer запихивать прямо в Controller. Сложив все вместе получаем, что для типичных не сложных приложений на MVC фреймфорке (Rails, Django, Spring MVC) бизнесс-логику можно делать в котнроллере. Что собсно и написано здесь:
http://www.djangobook.com/en/beta/chapter01/

"Django follows the “model-view-controller” (MVC) architecture. Simply put, this is a way of developing software so that the code for defining and accessing data (the model) is separate from the business logic (the controller), which in turn is separate from the user interface (the view)."

Вывод который я вынес для себя - самое главное это отделение бизнесс-логики от представления, все остально в общем-то не важно (ну и еще DAL желательно иметь где-то отдельно).