Тя дава на разработчиците на практика неограничена свобода в местата на свързване. Това е - един коренно нов механизъм, който не е трудно по принцип. Мисля, че повечето програмисти Delphi класическа никаква трудност да се използва оригиналният доста сложен компонент на ставните връзки, като например "Connection-DataSet-DataSource-DBAwareComponents". Тези връзки са в хода на времето, а в дизайна работно време, както и ефективното използване на насочени облигации също изисква известен опит.

Почти толкова неща и LiveBindings. Изпитани и проверени модели и технологични връзки след това по-късно откриват един нов свят на свободни връзки. Желателно е, разбира се, че примерите не са абстрактни и практически значими. Но най-напред някаква абстрактна теория.

Това е механизъм за свързване на обекти / компоненти въз основа на изрази. Няма нищо фундаментално комплекс. Как е логическа връзка между приложението и базата? Въз основа на SQL заявки. Това е един вид "текст" израз "отработване", което доведе до извличането на данни от базата данни и да ги прехвърлите на заявлението се има предвид факта, че текстът се следи изрично (статично заявка в дизайна работно време, параметризирана заявка, динамично "лепила" изразът в хода на времето.

А възможно без SQL език? Може ли всички ние, след като използва TTable компонент. Всичко се строго определени, както и за обработка на данни на клиенти, е поредица от процедурни повиквания. Може да се работи по този начин? Да. Защо SQL базиран подход е бил признат като доминиращ? Тъй като това е по-гъвкав и гъвкав (и какво ли не, който генерира терминът "по-силен"). И сега никой не пропуска TTable? Е, освен, че ние правим ясна десктоп-приложение с локално хранилище във файла.

приложения, като ясно разграничава някои "модел" и "интерфейс" изисква универсализация връзки. Качеството на архитектурата прави до голяма степен се измери нейната "гъвкавост", и това е тази гъвкавост се постига чрез гъвкави връзки. Диалогът трябва най-малко да се локализира в определена област на проекта, и ако ние говорим за компонент околната среда, то това трябва да се направи в компонент ниво.

Разбира се, през годините, за да се развиват навика да мисли твърди връзки чрез пряко събрани връзките не позволява мигновено възприемат LiveBindings в цялото му разнообразие, както по отношение на подкрепа компонент / клас, както и на равнището на наличните комбинации от стойността на имотите. Така че нека да се реши за разбирането на един много интересен проблем за създаване на прототипи приложения с елементи на 3D-моделирането.

графично показано по-долу.

• Като част от модел на обект, който има редица свойства
  
• Прозорецът на интерфейс на формата
  
• интерфейс елемент проектирана да действа от обекта (червена стрелка - Промяна на свойства)
  
• интерфейс елемент, интегриран визуализация обект (зелена стрелка - Визуализиране)
  
• Интерфейс за изобразяване елемент / промени свойство на обект
  

Очевидно е, че съобщението е показано със стрелките, има силен акцент. Има ли място за LiveBindings? Безспорно.

• Може да има няколко типа комплекс изображения (пространство в издатината, схематичен и т.н.)
  
• Контроли (ефекти върху свойствата на обекта), могат да варират в зависимост от изискванията за оформление интерфейс / клиента
  
• Модел като сбор от предмети трябва да бъде лесно разглобяема от кода на интерфейс (например, за използване в чисто изчислителни цели на ядрото)
  

изпълнение

има отново тест драйв за LiveBindings. Ще се прилага този механизъм ефективно за тази цел? Колко трудно е това? И, разбира се, искаме да чуем редица практически препоръки.

В някои отношения това е тест драйв "интуитивно" за LiveBindings, защото Аз не съм особено учи теоретичната основа, позовавайки се на случайно разбирам създател и потребител. Особено интересно за мен е възможността за свързване на обекти владее TComponent или TControl. Грубо казано, груби тромавите глупави потребителски потомци на TObject. За да ви пази от медитация, гледайки свойства и опции ценности, донесе поредица от практически съвети в рамките на проекта.

Първоначално имаме MySphere обект. TMySphere, която няма нищо общо с TSphere компонент за сфера 3D-визуализация. Ние приемаме, че TMySphere необходимо за моделиране / изчисления и не знам как някой, и когато той визуализира.

Обект Sphere1. TSphere стандартна крушка 3D. Жалко е, че той не притежава свойства LiveBindings, които обаче не успяха да предотвратят използването му за изграждане на гъвкави връзки (като обикновен обект трябваше да се завинтва в използването BindScope-а).

EDX. TEdit - компонент на двойна цел, и това се вижда, и засяга имуществото на обекта (движи се противопостави на правото, да променя своята координира Position.X).

"Бутон" играе ролята на инициатор на комуникацията "старомоден", то се прилага към обекта чрез връзка, т.е. директно. Добавен на яснота.

MySphere (модел) и Sphere1 (визуално), свързани еднопосочен съединител, и тъй като тези обекти "грешни генетика", за участието на дъщерното дружество BindScope-2 и са били използвани при визуалните световните LiveBindings.

EDX. TEdit - Добре, защото не е BindScope-и не я вземе всички връзки, представени му компонент име. Двупосочна комуникация.

Редица практически съвети

• връзка LiveBindings може да бъде "самоизпълняващо" визуално в дизайна работно време, може да се направи изцяло в код, но е бил приложен интегриран подход, при който компонентите се поставят върху формата на свойствата на "зарежда" в дизайна време, а останалите трябваше да продължи в навечерието време ( в действителност, това е напълно нормално начин на работа в Делфи);
  
• След като сте първата връзка, тя веднага се заселят в автоматично добавя BindingsList; ако имате нужда от друг (празен), след това кликнете върху BindingsList и направи новообза-> BindExpression;
  
• Двата компонента се свързват лесно, както е показано от многобройни примери композиция; те да съответстват добре с десния бутон на мишката в дизайна време и изберете новата LiveBindings точки. ;
  
• По-нататъшни връзки за развитие, направени от "инспектор обект";
  
• Ако искате да се сдружават в "нормална" потомък на TObject, а след това, разбира се, в дизайна време с този проблем; във връзка част BindScope компонент, който визуално живее на формата, участва във формирането на отношенията в областта на дизайна време, а след това вече е финализиран от време на изпълнение;
  
• Сайтът се поддържа-връзка (управлявани "bayndingi") изискват изрично уведомяване;
  
• Връзките могат да бъдат от типа "на контрола източник до", "от извора контрол до" и "двупосочен", която по принцип е от само себе си (особено при разглеждане на снимката по-горе);
  
• BindingsList - обща хранилище за всички контакти;
  
• Понякога е по-добре да не кликват (това обаждане) майсторски връзки от BindingsList-а, и да намерят връзката в прозореца на структура, а след това вече е променена в "обект инспектор", толкова ясно.