Почему TDataSource был создан изначально? - PullRequest
Новая
       5

Почему TDataSource был создан изначально?

11 голосов
/ 23 октября 2009

Какова была (или будет) причина создания TDataSource в качестве посредника между компонентами, связанными с данными, и фактическими базовыми TDataSets, вместо того, чтобы компоненты просто подключались непосредственно к самим TDataSets?

Это может показаться глупым вопросом, но я работаю над широким набором компонентов "средства просмотра данных", которые ссылаются на общий компонент "соединитель данных" и т. Д .; и при проектировании этого набора компонентов я обращаюсь к руководству со структурой классической Delphi «TDataSet -> TDataSource -> Data-bound-component». В моем наборе компонентов, однако, я по-прежнему хочу по существу объединить функциональность эквивалентов «TDataSource» и «TDataSet» в один класс. Это заставило меня задуматься о том, что за причины стояли за их разделением.

Ответы [ 5 ]

12 голосов
/ 23 октября 2009

Это все о развязке и косвенности .

А с TDataSource их есть два вида:

  • Отключение связей основных деталей (TDataSource находится в том же модуле, что и связываемые TDataSets; подробный TDataSet ссылается на главный TDataSet, указывая его свойство ' MasterSource на TDataSource, который указывает на главный TDataSet)
  • Отделение пользовательского интерфейса от бизнес-уровня (TDataSets находятся в DataModule; TDataSource находится в форме / фрейме, который содержит ваши элементы управления UI, элементы управления пользовательского интерфейса ссылаются на их свойство DataSource ).

Поскольку многие компоненты могут указывать на один и тот же источник данных, вы можете быстро переключаться между используемыми TDataSet, которые они используют, просто переключая одно свойство TDataSource.DataSet.

11 голосов
/ 23 октября 2009

Я думаю, что элементы управления, осведомленные о данных, могут быть присоединены к различным наборам данных, просто изменив набор данных, на который указывают связанные с ними источники данных, вместо того, чтобы изменять набор данных каждого элемента управления.

Таким образом, вы можете изменить используемую базу данных, просто изменив один источник данных вместо загрузки TDBEdits, TDBGrids и т. Д.

5 голосов
/ 23 октября 2009
  • TDataSet - это доступ к базе данных.
  • TDataSource о пользовательских интерфейсах: отключение / включение, синхронизация, поток данных и т. Д.

Если вы объедините эти два, ваш компонент базы данных получит зависимость от конкретной инфраструктуры пользовательского интерфейса, которую вы используете. Эти виды зависимостей могут быть хорошими в вашей собственной программе, но не в API, которые распространяются среди многих разработчиков.

3 голосов
/ 23 октября 2009

Вы можете думать об этом как о каком-то шаблоне Model-View-Controller.

Данные находятся в наборе данных (модели), который ничего не знает о том, кто их использует и для чего.
Компоненты, осведомленные о БД, предоставляют пользователю различные интерфейсы (представления) для взаимодействия с этими данными, не зная, кто их хранит.
Источник данных - это промежуточный элемент (контроллер), который обеспечивает связь и отправляет любое изменение данных или команду либо модели, либо представлениям.

Это позволяет легко связывать другой набор данных, не касаясь видов, не изменяя и не добавляя новые виды, не заботясь о них.

1 голос
/ 23 октября 2009

Я не знаю, думал ли именно об этом команда разработчиков, но один из способов, которым это могло бы помочь, - это изменение наборов данных. Допустим, у вас есть целая куча элементов управления, учитывающих данные, и все они связаны с одним набором данных, а затем вы хотите переключиться на другой. Если все они связаны через посредника, все, что вам нужно сделать, это изменить свойство источника данных .Dataset вместо того, чтобы перебирать все элементы управления и изменять их свойства.

(Хотя вам, возможно, все же придется изменить несколько имен полей, в зависимости от того, как все настроено, поэтому это может быть не самым лучшим примером.)

...