Есть такая библиотека DevExpress. Она мне всегда нравилась.
Сделана - хорошо.
(Оговорюсь - мы НЕ используем её в своих разработках, но очень плотно на неё смотрели)
Но! Там есть одна БОЛЬШАЯ проблема.
Всё построено на TAction'ах. Которые ДОЛЖНЫ лежать в ОДНОЙ общей коробке на MainForm.
Ну так уж она устроена.
Всё бы ничего. Пока форм-клиентов - немного. Но как только их (считай прецедентов) становится много - это всё превращается в "ад и ужас".
Потому, что MainForm становится НЕОБХОДИМО знать про ТИПЫ конкретных клиентских форм, а зачастую и про их внутреннее устройство. И начинаются - "макароны" и ОЧЕНЬ сильное связывание.
Я долго думал над этим и в итоге родилась сначала идея, а потом и реализация собственного фреймворка.
Грубо говоря так - MainForm содержит ТОЛЬКО прототипы Action'ов. В этих прототипах определяются визуальные параметры Action'ов, типа Caption, Hint, ImageIndex и т.п.
И есть - клиентские формы, которые работают в контексте MainForm.
На клиентских формах определяются "объекты" - операции. Которые рассказывают фреймворку, что мол эта форма умеет выполнять ту или иную операцию. Вот мол её Execute, а вот Update.
Ну это грубо, но идея именно такова.
Далее когда клиентская форма выходит на сцену (создаётся или получает фокус), то её операции подвязываются к обработчикам существующих Action'ов (ну и на самом деле могут и создавать их). А обработчики "предыдущих форм" - отвязываются.
Таким образом - мы получили "конструктор"-lego. Приложение конструируется из клиентских форм. Про внутреннее устройство которых оно "не знает". И этих форм - может быть - "сколь угодно много" - связность системы от этого не повышается.
Более того примерно эта же практика распространена и на КОНТРОЛЫ из которых состоят клиентские формы. Контролы ТОЖЕ имеют возможность ЗАЯВЛЯТЬ о том, что они ПОДДЕРЖИВАЮТ те или иные операции, которые тоже связываются с Action'ами.
Вот как-то так...
Развитие идеи (нереализованное пока) c с использованием атрибутов описано тут - http://roman.yankovsky.me/?p=896#comment-3024
А про другие аспекты нашего фреймворка я немного писал тут - http://18delphi.blogspot.ru/2013/08/mvc.html
Ну и ещё тут - http://18delphi.blogspot.ru/2013/09/blog-post_16.html
Сделана - хорошо.
(Оговорюсь - мы НЕ используем её в своих разработках, но очень плотно на неё смотрели)
Но! Там есть одна БОЛЬШАЯ проблема.
Всё построено на TAction'ах. Которые ДОЛЖНЫ лежать в ОДНОЙ общей коробке на MainForm.
Ну так уж она устроена.
Всё бы ничего. Пока форм-клиентов - немного. Но как только их (считай прецедентов) становится много - это всё превращается в "ад и ужас".
Потому, что MainForm становится НЕОБХОДИМО знать про ТИПЫ конкретных клиентских форм, а зачастую и про их внутреннее устройство. И начинаются - "макароны" и ОЧЕНЬ сильное связывание.
Я долго думал над этим и в итоге родилась сначала идея, а потом и реализация собственного фреймворка.
Грубо говоря так - MainForm содержит ТОЛЬКО прототипы Action'ов. В этих прототипах определяются визуальные параметры Action'ов, типа Caption, Hint, ImageIndex и т.п.
И есть - клиентские формы, которые работают в контексте MainForm.
На клиентских формах определяются "объекты" - операции. Которые рассказывают фреймворку, что мол эта форма умеет выполнять ту или иную операцию. Вот мол её Execute, а вот Update.
Ну это грубо, но идея именно такова.
Далее когда клиентская форма выходит на сцену (создаётся или получает фокус), то её операции подвязываются к обработчикам существующих Action'ов (ну и на самом деле могут и создавать их). А обработчики "предыдущих форм" - отвязываются.
Таким образом - мы получили "конструктор"-lego. Приложение конструируется из клиентских форм. Про внутреннее устройство которых оно "не знает". И этих форм - может быть - "сколь угодно много" - связность системы от этого не повышается.
Более того примерно эта же практика распространена и на КОНТРОЛЫ из которых состоят клиентские формы. Контролы ТОЖЕ имеют возможность ЗАЯВЛЯТЬ о том, что они ПОДДЕРЖИВАЮТ те или иные операции, которые тоже связываются с Action'ами.
Вот как-то так...
Развитие идеи (нереализованное пока) c с использованием атрибутов описано тут - http://roman.yankovsky.me/?p=896#comment-3024
А про другие аспекты нашего фреймворка я немного писал тут - http://18delphi.blogspot.ru/2013/08/mvc.html
Ну и ещё тут - http://18delphi.blogspot.ru/2013/09/blog-post_16.html
что-то мне это напоминает Merge/Unmerge Menu по идеалогии
ОтветитьУдалитьну "есть немного"...
УдалитьЯ никогда и не претендовал на "первенство идеи" :-)
УдалитьЯ лишь беру чужие идеи и инкорпорирую их к себе :-)
А что нашли сравнение из мира "не велосипедов" - лестно :-)