Зачем нужен DataSource ?

← →
ANB © (2005-06-15 13:58) [0]

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

← →
Anatoly Podgoretsky © (2005-06-15 14:03) [1]

Для связи с источником данных и централизации этой связи в одном месте.

← →
ANB © (2005-06-15 14:04) [2]

А почему напрямую хуже ?

← →
Anatoly Podgoretsky © (2005-06-15 14:11) [3]

Написал же - централизация. Кроме того датасет не должен ничего знать про визуальные приемник, а они соответственно про источники данных, вот для этого и нужен независимый посредник.

← →
MOA © (2005-06-15 14:14) [4]

Если Вы захотите добавить свой особенный DataSet - Вам не нужно реализовывать функциональность DataSource. И наоборот ;).

← →
Anatoly Podgoretsky © (2005-06-15 14:15) [5]

Главное приемники ничего про это знать не будут.

← →
Anatoly Podgoretsky © (2005-06-15 14:18) [6]

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

← →
Юрий Зотов © (2005-06-15 15:02) [7]

http://delphimaster.net/view/5-1116325152/

← →
iZEN © (2005-06-24 23:05) [8]

Кстати, в Java JDBC отказались от промежуточного централизующего звена довольно-таки сразу.
DataSet - это и есть инкапсуляция ДАННЫХ и ДЕЙСТВИЙ, которые с ними можно произвести. И не надо множить сущности почём зря!

← →
Игорь Шевченко © (2005-06-24 23:23) [9]

iZEN © (24.06.05 23:05) [8]

> Кстати, в Java JDBC

А в Фортране на DataSource ни DataSet - там все ленты. И живут же люди...

← →
Юрий Зотов © (2005-06-25 13:50) [10]

> iZEN © (24.06.05 23:05) [8]

> DataSet - это и есть инкапсуляция ДАННЫХ и ДЕЙСТВИЙ, которые
> с ними можно произвести. И не надо множить сущности почём зря!

Среди этих действий есть еще и такие, как визуальное отображение и визуальное редактирование. Следуя Вашей логике, их тоже следует запихнуть в DataSet? Чтобы сущности не множить.

← →
Anatoly Podgoretsky © (2005-06-25 14:18) [11]

Еще древний философ сказал - разделяй и властвуй.

← →
iZEN © (2005-06-25 19:32) [12]

К Юрий Зотов © (25.06.05 13:50) [10].
Не надо совмещать Модель, Вид, Контроллёр.
Визуальное редактирование и визуальное отображение Модели относятся к Контроллёру и Виду.
Модель может быть одна, а котнтроллёров и видов может быть несколько: что на десктопе можно реализовать одними средствами, то на смартфоне реализуется другими, а данные (DataSet и совмещённые курсоры) остаются одними и теми же.

Легко и просто?

Да не совсем и хорошо это только в Smalltalk так делать. В Java пришли к пониманию "склейки" Контроллёра и Вида в одном объекте визуального взаимодействия - Делегате. Хотя его "параметризация" нужными нам объектами look&feel проходит так же гладко как в Smalltalk, тем не менее принцип разделения на Модель+Делегат здесь тоже присутствует и в JBuilder, например, в его визуальной DataAware-библиотеке dbExpress/dbSwing для работы с реляционным БД никаких сложностей с визуальным проектированием связей между источниками данных и визуальным представлением на формах не возникает.

Так что DataSource в Delphi - это костыль, который и на Контроллёра слабо похож, и к Модели (DataSet) никакого отношения не имеет кроме централизованного шлюзования/фильтрации данных. Если есть "фильтр", то зачем нужно было дублировать аналогичную функциональность в визуальных (DataGrid, etc.) и невизуальных (TTable) компонентах?! В общем, вердикт: DataSource почти лишний.

← →
Ученик (2005-06-25 22:06) [13]

>iZEN © (25.06.05 19:32) [12]
>DataSource почти лишний.

А какое будет продолжение ?

← →
iZEN © (2005-06-25 23:05) [14]

К Ученик (25.06.05 22:06) [13].
Переделать VCL. :))

← →
Ученик (2005-06-25 23:18) [15]

>iZEN © (25.06.05 23:05) [14]
Когда начинаете сбор подписей ? :-)

← →
Ученик (2005-06-25 23:43) [16]

>ANB © (15.06.05 13:58)
На форме 20-200 DB-контролов, которые могут быть подключены к DataSet1 и DataSet2, как будет выглядеть переключение между DataSet1 и DataSet2 ?

← →
DiamondShark © (2005-06-25 23:48) [17]

> На форме 20-200 DB-контролов, которые могут быть подключены
> к DataSet1 и DataSet2, как будет выглядеть переключение
> между DataSet1 и DataSet2 ?

Путём рефакторинга приложения до количества контролов на форме 5-10.

← →
Ученик (2005-06-26 00:03) [18]

>DiamondShark © (25.06.05 23:48) [17]
Хорошо, на форме 5-10 контролов, вопрос остается в силе :-)

← →
Anatoly Podgoretsky © (2005-06-26 00:11) [19]

Сейчас он тебя уговорит на один

← →
DiamondShark © (2005-06-26 00:13) [20]

Видимо, оператором присваивания.
Угадал?

← →
Ученик (2005-06-26 00:25) [21]

Ужос, да?

← →
Ученик (2005-06-26 00:39) [23]

> iZEN © (25.06.05 19:32) [12]

> Не надо совмещать Модель, Вид, Контроллёр.

Абсолютно согласен. Но тогда, вероятно, и не следует совмещать Данные - Передача_данных_к_контролу - Отображение_данных?

DataSource позволяет делать одну, может, не очень часто нужную, но полезную вещь - "легким движением руки" переключать ВСЕ контролы формы на другой DataSet (или назначать им DataSet при подъеме формы в зависимости от каких-либро флагов)

Petr V. Abramov © (26.06.05 2:18) [25]
переключать ВСЕ контролы формы на другой DataSet
это как раз понятно, но уж очень редко применимо, чай не умер бы процерку SetDataSet написать ;)
Ученик (26.06.05 0:25) [21]
Для каждого из 5-10 контролов ?
А в чем проблема ?

На самом деле эта то функциональность датасоурса понятна, гораздо более интересен вот какой момент:

Но место для DataSourcе все же есть. Как раз потому, что ты прав - по сути, это именно список DataLink"ов. И поместить его в контрол нельзя, в контроле нужен только один элемент этого списка, а если поместить его в DataSet, то придем ровно к той же ситуации, о которой уже говорилось - все разработчики совершенно разных DataSet"ов будут вынуждены писать какую-то часть кода методом Copy-Paste.

← →
Ученик (2005-06-26 11:38) [27]

>jack128 © (26.06.05 03:23) [26]
У каждого разные критерии важности, если Вы не видите проблемы в назначение каждому контролу каждой формы DataSet-ата, то тут Вам ничем помочь не могу :-) и даже не буду пытаться :-)

это как раз понятно, но уж очень редко применимо, чай не умер бы процерку SetDataSet написать?

Если Вам нравится писать код переключения для каждого DataSet"а - на здоровье!
Лично мне это совершенно неинтересно, ибо работа совсем не умная.
Borland очень правильно поступил, создав компонент, при помощи которого можно "одним махом" переключить все контролы, не задумываясь "а не забыл ли я чего"?
На самом деле все просто: Не нравится - не пользуйтесь.
Существующие контролы не дают такой возможности? Напишите свои.

Вообще, не понятно о чем дискуссия? "Зачем курице перья"?

> Borland очень правильно поступил, создав компонент, при
> помощи которого можно "одним махом" переключить все контролы,
> не задумываясь "а не забыл ли я чего"?
- хм. Забыть можно простую вещь - во втором дейтасете может оказаться другой набор полей. А если запросы практически идентичны, то есть еще 2 пути :
1. Пересоздать и переоткрыть запрос
2. Использовать динамические курсоры, возвращаемые с сервера. Тогда вообще можно набор данных на серверной стороне формировать, используя любую логику.
Имхо. Ни разу не натыкался на необходимость переключать контролы на другой дейтасет. Единственно - отвязать временно, но это уже в дейтасете предусмотренно.

Зачем нужен DataSource ? Найти похожие ветки