Компоненты
Компонент — повторно используемый объект, который визуально внедряется (drag-and-drop) в другой объект [1], и работающий в нем без изменений с минимальными настройками. Известны специальные технологии, связанные с этим, такие как OLE, COM.
Как правило, любая визуализация (форма) иерархически состоит целиком и полностью из компонентов. При этом, если в качестве видимой части компонента используются контейнеры, то за его невидимой логикой работы стоит другой объект (наследник от System.Object [2]), отвечающий за бизнес-логику. Соответственно, проблема разделения визуализации и бизнес-логики существует и на уровне компонентов. Каждый отдельный компонент при этом состоит так же из трех частей: визуализации, бизнес-логики и контроллера. Но организация их работы несколько отличается от работы на самой форме. Этот аспект мы и обсудим в данной статье.
Визуализация компонента
правитьКонтейнер — в общем случае, тип данных, который позволяет инкапсулировать в себя объекты разных типов. При этом, говоря о не визуальных контейнерах используют термин коллекция. Здесь же мы будем говорить о визуальных контейнерах [3] . Многие языки программирования предоставляют специальные классы для создания визуальных контейнеров. В С# в качестве такого класса может использоваться UserControl [4]
Так, например, может быть создан контейнер «Банк», который будет содержать поля для названия, адреса, страны, и swift`а банка. И скажем, у нас есть форма «Платеж», на которой нужно отобразить 3 разных банка: банк получателя, банк плательщика и банк посредник. Тогда на форму будет помещены 3 одинаковых контейнера, но под разными именами. Это уже является примером повторного использования визуальных контейнеров.
Мы уже обсуждали (в Разделение визуализации и бизнес-логики) как полностью отделить визуализацию от бизнес-логики на форме, в которую теперь встраиваются контейнеры. Поэтому это встраивание у нас произойдет совершенно независимо от бизнес-логики. Этой частью может заниматься даже другой человек (дизайнер, а не программист), совершенно не зная как должна работать форма, но знает как она должна визуально выглядеть. При этом если разделив визуализацию от бизнес-логики мы как бы позволили „горизонтальное“ повторное использования, то теперь дизайнер форм может комбинировать для создания форм различные предметные блоки данных, осуществляя так сказать „вертикальное“ повторное использование.
Бизнес-логика компонента
правитьОсновное отличие организации класса бизнес-логики на уровне компонент, отличается тем, что он не создает свою визуализацию и свои контроллеры и ничего о них не знает. Класс бизнес-логики компонента агрегируется в бизнес-логику главной бизнес сущности (назовем ее документом, т.к. как правило он является абстракцией какого-либо реально существующего документа). В бизнес-логике документа логика компонентов используется по принципу целое-часть. Но от бизнес-логики части (компонента) уже не зависит как будет выглядеть документ в целом, т.е. компонент не только не умеет себя визуализировать, но и не знает как это делать. Это знает контейнер в который встраивается компонент, т.е. логика на уровне формы или компонент на уровень в иерархии на один выше. При этом это не бизнес-логика, а логика связи нескольких компонентов в один цельный документ. За эту логику логично будет если будет отвечать контроллер, который теперь может осуществлять горизонтальную связь не только между бизнес-логикой и визуализацией, но и вертикальную между документом и компонентами первого уровня вложенности, а в общем случае между уровнями вложенности компонентов.
Контроллер компонента
правитьВыше мы выяснили, что при использовании компонентов, на контроллер бизнес-сущности (назовем его главным контроллером (MainController)) ложится обязанность, создать контроллеры компонент, встраиваемые в эту бизнес-сущность. При этом сам компонент может в свою очередь состоять из других компонентов, и тогда контроллер компонента уровня выше создает контроллеры компонентов уровня ниже. При этом при создании, в конструктор контроллера, передается объект визуализации этого компонента (контейнер) и объект бизнес-логики соответствующего компонента.