Състезание за един набор от данни, два източника на данни
Здравейте хора. Интересно е да научите мнението за практическото приложение на One DataSet + Two or more DataSource. Всеки е свикнал с факта, че този пакет от компоненти идва в строга двойка One DataSet= One Datasource.
Кой и с каква цел е използвал връзката към темата?
Виновен, правописна грешка, прочетете DataSource вместо DataSet
-- Влизате, ако. -- С уважение, Слоболински А.Ю.
DataSet е необходим, ако има мрежа или нещо подобно, където данните трябва да се вмъкват автоматично . В противен случай не е необходимо.
-- Влизате, ако. -- С уважение, Слоболински А.Ю.
Здравей, Димитри! Вие писахте на Алексей Дубовски в сряда, 9 юли 2003 г. 11:12:56 +0000 (UTC):
DS> не съм ползвала. И виждам само една причина да използвам: DS> възпроизвеждане на места, където можете да залепите манипулатора. DS> Тук се чудя от много дълго време: какво е DS> източник на данни. В отговор получи замислено мълчание.
Прочетете по-внимателно за TDataLink, мисля, че ще стане по-ясно.
По темата: нещо не е обмислено, защо 2 DataSource. А какво предизвика такъв въпрос, ако не скрет?
"Александър Диушев-Малцев" съобщи следното в новините .
:)) не е тайна. Напълно неочаквано намерих приложение. Между другото, смисълът на разделянето на DataSet и DataSource също беше напълно неочевиден за мен. Особено ако връзката е 1:1 в 99% от случаите. Те биха могли поне да преместят концепцията на Current line и буфера на текущия ред от DataSet към DataSource - и това би било по-полезно.
Добре, избягах дълго. Все пак открих този 1%, който е трудно да се намери веднага . Приложението е:
Трябва да попълните поле, чиято стойност е взета от друга таблица (T1). В същото време при промяна на стойността е необходимопокажете други полета от T1. Но трябва да покажете ВСИЧКИ полета само ако един от атрибутите е активиран (например зависи от друго поле). Като цяло направих DataSet: T1, от него DataSources: dsCode, dsCodeProps е, сега е ясно какво правя - dsCodeProps.Enabled:= MyFlag=True; Струваше ми се доста просто и красиво решение. Използвайте го.
Александър Диушев-Малцев написа за „Конкурс: Един набор от данни + два източника на данни“:
DS>> От много време се чудя какво е DS>> източник на данни. В отговор той получи замислено мълчание.
TDataLink е помощен клас, използван от обекти, запознати с данни, за координиране на действията на TDataSource и TDataSet и за отговор на данни събития.
И какво? Това не добавя необходимост от TDataSource. Само още един междинен клас между TDataSet и DB-aware контроли. Какво пречи на същия DataLink да се залепи директно в DataSet? Нищо. Какво пречи на TDataSource да изпраща прословути събития с данни директно към обекти запознати с данни чрез Dispatch? Отново нищо. Като цяло сега разбирам, че TDataSource наистина е необходим само за събиране на контроли в купчини и извършване на масова работа с тях : активиране/деактивиране, промяна на източника и т.н. Ето все пак . Има една мистерия по-малко в душата на разработчиците на Borland. Благодаря на всички.
SY, Димитрий Сибиряков.
четвъртък, 10 юли 2003 г. 10:03, Димитрий Сибиряков пише на Александър Диушев-Малцев:
DS> От: "Димитрий Сибиряков"
DS> Александър Диушев-Малцев написа за „Конкурс: Един набор от данни + DS> два източника на данни“:
DS>>> Тук се чудя от много дълго време: какво е DS>>> източник на данни. Получено в отговорзамислено мълчание.
DS> TDataLink е помощен клас, използван от обекти за данни за DS> координира действията на TDataSource и TDataSet и за да отговори на DS> събития с данни. _^^^^^^^^^^^_
DS> И какво? Това не добавя към нуждата от TDataSource. Само още един DS> междинен клас между TDataSet и DB-aware контроли. Какво спира DS> към същия DataLink да бъде залепен директно в DataSet? Нищо. Какво спира DS> TDataSource изпраща прословутите събития с данни директно към data-aware DS> обекти чрез Dispatch? Пак нищо.
Като цяло има причина за въпроса - защо отделен DataSource? Ако мислите от гледна точка на писателя на компоненти - и наистина, защо?
А сега нека помислим за програмист, който пише приложение: IMHO едно от удобствата е възможността да има _няколко_ манипулатори на една дата събитие. Както знаете, събитието на VCL компонент може да има само един манипулатор , внедрен във формуляра или модула за данни. Отделен компонент DataSource чрез капсулиране на обработката на събития за DataSet ви позволява да заобиколите това ограничение.
Надявам се това да помогне, Александър Мячин
по принцип е възможно, но тогава, когато променяте набора от данни, ще трябва да промените на всички аварийни компоненти. за това беше въведен слой за компонентите дисплей/редактиране
"Владимир Улченко". /. ? . . новини:beh5nc$2nej$***@ddt.demos.su.
Също така забравих да добавя, че пакетът TSomeDataSet/TSomeField - TSomeDBAwareControl - TDataSource е въплъщение на Borland на прословутата схема Model-View-Controller, макар и малко специфично, разбира се :)
да, по дяволите, 7 години не притесниха никого, всички бяха доволни, а след това изведнъж се появи човек, който не го харесва. Има много различни набори от данни. Има TDataSetTBDEDataSet, TADODataSet (със сигурност), TClientDataSet. Напред. Имам 10 компонента, прикачени към DataSource. Ако искам да сменя източника на данни, т.е. TTable към IBTable, тогава не е необходимо да променям източника на данни за тези 10 компонента - той остава същият, какъвто беше DataSource. След това разгледайте източниците на TDataSet и TDataSource по-подробно, ако се интересувате толкова _защо_ се прави това.
И не забравяйте, че в началото на 90-те Borland беше най-готиният в OOP. Т.е. няма нужда да казвам, че някой идиот е измислил отделен TDataSource през 1994 г.
-- Дмитри Кузменко, www.ibase.ru, 953-13-34
Изпратено чрез сървър [email protected] - http://talk.mail.ru
DS> TDataLink е помощен клас, използван от обекти за данни за DS> координира действията на TDataSource и TDataSet и за да отговори DS> към събития с данни.
DS> И какво? Това не добавя към нуждата от TDataSource. Просто още DS> един междинен клас между TDataSet и DB-aware контроли. Какво DS> възпрепятства същия DataLink да бъде залепен директно в DataSet? Нищо. Какво DS> пречи DS> TDataSource изпраща прословутите събития с данни директно към data-aware DS> обекти чрез Dispatch? Отново нищо. DS> Като цяло сега разбирам, че TDataSource наистина е необходим само DS> за да съберете контроли в купчини и да произведете DS> масова операция: активиране/деактивиране, промяна на източника и др. Тук DS> след всичко. Още една мистерия в психиката на разработчиците на Borland DS> по-малко.
IMHO неразбрано, въпреки че и за това. За да разберете напълно нуждата от такива помощни обекти, трябва да опитате да напишете поне веднъж доста разтегната йерархия от класове, които трябва да работят заедно. Първо, няма абсолютно никакъв смисълобгръщане на TDataSet с функционалността, необходима за работа с визуални контролни елементи . Или, ако не можете без него, тогава го минимизирайте. Защото че, например, в CGI или уеб приложение няма контроли за данни .
Втората точка е сложността на проектирането на връзка между два класа , които комуникират в двете посоки. Е, ако комуникацията беше в една посока, единият клас щеше да контролира другия, няма проблем. Нещата обаче са по-сложни с двупосочния обмен. Първо, не е възможно да се декларира тип:
единица cMyNonVisualClass; . тип
TMyNonVisualClass=class(. ) . procedure DoSomething(const Target:TMyDBAwareClass); end;
единица cMyDBAwareClass; . тип
TMyDBAwareClass=class(. ) . procedure DoSomething(const Target:TMyNonVisualClass); end;
И ще ви трябва, можете да бъдете сигурни. Ще трябва да използвам или напълно абстрактни описания като Target:TPersistent и да организирам проверка на типа с манипулатори вътре в методите, или да намаля класовете в една единица. Третият вариант е да се използва някакъв вид напълно абстрактен механизъм за взаимодействие при събития.
Третата точка е разширяемостта. И ако трябва да използвам dbaware-функционалност с "различна" йерархия на класове, която никога не е чувала за Borland (да се чете - несъвместима и наследена от класове с , с които TDataSet не може да работи)? Цялата вградена dbaware-функционалност в TDataSet отива в канала.
Така че помощни обекти като TDataSource и TDataLink ви позволяват да избегнете тези проблеми.