ToDo. Видимо надо начать "с нуля" про VCM

Видимо надо начать "с нуля" про VCM.

Откуда, что, чего.. И зачем это нужно.

Для примера - DevExpress. С его ХОРОШЕЙ реализацией. И УЖАСНОЙ архитектурой. Где ВСЕ "операции" (TAction) лежат в ОДНОЙ "коробке" на MainForm.

Начинаем с ОТДЕЛЬНОЙ формы. Описываем её ОПЕРАЦИИ. Как они публикуются в тулбары и ""меню".

ПОНИМАЕМ для начала тот факт, что "форма" - это активный объект, который умеет ПУБЛИКОВАТЬ операции.

Затем превращаем эту форму в ГЛАВНУЮ ФОРМУ приложения (MainForm).

Далее вставляем в неё подобную же ОДИНОЧНУЮ форму. Опять же с ОПЕРАЦИЯМИ и КОНТРОЛАМИ.

Дальше иллюстрируем FormDataSource. Потому, что "вспомнили", про "данные", которые инстанцируют форму.

Дальше понимаем, что БЫВАЕТ несколько "активных зон".

Вставляемую форму дробим на "активные зоны". Получаем несколько ViewAreaDataSource.

Далее получаем - FormSetDataSource. Как "поставщика" этих самых ViewAreaDataSource.

Далее "понимаем", что FormSetDataSource и есть - ДАННЫЕ прецедента (UseCase).

Далее понимаем, что "активные зоны" могут закрываться и открываться (это к примеру). И тут получаем собственно FormSet (UseCase) - как контроллера собственно бизнес-логики ПРЕЦЕДЕНТА.

В итоге цепочка такая:

По представлению:

FormSet (UseCase) -> ViewArea ("активная зона").

По данным:

FormSetDataSource (UseCaseDataSource) -> ViewAreaDataSource -> Data.

В отличии от MCV - "колен" как минимум - ПЯТЬ - UseCase -UseCaseDataSource, ViewArea - ViewAreaDataSource, Data - это "активные" объекты осуществляющие "выбор" данных из БД и реализующие "первичную бизнес-логику".

P.S. В схеме MVC - мне всегда казалось, что "колен" не хватает.... Хотя я и знаком с ней только в трактовке Apple.

P.P.S. Собственно "контролы" и их "геометрия" тут остались за сценой. Это ещё как минимум ДВА слоя (собственно описание контролов внутри "формы" ("подслой" - место размещения "активных зон" внутри формы) и FormSetFactory (UseCaseFactory)).

P.P.P.S. Далее - добираемся до того факта, что контролы на форме - тоже умеет быть АКТИВНЫМИ объектами, которые умеют ПУБЛИКОВАТЬ операции. Фокусо-зависимые.

P.P.P.P.S. И видимо надо отдельно описать и АКЦЕНТИРОВАТЬ внимание на тот факт, что ИМЕННО UseCaseDataSource и ViewAreaDataSource - служат "связующим звеном" для того, чтобы "формы ничего НАПРЯМУЮ не знали друг про друга".

ToDo. Начать с нуля SandBox, тесты к нему и мета-модель

Начать с нуля SandBox, тесты к нему и мета-модель.

И расписывать по шагам - как оно вырастает "с нуля".

С одиночным "главным" наследованием. Чтобы ВСЕ примитивы мета-модели (и Class и Category) наследовались от абстрактного примитива Base.

И с выделением "примесей" AttrHolder, PropertyHolder, ReadOnlyPropertyHolder, UsesHolder etc.

А может и БЕЗ них. Обойтись ТОЛЬКО "квадратиками". А атрибуты и операции сделать ТОЖЕ "квадратиками". По аналогии с method и ViewArea.

А "операции" оставить ТОЛЬКО для "сигнатур". А "атрибуты" рисовать "квадратиками" с наследованием (как ViewArea) т.е. стрелка "наследования" указывает целевой тип атрибута, а имя "квадратика" указывает имя атрибута. Ну и понятное дело - на "квадратик" можно "навесить" пользовательские свойства.

В "стрелках" есть БОЛЬШАЯ "сермяжная правда" в отличии от "сигнатур" - "стрелки" - НАПРЯМУЮ указывают на тип, а "сигнатуры" - предполагают парсинг и вариативность типа. Стрелки же - вариантивность типов - ИСКЛЮЧАЮТ.

Кстати и для "методов" можно избавится от "сигнатур". По индукции. Вводя внутри методов стереотипы <<Param>> со стрелкой к типу. Это - УНИФИЦИРУЕТ. Но! Может сказаться на производительности рисования диаграмм. Тут - надо ТЩАТЕЛЬНО подумать.

Практически получится "UML без UML". ОЧЕНЬ маленькое подмножество - "стрелки" и "квадратики". На основе которого можно нарисовать ВСЁ, что рисуется и сейчас.

Отдельно выделить - АКСИОМАТИКУ (совсем базовые примитивы) и производные (которые перед генерацией распадаются на базовые примитивы, путём их конструирования перед генерацией).

АКСИОМАТИКА - зависит от целевого языка генерации, а ПРОИЗВОДНЫЕ - не зависят. Они лишь порождают примитивы из АКСИОМАТИКИ.

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

Таким образом - получаем "компактное" языко-зависимое "ядро" и набор языко-независимых производных стереотипов.

Также надо ОКОНЧАТЕЛЬНО подумать о возможности рисования представления ПРОИЗВОДНЫХ примитивов в виде диаграмм ВНУТРИ данных примитивов. В диаграммах могут использоваться как примитивы из АКСИОМАТИКИ, так и РАНЕЕ определённые ПРОИЗВОДНЫЕ примитивы.

Эти диаграммы достаточно "просто" обрабатывать. Достаточно перебрать все элементы диаграммы и создать такие же (по образу и подобию) уже в конечном экземпляре примитива. Надо лишь учесть возможность подстановки специальных переменных типа SELF, PARENT, PARENT1..PARENTN etc. Это уже надо по месту додумывать. "Сферического коня" - тут ни в коем случае - рождать не нужно.

Также надо подумать о "разрисовывании" вызовов встроенных (и определённых ранее) примитивов DSL ПРЯМО внутри методов генерации. Чтобы в конечном итоге иметь возможность "безболезненно" сменить текстовый DSL. В виде "блок-схем".

Вкратце - может получится, что от мета-мета-модели останутся лишь стереотипы Class, Category и dependency (унаследованные от ЕДИНОГО предка Base). Все остальные - не нужны.

Причём "начать плясать" именно от "контейнерных" примеров в SandBox: Project->Library->SimpleClass. Далее понадобился ExeTarget - вводим его. Понадобился Enum или Pointer - вводим их. etc по индукции. Понадобился TestTarget и TestCase - вводим их. Ну в общем - "в стиле XP". Делаем ТОЛЬКО то, что НУЖНО в данный конкретный момент.

И смотреть на временные срезы этого хозяйства. Как оно растёт.

Там глядишь и до VCM в "новом понимании" можно добраться.

Ну и иметь в виду - http://18delphi.blogspot.com/2013/07/blog-post_24.html

Также надо подумать (в разрезе SandBox) о микро-UseCase'ах и микро-UserNeeds. Чтобы сразу под проектные классы "подкладывать" ТРЕБОВАНИЯ.