Видимо надо начать "с нуля" про 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 - служат "связующим звеном" для того, чтобы "формы ничего НАПРЯМУЮ не знали друг про друга".
Откуда, что, чего.. И зачем это нужно.
Для примера - 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 - служат "связующим звеном" для того, чтобы "формы ничего НАПРЯМУЮ не знали друг про друга".
Комментариев нет:
Отправить комментарий