xpin2013
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
У меня вопрос, суть которого проще понять после моего, возможно корявого пояснения (на случай поспорить - я пас, пояснение оно только для вопроса).
Простите новичка, недавно столкнулся с необходимостью узнать, что такое MVC (Model View Controller), в руках исходники с MVC. Я под впечатлениями, как от исходников, так и от того что в интернете бросилось в глаза.
1) Модель - обёртка данных. Смысл её существования в обеспечении отдельного развития модели от конечных реализаций. Неоднократно делаются замечания, что хороший тон, это когда бизнес-логика закладывается в модели. Ну это понять просто, например, - бизнес-логика в триггерах, а никак не в событиях датасета. Зачем же Модель, то есть обёртки? Использование модели уже отменяет технологию DB->DataSet->DBControl и обязывает продублировать работу с данными - данные изменяются и в модели и в файле DB. Оказывается Controller умеет строить модель независимо, - либо он читает данные из датасета/базы и заполняет коллекцию/список, либо строит её не связанно с базами, - на момент существования процесса или задачи. Остальной код не знает как заполнять обёртки и использует для этого контроллер. (сомневаюсь, что ради этого можно согласиться на дублирование данных, когда нам не хочется использовать ClientDataSet мы его не используем).
2) View - представление. Тут понятно, если мы добавили поле в модель, мы его добавляем в гридину, всё так же как обычно за исключением - это не DBControl, нет датасетов/датасурсов. Мы из обёрток вытаскиваем строки и передаём их в грид. Если не ошибаюсь в сишарпе это метод Fill тоже какого-то контроллера, но вызывает его именно представление. Почему View мы связываем с моделью, а не с датасетом? Чем можно заменить технологию событий протекающих через DataSource? Ну есть пассивный MVC - обёртки есть, событий их изменений нет. Есть активный, в классическом варианте MVC - это активный MVC. В этом случае View подписывается на события модели, у меня десяток View - 5 подписалось на события одного справочника, а 5 подписалось на события другого. Там в сишарпе событие это не один обработчик OnChanged, а сколько угодно все происходят пачкой последовательно. В шарпе это реализовано на уровне языка и понятно, почему можно согласиться на MVC, для чего пассивная модель может быть использована в Delphi совершенно теряюсь, для активной модели приведу свой суррогат/заменитель
Подробнее...
Для своего типа события свой класс-реализация с тремя методами. Думаю легко переделывается в генерик, у меня их ещё не было. Про пассивную модель я понял, что к ней отношение негативное. Хотя у меня в той программе именно пассивная модель, мне стало интересно понять плюсы MVC, кроме тех, что если в Delphi MVC, то заказчику кроме меня никто не поможет, он побежит ко мне. Но хоть и реальный плюс - озвучивать его не желательно.
3) Контроллер. Ну если модель не знает как хранятся данные, то она и не умеет их удалять из DB файла. Это делает, на сколько понимаю контроллер - даёт команду удалить из модели и сразу же удаляет из файла, или тоже является подписчиком и удаляет когда модель генерирует событие удаления. Контроллер можно выбирать, тут я вообще не ориентируюсь - зачем? View обязан знать модель, чтобы её отобразить, но вроде, чтобы поменять данные, - он просит контроллер. Это как если бы мы хотели AfterInsert перенести в контроллер, бизнес-логику из AfterInsert распихать по модели, а что касается того, что у меня изменения и в базе и в модели, так это остаётся в контроллере. Ну пока для меня это тихий ужас, который простителен, если речь идёт о том, что это не в Delphi и нет DataSource.
Наконец то добрался до вопроса. Я там читал на Хабре, как они там бряцая талмудами мусолят что есть истинный MVC, а что не истинный. Идёт чёткая установка, что удобства тут в расчёт не принимаются. Гораздо важнее истинный MVC. Тема то популярная, а что полезного можно извлечь в Delphi? Второй вопрос, а встроят ли делегаты в Delphi когда ни будь? Ну могло бы быть интересным тот же MVC покрутить "с девками". А пассивный, то, что-то совсем не понравился. Когда я подписываюсь на событие, я как следствие не дублирую модели пачками на каждое окно и знаю где я должен менять циферки. А так у меня в одном окне я меняю данные - их редактировали, в другом окне перестраиваю, так как могли редактировать, но данные беру уже из другого места. Такая модель ну очень не нравится. Что полезного для Delphi и будут ли делегаты? На сколько вообще я отстал от жизни?
Добавлено:
Совершенно забыл. Тут есть файлик vlb вроде. Он для каждого модуля пустой, но дата его всегда меняется. Чтобы в нём что-то было, в Опциях Delphi в ветке Live Bindings надо Display LiveBindings. Потом увидим внутри vlb ини формат для хранения координат квадратиков (очень похоже на ddp в Delphi7). Это пока для того чтобы не писать строчку присвоить а иметь её в графическом виде. Интересно, что это позволяет натравить генерик на источник данных. Вот бы это увязать как-то с MVC. |
Мы вообще так далеко не плаваем. Из моего кода видно, что ProccessMessages вообще изолирован со всей кучей обработок. 
