Ваше мнение на мой подход.

← →
karat © (2004-11-11 09:48) [0]

ВСе чаще приходится создавать приложения для БД. И выработал для себя такой подход. Хотел бы узнать ваше мнение, насколько это вообще правильно.
Для работы с БД я всегда создаю класс. Его методы выполняют обыкновенные стандартные операции типа добавить запись, удалить запись и т.д. (к примеру, TOperation.GetClientCard). Как правило, в конструктор я передаю наборы данных (ADOCommand, ADOQuery), где инициализируются внутренние переменные того же типа. И методы работают уже с ними. Так же есть поля класса, содержащие свойства, специфичные для БД (к примеру ServerName).
Выаше мнение на такой подход?

← →
Nikolay M. © (2004-11-11 10:08) [1]

Видал такой кошмар в одном месте. Не исключаю, что если грамотно построить иерархию классов, оно будет работать красиво и быстро. Но мне пришлось некоторое время провести на поддержке такой программы, где список клиентов выводился не связкой ADODataSet-DataSource-DBGrid, а начитывался в ListView, причем для построения каждой записи делалось несколько запросов к базе! Имхо, автора этого ужаса замучала икота от мата в его адрес...

← →
КаПиБаРа © (2004-11-11 10:23) [2]

karat © (11.11.04 9:48)
И выработал для себя такой подход

Между какими подходами вы выбирали и в чем преимущества именно этого подхода?

← →
Dmitriy O. © (2004-11-11 10:34) [3]

Это извращение

← →
karat © (2004-11-11 10:40) [4]

> Между какими подходами вы выбирали

К примеру, можно просто на обработку каждой кнопки или другого нужного события, вставлять код исполнения SQL запроса, а не метод класса. Или уйти от классов и создать отдельный модуль с процедурами и функциями.

> в чем преимущества именно этого подхода

- С преимуществом столкнулся при разработке MDI приложений. Где есть несколько основных дочерних окон, в которых отображается наиболее важная часть информации для пользователя и допускается возможность открывания сразу нескольких одинаковых окон. Тогда класс, при создании дочернего окна, "привязывается" к нему и работает именно с данными этого окна. При подходе с отдельным модулем функций и процедур (без класса), считаю сложнее осуществивым.
- Читабельность кода модуля форм. В этой ситуации, класс является неким "черным ящиком", от которого интересует только информация на выходе. А что творится внутри него, уже мало интересует (при этом важен проффесиализм программиста). Это как про то, что мы используем функции и процедуры OP, но редко кто(наверное большинство) заклядывает внутрь их.

← →
karat © (2004-11-11 10:42) [5]

> Dmitriy O. © (11.11.04 10:34) [3]
> Это извращение

Что тогда не извращение?

← →
КаПиБаРа © (2004-11-11 11:36) [6]

karat © (11.11.04 10:40) [4]
К примеру, можно просто на обработку каждой кнопки или другого нужного события
Можно все писать в DataModul.

> Тогда класс, при создании дочернего окна,
> "привязывается" к нему и работает именно с данными
> этого окна

Почему бы самому дочерниму окну не работать с данными минуя промежуточные классы? Причем можно создавать несколько дочерних привязаных к одному и тому же набору.

← →
Игорь Шевченко © (2004-11-11 11:53) [7]

> Почему бы самому дочерниму окну не работать с данными минуя
> промежуточные классы?

В примитивных приложениях так и делается (и это именно то, что рекомендует Borland).

← →
by © (2004-11-11 11:56) [8]

Игорь Шевченко © (11.11.04 11:53)
А что рекомендует Borland для не примитивных приложений?

← →
inic © (2004-11-11 12:01) [9]

karat © (11.11.04 9:48)

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

← →
blackman © (2004-11-11 12:02) [10]

>В примитивных приложениях так и делается (и это именно то, что рекомендует Borland).
Это рекомендует Шевченко противный и примитивный Borland :)

← →
Rule © (2004-11-11 12:07) [11]

ну момоему все зависит от задач, если написать быстренько маленьку программку по учету чегото то думаю нецелесообразно пихать новые классы туда где они будут все равно использоваться единажды, а если есть много окон или приложений которые повторяют опроделенную бизнесс-логику, тот тут место трехзвенкам ...
ИМХО

← →
Игорь Шевченко © (2004-11-11 12:08) [12]

blackman © (11.11.04 12:02) [10]

Ты когда-нибудь уймешься ?

← →
msguns © (2004-11-11 12:13) [13]

Есть такой метод (на примере такого же MDI-решения):
1. Создается Датамодуль, в который вшивается то, что глобально для приложения: записи, типы, коннекты, транзакции (для ИБ), методы, применяемые большинством объектов (например, обработчики событий датасетов) и т.д.
2. Создается по одной базовой форме на каждый тип интерфейсного окна (окно справочников, окно документов, окно редактирования записей и т.д.), где максимально прописывается реализация (обработчики акций, поп-ап меню, связка с коннектом, транзакциями и т.д.)
3. Из базовых форм достаточно быстро мастерятся интерфейсные (пользовательские) формы, которые "наточены" на конкретные объекты БД или предмета (таблицы, отчеты). Большинство функций уже определены (отображение текущего состояния датасета, обработчики вставки-удаления-изменения, перечитка с позиционированием, всевозможные поиски-фильтры-сортировки и т.д.) в форме-папаньке, остается только "заточить".
4. Формы в ране создаются динамически и после закрытия уничтожаются. Наряду с минусами (многажды открытая одна и та же форма, что приводит к лишним транзакциям или загрузке кэша одной, потеря узером "фокуса" и т.д.) есть и плюсы (можно одну и ту же таблицу отсортировать неск.способами и сравнить результаты в неск.окнах)
5. Никаких коррекций в гридах ! Только через формочки, не связанные напрямую с данными. Все модификации через автономные запросы (TIBSQL). Все, что должно заключаться в одну логически целостную операцию (например, проводка документа), через ХП в отдельной транзакции.

Уф, увлекся ;)))

← →
Игорь Шевченко © (2004-11-11 12:18) [14]

msguns © (11.11.04 12:13) [13]

Как все до боли знакомо :) Я уже давно иду в сторону от подобного подхода, вынося функциональность бизнес-логики в отдельные классы или, в ряде случаев, в те же DataModule, так, чтобы форма преимущественно не знала об конкретном источнике данных для отображения.

← →
КаПиБаРа © (2004-11-11 12:22) [15]

Я с классами заморачивался когда мне нужно было отображать в различном виде некоторые сущности, информация о которых расположена в БД.

← →
msguns © (2004-11-11 12:28) [16]

>Игорь Шевченко © (11.11.04 12:18) [14]

.. и напрашивающийся шаг: вынести классы в саму базу и написать средство их юзанья и апдэйта извне..
И получим образчик Объектной модели БД. Но это уже совсем другая песнь.

← →
Rem © (2004-11-11 13:33) [17]

У меня сделано так:
1. Есть службы бизнеса (хотя, они интегрируют в себе частично службы данных) - компоненты для работы с конкретными сущностями БД. Они реализуют методы для открытия списков, редактирования элементов. Эти методы вызывают обработчики, привязанные к соответствующим событиям (OnExecuteList, OnOpenDocument, OnEditDocument, OnDeleteDocument, OnRestoreDocument). В этих обработчиках пользователь может подключать свои (внешние для набора компонентов) формы (например, форму для отображения списка клиентов или форму редактирования данных о клиенте) или выполнять любые другие действия. Кроме этого, служба бизнеса содержит закешированный список - грубо говоря, открытую таблицу БД (хотя, это чаще всего именно запрос к нескольким таблицам БД) - то-есть то, что пользователь должен видеть в списке (например, Фамилию, Имя, Отчество, Адрес клиента (из таблицы "Клиенты"), Электронную подпись автора записи (из таблицы "Пользователи") и пр). Для чего это нужно: Вновь открываемые представления списка (а они могут отличаться за счет установки фильтров) не должны делать запроса к БД, так как данные уже на клиентской машине, и их нужно только клонировать. Для того, чтобы обеспечить актуальность кешированных данных, центральная служба данных (она общая для всех бизнес-служб) занимается синхронизацией данных. В результате траффик практически на нуле, так как пользователи загружают список при запуске приложения, а после этого происходит только синхронизация единичных записей.

2. Есть набор компонентов для работы со списками - от простого клона в памяти - до табличного представления. Они подключаются к службам бизнеса. Эти списки открываются не путем запроса из БД, а путем простого клонировани НД. В результате - экономия памяти и синхронизация данных. То-есть, поьзователь может открыть множество списков (журналов), например, приходных накладных за разные диапазоны дат (с любым пересечением), а набор данных у этих списков будет один и тот же. Причем, в случае изменения записей одним ихз пользователей в сети, эти данные автоматически ихзменяются во всех списках у всех пользователей. Траффик в момент синхронизации - на уровне 0.1 - 0.2% от общей пропускной способности сети (локальная сеть 100 мбит, 8 одновременно работающих пользователей) по данным Диспетчера задач Windows XP.

3. Есть набор компонентов (расширения DataSet"а) с методами управления документами (создать новый, открыть, записать), которые подключаются к службам бизнеса. Службы бизнеса запрашивают данные напрямую из БД и передают их в DataSet"ы. При записи службы бизнеса контролируют корректность записываемых даных и пишут напрямую в БД. После этого инициируют синхронизацию данных в кеше списков (для всех пользователей, подключенных к БД).

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

Уффффффф....
:)

← →
Rule © (2004-11-11 14:07) [18]

ух ну вы тут навкладывали :)

← →
Гавирла (2004-11-11 14:12) [19]

> [1] Nikolay M. ©

тоак проблема наверно не в том, что через классы в LIstView
а в том, что несколько запросов на одну запись ?

← →
blackman © (2004-11-11 14:22) [20]

>Игорь Шевченко © (11.11.04 12:08) [12]
Ничего уж и сказать нельзя :)
Учебник: Создание приложений для работы с базами данных
http://articles.org.ru/lection/sozdbd.php
Не надо мудрствовать :)

← →
DiamondShark © (2004-11-11 14:27) [21]

> blackman © (11.11.04 14:22) [20]

То, что там описано, и есть примитивное приложение.

← →
Суслик © (2004-11-11 14:30) [22]

Советую почитать книгу
Мартин Фаулер
Архитектура корпоративных программных приложений.
Она есть на www.books.ru

Книга хорошая, с точки зрения обзора. С точки зрения глубины у книги есть недостатки. Особенно это выражается в том, что НЕлюбимые автором методы он описывает не очень любя, давая не очень внятные примеры и поясления.

Там и такой подход есть. Это либо паттерн аctive row, row data gateway, table data gateway, table module (точно понять по приведенной инфе невозможно).

← →
Rule © (2004-11-11 14:36) [23]

blackman © (11.11.04 14:22) [20]

БРРРРРРРРРРРРРРРРРРР, это БДЕ, вы что ... не нада даже напоминать о нем.
С тех пор как с него ушел, я стал намного счастливее :)

← →
by © (2004-11-11 14:40) [24]

Суслик © (11.11.04 14:30)
Читал я Фаулера. Он много расписывает подход для модели предметной области, все через классы, когда представление (форма) ничего не должна знать о том где класс берет данные, все в коллекциях. И очень мало он пишет о подходе для модуля таблицы, когда все основано на датасет. При это говорит, что для С# модуль таблицы может подходить больше, но равноценного с моделью предметной области примера и применения не приводит.
Много говорится что модель предметной области лучше, гибче, но чем конкретно она лучше не понятно. Особенно не понятно это для языков, которые имеют родные средства работы с модулем таблицы, для Delphi, для C#.
Может кто объяснит, в чем превосходство?

← →
DiamondShark © (2004-11-11 14:41) [25]

Это верно. БзДЕ должно сдохнуть.
Обидно только, что другие технологии доступа, реализованные в Дельфи фактически копируют ублюдочную идеологию бзде.

← →
Суслик © (2004-11-11 14:43) [26]

> [24] by © (11.11.04 14:40)

> Много говорится что модель предметной области лучше

> Может кто объяснит, в чем превосходство?

Не знаю :))) Вернее мнение есть, но это не для форума - долго очень.

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

← →
by © (2004-11-11 14:49) [27]

[26] Суслик © (11.11.04 14:43)
Жаль что мнение не для форума, очень хотелось услышать.
Я начинал в свое время, в первом проекте, как теперь понимаю с модели предметной области. Очень много текста приходилось писать.
Потом перешел на модель таблицы данных, с DBAware компонентами.
Теперь иду по пути отделения логики от предаставления, но без коллекций, а используя как основу класса датасет, и не отказываясь от гридов.

Вот здесь есть open-source проект, который использует только модель предметной области, все согластно паттернам проектирования. Как серьёзный пример, очень показательно.
TechInsite Object Persistence Framework
http://www.techinsite.com.au/tiOPF/ReleaseBuild

Вот бы такое увидеть и для модели таблицы.

← →
Игорь Шевченко © (2004-11-11 14:49) [28]

DiamondShark © (11.11.04 14:41) [25]

А эта...если не секрет, в чем беда идеологии BDE ?

← →
Суслик © (2004-11-11 14:51) [29]

> [27] by © (11.11.04 14:49)

> Очень много текста приходилось писать.

Я не вижу в этом проблемы. Код, если он написан хорошо и един (а не разнесен по разным местам: pas и dfm) поддерживатся точно также как меньший код, но разнесенный.

← →
by © (2004-11-11 14:57) [30]

[29] Суслик © (11.11.04 14:51)
Насчет того что легче поддерживать код в pas это да. Я и начичинаю потому отделять форму от логики, так как запарился в дизайн тайме искать где изменилась длина поля и пр.

← →
Игорь Шевченко © (2004-11-11 14:58) [31]

by © (11.11.04 14:49) [27]

Tiopf-то ? Любопытно, но уж больно громоздко, на мой взгляд.

← →
panov © (2004-11-11 14:59) [32]

Присоединяюсь к вопросу от Игорь Шевченко © (11.11.04 14:49) [28].

← →
Суслик © (2004-11-11 15:00) [33]

> Насчет того что легче поддерживать код в pas это да. Я и
> начичинаю потому отделять форму от логики, так как запарился
> в дизайн тайме искать где изменилась длина поля и пр.

Скажу больше, что я давно (еще года 3 назад) запарился вообще компоненты кидать. Кидаешь быстро, медленно правишь (все бывает, иногда и это нужно). Код + заточенная на мои проблемы оболочка (в основном, в виде внешних методов) над vcl мне нравятся больше.

Конечно, это все мое личное мнение.

← →
by © (2004-11-11 15:02) [34]

Игорь Шевченко © (11.11.04 14:58)
Да вот и меня масштаб этого framework слегка озадачил. Да и не готов я отказаться от грида как представления набора данных. Может еще и по потому что мне приходится писать приложения, которые оперируют буольшими наборами данных (биллинг), и загонять это в коллекции как то не хочется. Хотя может я и не прав. Уже пол года на распутье, как писать следующий проект.

← →
Суслик © (2004-11-11 15:06) [35]

> [34] by © (11.11.04 15:02)

Биллинг?
Это особая статья. Это систему вряд ли можно отнести к тем системам, про которые говорит Фаулер.

Думаю, что для биллинга такой подход вряд ли подойдет.

← →
Игорь Шевченко © (2004-11-11 15:15) [36]

by © (11.11.04 15:02) [34]

> Да и не готов я отказаться от грида как представления набора
> данных

Так вот и я не готов. Ни от грида, ни от прочих Data-aware controls, так как во-первых, удобно, во-вторых - уже написано, отлажено и, главное, протестировано многими пользователями.
Я вот до сих пор не могу себе ясно представить, как можно opf совместить с привычной идеологией разработки приложений в Delphi, так, чтобы при этом еще и не писать код в объеме, подобном tiopf.

← →
msguns © (2004-11-11 15:21) [37]

>DiamondShark © (11.11.04 14:41) [25]
>Обидно только, что другие технологии доступа, реализованные в Дельфи фактически копируют ублюдочную идеологию бзде.

Нельзя ли для особо бестолковых прокомментировать:
1. Какие технологии копируют ?
2. Что именно копируют ?
3. В чем "ублюдочность" биде ?

← →
DiamondShark © (2004-11-11 15:24) [38]

> Игорь Шевченко © (11.11.04 14:49) [28]
> DiamondShark © (11.11.04 14:41) [25]
>
> А эта...если не секрет, в чем беда идеологии BDE ?

А в ней от десктопных и файл-серверных БД рудиментов много.

Впрочем, я попутал. Не в самой БзДЕ, конечно, а в БД-компонентах.

← →
vuk © (2004-11-11 15:26) [39]

to DiamondShark © (11.11.04 15:24) [38]:
>Не в самой БзДЕ, конечно, а в БД-компонентах.
О как! А в компонентах-то где?

← →
Rule © (2004-11-11 15:30) [40]

Если бы существовало однозначное решени для всех авриантов, оно бы уже было бы реализовано, а так имеет то что имеем :)

← →
DiamondShark © (2004-11-11 15:33) [41]

> 1. Какие технологии копируют ?
> 2. Что именно копируют ?
> 3. В чем "ублюдочность" биде ?

1. Все наследники TDataSet
2. Имитацию десктопности
3. см. выше.

> О как! А в компонентах-то где?

А везде.

← →
vuk © (2004-11-11 15:40) [42]

to DiamondShark © (11.11.04 15:33) [41]:
>А везде.
Конкретные места, пожалуйста.

← →
by © (2004-11-11 15:40) [43]

[35] Суслик © (11.11.04 15:06)
Вот в том и беда, что громадные объемы соседствуют со сложной логикой (тарифные планы и пр.)

Видать пойду по пути который начал разрабатывать сейчас. Схематически это выглядит так.
Есть базовый класс DBClass (в DataModule), он содержит методы работы с датасетом (выборка, редактирование строки и пр., мапинг полей датасета на поля класса). Есть его наследники, которые представляют класс для работы с конкретной сущность, которая представлена в БД.
Есть формы для отображения данных и редактирования, не привязанные к конкретному классу, все гриды и эдиты наполняются динамически (для особо сложных по дизайну рисуются не динамически)
Есть Головная форма, своеобразный диспетчер, она вызывает формы представления и передает им как параметр наследника DBClass.

Это пока схематически, разработка покажет.

← →
Суслик © (2004-11-11 15:43) [44]

> [43] by © (11.11.04 15:40)

Т.е. это у тебя table module + шлюз?

Нормальное решение имхо.

У нас, сложная логика, но и объемы маленькие. Да и к скорости спрос не высок. Поэтому хватает.

← →
blackman © (2004-11-11 15:43) [45]

>DiamondShark © (11.11.04 14:27) [21]
>То, что там описано, и есть примитивное приложение
И не надо мудрить! Усложняя вы приносите юзеру массу проблем в дальнейшей эксплуатации проекта.
Вы не вечны :) и дальнейшая модернизация проекта вероятно будет необходима. Пожалейте тех, кто будет ... после вас :)

← →
msguns © (2004-11-11 15:44) [46]

>DiamondShark © (11.11.04 15:33) [41]
>> 1. Какие технологии копируют ?
>1. Все наследники TDataSet

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

← →
Суслик © (2004-11-11 15:45) [47]

Очередной холи вор.
Да... давно не было.

Заметтье я к началу вор отношения не имел :)

← →
msguns © (2004-11-11 15:46) [48]

И еще вдогонку:
Поясните, будьте любезны, что именно "десктопного" Вы находите в свойствах, методах и событиях TDataSet ?

blackman © (11.11.04 15:43) [45]

Боюсь, что это ваш подход приносит юзеру проблемы в дальнейшей эксплуатации и особенно в модернизации. Впрочем, нравится вам имитировать урезанный Access - бога ради.

[44] Суслик © (11.11.04 15:43)
Ага, если мапить это на книжку, то так. )))

Вот так начитаешься всяких GoF, Fowler и прочих, и думаешь - все что ты делаешь уже описано, что ж раньше не читал, изобретал велосипед.
Но, с другой стороны, я где-то читал что научить правильному проектированию приложений не возможно (или очень сложно), нужно все таки эти шишки набить самостоятельно.

2 Суслик
А ты нигде не встречал подобное Фаулеру, но для модуля таблицы, да еще и для Delphi )). Чтобы описывалось что-то нормальной сложности, а не связка Dataset - datasource - Grid - dbnavigator

> [50] by © (11.11.04 15:59)

> А ты нигде не встречал подобное Фаулеру, но для модуля таблицы,
> да еще и для Delphi )). Чтобы описывалось что-то нормальной
> сложности, а не связка Dataset - datasource - Grid - dbnavigator

Не поверишь, но я никогда полноценно в этой технологии не работал.
Совсем саму малось, и то для себя.

> msguns © (11.11.04 15:44) [46]
> А как могут наследники НЕ копировать предка ?

Никак. Об том и разговор.
Я и не пользуюсь ими. Неприятность в том, что много компонентов (контролы, гриды, репорты разные) завязаны на них.

ADODataSet... DataSource ... DBGrid
Прямо совещание батонокидателей :))

2 karat © (11.11.04 09:48)
Все нормально. Настоящие мачо так и делают.

to DiamondShark:
Я правильно понял, что конкретных мест, где в DataSet имитация десктопности так и не будет? Просто я что-то эти места не особо вижу.

Все что нашел Фаулера.
1)Новые методологии программирования
http://www.maxkir.com/sd/newmethRUS.htm
2)Проетирования больше нет?
http://www.maxkir.com/sd/designDead_RUS.html
3)Чтобы было яснее (пользе простого и понятного кода)
http://www.maxkir.com/sd/explicit_RUS.html

А вообще полезное вот здесь http://www.maxkir.com/sd.html

>DiamondShark © (11.11.04 16:06) [52]
И все ж таки я не врубился, в чем "ублюдочность" ? В том, что парни разработали свой (пусть не идеальный) подход к программированию доступа к базам и написали кучу компонент, ориентированных на этот подход ? Вам не нравится подход ? Да бога ради ! Пишите свой вместе с упомянутыми Вами гридами, эдитами и прочим "довеском". Или покупайте (заимствуйте) из других библиотек.
А то как-то нехорошо получается. Вам достался продовольственный пакет с вареной колбасой, крупой, пельменями и баночкой грибов. На шарика. Вы слопали грибы, а остальное с руганью и презрением выбросили в мусорный бак.
Так что ли ?

> msguns © (11.11.04 17:06) [59]
> И все ж таки я не врубился, в чем "ублюдочность" ?

С третьего раза и не врубился? Ну ладно, как особо тупому объясню ещё раз. На этот раз примером из жизни.

Зовут меня разобраться в странном поведении приложения -- приложение впадает в странные дедлоки, причём весьма нерегулярно, а так, от случая к случаю. Место блокировки утановлено, но от этого не легче, т.к. условия, по которым блокировка возникает, не поддаются выявлению.
Решаем разобрать по косточкам алкогоритм, с одновременным внимательным чтением хелпа -- вдруг там чего написано, а просто мы ламеры. Код товарищи, конечно, написали весьма макаронистый, но в принципе всё корректно, никаких недопустимых сочетаний использования объектов нет.
Наконец, из соображений: "А может оно там чего?" включаю трассировку вызовов ODBC. Смотрю в лог, и -- ох, у меня какие глаза делаются. Эта сволочь, оказывается, открывает несколько ODBC коннектов к серверу! Как результат -- разные датасеты оказываются связанными с курсорами в разных коннектах и, следовательно, в разных транзакциях. Естественно, изменения в этих датасетах могут привести к взаимной блокировке.
Ну, эту "не баг, но фичу" мы, конечно обошли. Но мату было много.

ЗЫ
А с некорректными аналогиями, тем более на морально-этические темы -- фсад. Или дальше...

> vuk © (11.11.04 19:36) [61]

Конкретно в этом безобразии виновато ядро БзДЕ.
Чтоб было понятнее, опишу подробнее, как это происходит.
При инициализации БзДЕ запрашивает всякие разные опции ODBC-источника, в том числе и число одновременно открытых курсоров.
Для некоторых серверов (в частности, для MSSQL) это число равно 1.
Как же должно поступать ядро БзДЕ, если мы хотим открыть сразу несколько датасетов? Либо кешировать все данные из уже открытого курсора, прибивать его и открывать новый, либо так, как оно поступает: открывать новый коннект и в его контексте уже другой курсор.

Теперь, собственно, при чём тут датасеты и наследники.
А здесь мы имеем так называемый эффект скрытой сложности.
Желание унифицировать метод доступа вообще к любым базам похвально, но неизбежно приводит к противоречивым требованиям: либо в обобщение войдёт только то, что свойственно любым базам (пересечение множеств фич), либо наоборот -- объединение множеств фич. В первом случае получится вещь слишком ограниченная, и в некоторых случаях этой органиченностью сильно мешающая. Во втором -- некоторые фичи придётся эмулировать.

Третий вариант -- когда набор отсутствующих фич определяется на этапе выполнения, а в случае их использования сопровождается исключением: "Извините! Пива нет." противоречит самой цели: создать универсальное средство, скрывающее различия.

Не знаю, понятнее стало, или нет...

Но при чем тут вообще датасет? Ну напиши наследника, в котором добавишь нужную функциональность. Но ием не менее сохранишь совместимость со всеми компонентами визуализации etc.

to DiamondShark © (11.11.04 20:11) [62]:
>Конкретно в этом безобразии виновато ядро БзДЕ.
Для MSSQL существует ограничение не на один открытый курсор, а на один недовыбранный курсор. Что, согласитесь, есть две большие разницы. Честно говоря, я не знаю, как ядро BDE поступает при работе с ODBC, но при работе с native драйверами просто происходит довыбор данных для открытого курсора и открытие нового. Специально сейчас проверял.

Что же касается фич, то в самом DataSet как раз раелизован необходимый минимум, который никто не мешает расширять. Что, в общем-то обилие различных реализаций и подтверждает.

Прямой доступ чеерз API клиентской части сервера - функционал + небольшие глюки (а куда ж без них, ну со всеми бывает)
Доступ через BDE, которая обращается к клиентской части сервера - функционал + небольшие глюки в квадрате
Доступ через BDE, которая обращается к ODBC которое обращается к клиентской части сервера - функционал + небольшие глюки в четвертой степени.
Причем количество функционала не увеличивается, сколько премудрых промежуточных драйверов и прогрессивных технологий не насуй между "формой" и API сервера.

сорри за дубль [66]

> [62] DiamondShark © (11.11.04 20:11)

Я понимаю, что у нас сие наболело, но при чем тут DataSet как таковой??
Впрочем, вопрос скорее риторический. Т.е. вы вроде и сами понимете.

Ваше мнение на мой подход. Найти похожие ветки