Навіщо потрібний TDataSource
TDataSource- проміжна ланка, яка забезпечує зв'язок між набором даних та візуальним компонентом для відображення цих даних. Набір даних - це сукупність записів, виділених за певними правилами з однієї або кількох фізичних таблиць бази даних. Набір даних може бути, наприклад, уADOTable,ADOQuery. Наприклад: 1)Кидаєш на формуADOTable. Вказуєш їй до якої бд підключатися та яку таблицю дивитися. Це набір даних. 2) кидаєш на формуDataSource. Він має властивістьDataSet. Вибираєш у ньомуADOTableсвою. 3)Кидаєш на формуDBGrid. У властивостіDataSourceвибираєш зі списку свійDataSource- який кинув за крок 2. Якщо правильноADOTableпідключена - тоDBGridвідобразить табличку.
У книзі В'ячеслава Понамарьова Бази даних у Делфі 7 - дуже добре дуже багато компонентів описані для роботи з бд і багато понять самої бд.
Можу приклад із DataSource кинути, якщо треба.
я взагаліDBGridі йому подібні компоненти не використовую. Роблю SQL-запорос до бд, а потім дані виводжу куди мені треба.
Так ось – При виконанні запиту – отримуємо набір даних. Цей набір даних можна тримати вDataSource, а наприклад,DBGridпідключена до цьогоDataSourceі цейDataSource- підключений доADOQuery. Тоді можна не писати мою перевірку та мій цикл, а отримувати дані вDBGridвідразу.
В цілому, як я розумію,DataSource- це контейнер для набору даних, які можна легко відобразити в компонентах, що вміють підключатися доDataSource.
Але я обходжуся і без нього якось поки що.
Взагалі виводжу на NextSheet- Табличка красива виходить і дуже просто + об'єднання осередків є + вбудовані функції + вставка рядків, колонок + багато чого. А сама DBGrid - мені особисто не до смаку просто)))
Мені, розумієш, треба витончено
Вирішив порушити тему. Нещодавно десь читав, що така структура об'єктів (Query - DataSource - DBAware-контроль) - це реалізація патерну MVC. DBAware-контроль - це View Query - Model DataSource - Controller
Ось як, виявляється.
Востаннє спробую донести:
"TConnection" - "TQuery" - "TDataSource" - "TDB"
"TConnection" - "TQuery" - "TDB"?
Адже можна було б брати дані прямо з TQuery (адже вони саме там знаходяться)?
Тобто.must be associated
Я згоден з топікпастером. Навіщо потрібенTDataSource, якщо всі набори даних є спадкоємцямиTDataSet? Хай биTDataSetі вмів усе це робити.
Припустимо, що відображення даних та редагування – це велике навантаження. І мовляв, вибірці нефік цим напружуватися. А якщо потрібна візуалізація, зв'язуйтесь через ДатаСорсе – нехай він напружується.
Нехай тема закрита, але вставлю своїх п'ять копійок, може кому буде цікаво. У ООП, існують кілька важливих понять: 1 High cohesion - Висока (Сильна) зв'язність (Всередині класу/об'єкта), - визначає внутрішньоелементний взаємозв'язок. 2 Low coupling - Низька зв'язність - визначає міжелементний взаємозв'язок, це поняття є доповненням першого. Так ось один з основних принципів OOP, є Висока зв'язність всередині об'єкта, або іншими словами - висока відповідальність класу/об'єкта. Що воно значить? - те, що клас/об'єкт повинен мати тільки тіметоди, які строго визначають його поведінку, не більше не менше! Навіщо декларовано цей принцип? - Для того, щоб можна було з легкістю використовувати інший принцип ООП - повторне використання коду. На прикладі з Датасетом і датасоурсом: датасет відповідальний суворо за мапування даних сховища (чи сервер чи інший набір даних) та організації роботи з ними як зі списком. Датасоурс відповідальний за створення зв'язку (дата - лінка) доступу до списку, різних клієнтів (споживачів цих даних, будь то aware control або інший датасет) А тепер злийте обидва класи в один, поставте себе на місце розробника компонентів доступу до даних та спробуйте в майбутньому розширювати складну систему компонентів, враховуючи те, що ви по суті створили (шляхом злиття), лише базовий абстрактний клас, у якого відсутня левова частка робочого функціоналу. Докрутіть його до робочого компонента доступу до конкретного сервера (при цьому кількість коду, простір станів і складність зросла в кілька разів), і уявіть, що з'явився якийсь super-puper grid у якого змінився інтерфейс доступу до dataset компоненту. І тепер вам належить нелегке завдання - адаптувати свій датасет, до supergrid-у (реалізуючи новий інтерфейс). Причому, стара реалізація інтерфейсу лінка (Датасоурса) виявилася не затребуваною (залишилася висіти в класі мертвим вантажем) А тепер поверніть все у вихідний стан і ви побачите, як просто адаптувати датасет до дата контролю (або навпаки), використовуючи клас зв'язку Датасоурс)! При зміні інтерфейсу датасета чи дата контролю, досить адаптувати кожен із кінців класу лінка (патерн Адаптер), тобто. Продати необхідний інтерфейс на одному з кінців. Багато людей про це не замислюються, тому що не пишуть компонентів.та класів, їм надали у користування вже грамотно спроектовану підсистему VCL, яку просто модифікувати отримуючи необхідний результат.
Резюме: складність систем зростає, а інтелектуальні ресурси людини залишаються постійними. інтерфейсів), а також повторно використовувати сущ. код компонентів, які не тягають за собою мертвий баласт, що позначається на надійності, розмірі та легкості інтеграції компонентів/класів з іншими підсистемами.
Тепер із приводу MVC: Dataset -> DataSource -> DATAAWARE control - це не МВС, є щось схоже, але не концептуально. У MVC при впливі на модель, за допомогою контролера, на уявленні відображаються результати зміни, причому незалежно від кількості клієнтів, зачеплених на модель. На прикладі з Dataset-> DataSource -> DATAAWARE control, MVC виглядав би так: користувач зробив зміни в моделі(датасеті), при цьому вони автоматично позначилися на представленні в DATAAWARE control, причому не тільки у нього, але й у всіх інших користувачів, які в даний момент працюють з модель. Щось схоже на реактивне програмування
Резюме: складність систем зростає, а інтелектуальні ресурси людини залишаються незмінними.
Тому куди простіше, зрозуміліше, надійніше проектувати систему, поділяючи її на невеликі підсистеми (класси),