дає розробнику практично необмежену свободу в зв'язуванні об'єктів. Це - принципово новий механізм, який, в принципі не є складним. Я думаю, більшість програмістів-класиків Delphi не відчувають труднощів у використанні спочатку досить складних композитних зв'язок типу "Connection-DataSet-DataSource-DBAwareComponents". Ці зв'язки створюються як в run-time, так і в design-time, а ефективне використання спрямованості зв'язків також вимагає деякого досвіду.
Практично також справи йдуть і з LiveBindings. Напрацьовані шаблони і технологічні зв'язки потім в подальшому відкриють новий світ вільних зв'язків. Бажано, звичайно, щоб приклади були абстрактними, а практично значущими. Але спочатку трохи абстрактної теорії.
являє собою механізм скріплення об'єктів / компонентів на основі виразів. Тут немає нічого принципово складного. Як здійснюється логічний зв'язок між додатком і базою даних? На основі запитів SQL. Це є якесь "текстове" вираз, "відпрацювання" якого призводить до вилучення даних з бази і передачі їх в додаток з урахуванням того, що даний текст контролюється в явному вигляді (статичний запит в design-time, параметризрвані запит, динамічно "склеюють" вираз в run-time.
А можна без мови SQL? Можна, все ми колись використовували компонент TTable. Все було жорстко задано, а обробка даних на клієнті представляла собою послідовність викликів процедур. Можна було так працювати? Так. А чому все-таки підхід на основі SQL був визнаний домінуючим? Тому що більш гнучкий і універсальний (і ще багато чого, що формує термін "більш технологічний"). Ніхто тепер не сумує за TTable? Ну хіба що ми робимо явне desktop-додаток з локальним зберіганням в файлі.
додатки, чітко виділяє якусь "модель" і "інтерфейс" вимагає універсалізації зв'язків. Якість архітектури прийнято багато в чому вимірювати її "гнучкістю", і саме ця гнучкість досягається за рахунок гнучких зв'язків. Зв'язки повинні бути як мінімум локалізовані в певному місці проекту, а якщо ми говоримо про компонентної середовищі, то це повинно відбуватися на рівні компонентів.
Природно, роками вироблена звичка мислити жорсткими зв'язками за рахунок прямих компільованих посилань не дозволяє миттєво сприйняти LiveBindings у всій своїй різноманітті як в плані компонентної / класової підтримкою, так і на рівні поєднань доступних значень властивостей. Тому давайте для розуміння вирішимо досить цікаве завдання прототипирования додатки з елементами 3D-моделювання.
в графічному вигляді показана на малюнку нижче.
- Якийсь об'єкт як частина моделі, який має низку властивостей
- Інтерфейс віконного виду
- Елемент інтерфейсу, призначений для впливу на об'єкт (червона стрілка - Change properties)
- Елемент інтерфейсу для комплексної візуалізації об'єкта (зелена стрілка - Visualize)
- Елемент інтерфейсу для візуалізації / зміни властивості об'єкта
Очевидно, що зв'язку, позначені стрілками, мають яскраво виражену спрямованість. Чи є тут місце для LiveBindings? Без сумніву.
- Може бути кілька видів комплексної візуалізації (просторова, в проекції, схематична і т.д.)
- Елементи управління (впливу на властивості об'єкта) можуть змінюватися в залежності від макета інтерфейсу / вимоги замовника
- Модель у вигляді сукупності об'єктів повинна бути легко відділяється від коду інтерфейсу (наприклад, для використання ядра системи в чисто розрахункових цілях)
Реалізація
Тобто знову якийсь тест-драйв для LiveBindings. Чи зможе цей механізм бути ефективно застосований в цих цілях? Як складно це? І, звичайно, хочеться почути ряд практичних рекомендацій.
У деякому плані це був тест-драйв "інтуїтивності" для LiveBindings, тому що я особливим чином не вивчав теоретичну базу, покладаючись на збіг здорового глузду творця і користувача. Особливо мені було цікавим можливість зв'язування об'єктів, що не успадковують TComponent або TControl. Грубо кажучи, грубих нерозумних призначених для користувача незграбних нащадків TObject. Щоб уберегти вас від медитації, дивлячись на властивості та їх можливі варіанти значень, приведу набір практичних порад в контексті виконаного проекту.
Початково у нас є об'єкт MySphere. TMySphere, який не має нічого спільного з компонентом TSphere для 3D-візуалізації сфери. Будемо вважати, що TMySphere потрібен для моделювання / розрахунків і взагалі не в курсі, як хто і коли його візуалізує.
Об'єкт Sphere1. TSphere стандартний кулька 3D. Шкода, що у нього немає властивості LiveBindings, що, однак, не завадило його використовувати для побудови гнучких зв'язків (як і звичайний об'єкт його довелося прикручувати за допомогою BindScope-а).
edX. TEdit - компонент дуального призначення, він і показує, і впливає на властивість об'єкта (рухає об'єкт вправо, змінюючи його координату Position.X).
"Кнопка" грає роль ініціатора зв'язку "по-старому", вона впливає на об'єкт через посилання, тобто безпосередньо. Додана для наочності.
MySphere (модельна) і Sphere1 (візуальна) пов'язані Односпрямована зв'язком, а оскільки ці об'єкти "неправильної генетики", то для з залучення в візуальний світ LiveBindings були використані 2 допоміжних BindScope-а.
edX. TEdit - правильний, для нього ніякого BindScope-а не знадобилося, він у всіх зв'язках фігурує своїм компонентним ім'ям. Зв'язок двунаправленная.
Ряд практичних порад- Зв'язок LiveBindings можна "накликати" візуально в design-time, можна зробити повністю в коді, але тут був застосований комплексний підхід, коли компоненти розміщувалися на формі, частина властивостей "заряжалась" в design-time, а решта припадала доробляти в run-time ( власне, це абсолютно нормальний стиль роботи в Delphi);
- Як тільки у вас з'явилася перша зв'язок, вона тут буде мешкати в автоматично-що додається BindingsList; якщо вам потрібна ще одна (порожня), то натискаємо по BindingsList і робимо New-> BindExpression;
- Два компонента зв'язати легко, як показують численні демо-приклади; вони добре в'яжуться за допомогою правої кнопки миші в design-time і вибору пункту New LiveBindings. ;
- Доопрацювання зв'язків робиться з "інспектора об'єктів";
- Якщо потрібно зв'язати "звичайний" нащадок TObject, то, зрозуміло справа, в design-time з цим проблема; в зв'язку бере участь компонент BindScope, який візуально живе на формі, бере участь у формуванні зв'язків в design-time, а потім допрацьовується вже в run-time;
- Managed-зв'язку (керовані "байндінгі") вимагають явного повідомлення;
- Зв'язки можуть мати тип "від джерела-к-контроль", "від контрола-к-джерела" і "двонаправлені", що, в принципі, є self-explanatory (тим більше, якщо подивитися на картинку вище);
- BindingsList - загальне сховище всіх зв'язків;
- Іноді краще не кликати (тобто кликати) майстер зв'язків з BindingsList-а, а знайти потрібну зв'язок в панелі Structure, а потім її вже модифікувати в "інспекторові об'єктів", так зрозуміліше.
