ты дельфи-то юзал хоть раз по нормальному?

Добавлено через 1 минуту и 23 секунды
Тут дело не в дельфи, тут дело в самом программисте. Захочет он использовать MVC/MVP, то будет использовать, а если ему нафиг оно ненуна, то не будет.

  Он делает программу менее чувствительной к изменениям. Если есть правильная модель, то на ее основе можно делать различные представления. Можно изменить функционал сохранив вид. 

Cocoa?

если опираться на ту нуДную статью и на пример  с чекбоксом, то можно использовать DevExpress

Наверное, имелось ввиду для Delphi?

По-моему имелось в виду вообще.

Зачем ему вообще, если здесь речь о Delphi?

Дельфи не нужен  

говори токма за себя   

Паттерн MVC, как я думаю, придуман для веба. На вебе, ввиду гетерогенности, презентативный слой технологически изолирован от слоя логики, а попытки сделать прозрачным взаимодействие этих слоев пока нелепы. MVC это вынужденный компромисс переходного периода.
Десктопные приложения,  даже не будучи гомогенными, имеют куда более развитые средства взаимодействия промеж сообой. Казалось бы выдели прикладную логику в COM да дергай ее из любой морды, сервиса и бла-бла. Прикладная логика отдает сложный объект, вроде резалтсета - да бога ради, с этим можно как-то справиться. Особой нужды тут в следовании MVC как бы и не прослеживается.

Вот и спрашивал, есть ли  прецеденты. k0rvin, спасибо.

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

Добавлено @ 19:37

Если уж на то пошлло..... классическая делфийская связка DataSet-DataSource-<data aware controll> как бы вполне себе в писывается в MVC. Когда-то я даже понимал зачем это надо, теперь, увы, забыл.

Это сообщение отредактировал(а) Zloxa - 18.7.2012, 19:40

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

Собственно кроме Cocoa, думаю, можно посмотреть современные реализации SmallTalk.

Добавлено через 6 минут и 27 секунд

Я бы не стал этого утверждать. А смысл DataSource'а я так и не понял.

Почему?


Если смотреть со стороны контролла, который может взять данные напрямую из датасета, то да, как бы не особо понятно зачем лишний слой. Но если смотреть от датасета, датасету нафиг не нужно знать какие контроллы от него ведутся, как и когда их обновлять, об этом знает датасурс. Емнип, датасурс так же управлятет буферами контроллов. У тебя уже есть грид, который показыват пять строк, ты динамически добавляешь новый, который будет уже показывать 10 строк. Данные надо считать, при этом позицию курсора не сбить...

MVC было описано или придумано ещё в конце 70х.
Я уверен, что если бы в Delphi был так сильно нужны приёмы MVC, то их бы уже давно жёстко применили, описали в справке, книгах и т.д.

Как я уже говорил, то это дело программиста. Он может сделать жёсткую связку СУБД->SQL-запрос(DataSet, Query)->отображение на экране, а может сделать на уровне MVC, т.е. запрос изменил и данные отображаются другие.
По идее в наследниках DataSet столбцы для отображения данных могут создаваться динамически в момент запуска приложения или в момент создания модуля.

Вот пример.
1. Создаем таблицу в базе.
2. Создаем представление на основе таблицы (View).
3. В TQuery делаем запрос к представлению select * from view.
4. Соединяем TDBGrid с TQuery. В design-time никаких столбцов не создаем у TQuery, т.к. их TQuery создаст сам на основе выборки.
5. Теперь нам достаточно открыть TQuery и в гриде появятся нужные столбцы.
6. Допустим, что пользователь захотел, чтобы в гриде данные отображались в другом порядке или какой-то столбец не нужен.
Изменяем представление (view): убираем оттуда столбец и меняем порядок  других столбцов, хотя, на клиенте это всё тоже можно сделать настройками грида.

6а. Допустим, что пользователь хочет, чтобы в выборке больше не показывались записи из архива.
1. Изменяем представление (view): и добавляем там условие where deleted=0 и всё.
2. Приложение перекомпилировать не нужно.


6б. Допустим, что пользователь хочет, чтобы второй столбец был не текстовым, а датой и чтобы в гриде была при этом правильная сортировка, фильтрация, группирование и соответствующий редактор был, т.к. для даты нужен уже календарь.
1. Добавляем новое поле или изменяем тип старого. Изменяем представление (view): в запросе представления меняем второе поле или просто перекомпилируем в СУБД само представление (view).
2. Теперь TQuery в выборе получит второе поле уже не текстовое поле, а дата, грид создаст на основе типа поля уже соответствующий редактор.

Чем вам не MVC?

Добавлено @ 10:58

ну там есть некоторые события, которые помогают, например при связке Master-detail

Akella, в терминах MVC view  это форма, а не вьюха СУБД. То что ты описал - совсем не MVC.

и что с того, я просто применил не тот термин и всё