Товарищи, если вы в таком ключе продолжите рассуждать, то придете к тому что при наезде мышкой на Кнопку та отправляет сообщение контроллеру "Боже, на меня наехали!", тот срочно требует у модели изменить состояние на "кнопка К в состоянии наезда" и модель кричит кнопке "меняй стейт на "наехали"!"
Имейте совесть - зачем контроллеру знать о каком-то драге, с этим прекрасно справится вью. Вот когда действие будет совершено и объект отпустят - тут другое дело.
Взять те же шахматы. Вот начало игры, модель выставила фигуры... Кто делает ход? Ну ОК, допустим предполагается изначально, что Игрок. Вот он хватает фигуру и опускает ее на какую-то клетку. Кто сейчас решает - будет ли фигура поставлена на эту клетку? (зависит от фигуры, правил ее хода, и клетки) Что Вы выберете - Вью или Модель? Кому отдадите эту логику? Вью вроде как по барабану, ее дело - отобразить. Модель должна решать, останется ли фигура на клетке и ход перейдет машине, или фигура вернется и ход останется за игроком? Как по мне - Контроллер здесь на лицо. От того, что вы запихнете его в модель - суть не изменится. Это логические операции, и они должны осуществляться контроллером. Я уже не говорю о рассчете ответного хода машины.

Добавлено через 15 минут
Что бы там ни говорили на вики - Решения должен принимать Контроллер, никак не Модель. Говорить, что Модель - это НЕ база данных, было бы справедливо в одном случае - если бы в этой архитектуре была еще и База Данных. Но она как раз и представлена Моделью, обзывайтесь как хотите. Кто-то должен хранить состояние, и этот кто-то - не Вью и не Контроллер. Здесь Модель мира - это доска: положения фигур, тактические очки игроков, состояние "чей ход", таймер и замечания судей. Но вовсе не Модель решает, куда сходить и сколько очков дать за ценность хода. Максимум, что она может делать сама - считать время, но и здесь на самом деле Таймер это отдельный маленький контроллер, МЕНЯЮЩИЙ состояние параметра "время" Модели))

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

В контроллере может быть или не быть проверка, но в моделе она бать обязана. Это называется «целостность данных», и даже если бы модель была просто базой данных, база данных все равно должна за этим следить!
Интеллект может рассчитывать контролер, так как по сути он симулирует действие того же пользователя, только в качестве пользователя выступает программа.
Откуда по вашему растут ноги у правила что у классов не должно быть открытых членов, и они должны быть заменены на свойства(гетеры/сетеры)?

Вообще, при проектировании баз данных, правильно формировать всю бизнес логику на стороне базы данных. Это гарантирует, что кто бы не работал с данными, сколько бы у нее не было клиентов, она работала правильно. Это в эпоху веб программирование про это забывают, из-за ограничений mySql. Хотя на самом деле те, кто пишут серьезные приложения не забыают, просто для написания сайтов это не нужно, поэтому некоторые веб программисты как не знали, так и не знают.
Но это лирическое отступление. А по поводу того, что логика находится в контроллере а не в моделе... Конечно так можно сделать. Только это уже будет не MVC вовсе.
Это говорит мне не только вики, а само название «модель», «здравый смысл» и интернет:)
http://www.rsdn.ru/article/patterns/...wPresenter.xml
http://chtivo.webhost.ru/articles/mvc.php
...

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

Кстати, мне кажется, что с MySQL у Вас та же ситуация, что и с PHP ))
Внутри MySQL несколько технологий и, скажем, если работать в модели innoDB, то там и транзакции есть и хранимые процедуры и вообще много чего.

2Jack
Да кто вам такое сказал? Вы прочитали на вики один из вариантов MVC и принимаете его за истину в последней инстанции. Даже если первоначально в smartTalk это было так, то при развитии идеи от этого отказались
DocumentView, MVP, MVVP - не перестают быть от этого mvc - главное отделение данных от вида.
само слово данные (модель) уже говорит, что это может быть просто БД. При добавлении контроллера мы и бизнес логику отделяем от греха подальше.
А за бизнес логику в sql надо бить. Есть конечно исключения, когда они продиктованы производительностью ( мол лучше в одном запросе получить сложную выборку через хранимые процедуры), но они только подтверждают правила.
А вообще мне пофик. Что я тут распинаюсь)
Вы пока теоретик, вот и теоретизируйте себе по вики и учебникам. Я как практик говорю: логики в модели не должно быть.
Вы хотя бы прочитайте ссылки, которые сами постите.

Безусловно зависит от контекста, но в общем случае не надо искать то чего нет.
Это дело представления как отобразить перетаскивание - она может просто переместить элемент, добавить анимацию вокруг него, сделать колебания вокруг новой позиции.
Моделе в данном случае надо только знать - была позиция одна, элемент переместился (и остался на позиции 2).

Не совсем. На текущий момент MySql уже вполне похожа на нормальную реляционную базу данных с хранимыми процедурами, триггерами и т.д. Но так было не всегда...
В свое время я как раз очень серьезно с этим столкнулся... Тот период жизни, когда я начал делать сайты и юзать mysql, я пришел с разработки бизнес приложений, и то как я привык работать с базами данных, принципе было не возможно на mySql...
Но вопрос не в том, что сейчас умеет mySql, а что он умел, когда формировались веб программисты в своем большинстве...

Добавлено через 5 минут
:eek:
Откуда такая информация?
Стало быть у вас большой опыт написания бизнес приложений?

Кстати, хранимая процедера для создания отчета - это не логика....

Джек, я не вижу смысла этот странный спор продолжать. Вы прекрасно понимаете, что кто-то контролирует поступающие данные и принимает решения об изменении состояния модели или вью. Ваша модель такая вся из себя, сама ходит, сама говорит - отлично. Сама переводит себя в состояние "я показываю пользователю системное окно об ошибке" (видимо так, иначе кто заставит Вью это показать - контроллера ведь нет). Всё, что нужно - это попытаться отделить в своем сознании контроллер от базы данных (их союз Вы сейчас называете "моделью"), и все встанет на свои места. Окажется, что контроллер никак не противоречит "здравому смыслу". Модель хранит Состояния, Контроллер отвечает за Действия, а Вью предоставляет интерфейс для показа Состояний пользователю и получение от него Действий. Удачи.

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

В случае, который описывали вы я бы сообщал через контроллер о новых координатах нодов в модель. Модель бы определяла имеется ли пересечения, и если да то ... только в этом случае, модель диспатчит об необходимости изменения чего либо.
А вообще возможно более удачной была бы реализация не MVC-архитектуры а MVP? Тоже популярное решение.

Wolsh системные окна об ошибках должен бы давать команду показывать контроллер, когда это было функционалом модели?

Как то противоречиво. я наоборот говорил, о том что делайте так как лучше, не обращая внимания на классику.
Кстати mvp - это практически перекладывание всего на контроллер, и это всё равно mvc.

Вот в этом и разница. Для многих MVC - стало собирательным понятием. А между тем MVP это MVP, а MVC это MVC. Если MVC - не актуален, и вы изменили роль и принципы взаимосвязи компонентов, никто не говорит, что вы не правы или, там, делаете неправильно, но это уже не MVC, иначе получается путаница какая то.

Кажется у этого всего есть определение: Реализация взаимодействия слабосвязанных компонентов программы.