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

← →
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 ?

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

blackman © (11.11.04 15:43) [45]

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

← →
by © (2004-11-11 15:59) [50]

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

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

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

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

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

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

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

← →
DiamondShark © (2004-11-11 16:06) [52]

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

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

← →
Dok_3D © (2004-11-11 16:08) [53]

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

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

← →
by © (2004-11-11 16:08) [54]

[51] Суслик © (11.11.04 16:06)
Видно прийдется опять набивать шишки самостоятельно )))

← →
vuk © (2004-11-11 16:15) [55]

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

← →
DiamondShark © (2004-11-11 16:32) [56]

> vuk © (11.11.04 16:15) [55]

А конкретные места где ты -- человек, будут?
Как целое.

← →
karat © (2004-11-11 16:44) [57]

Все что нашел Фаулера.
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

← →
vuk © (2004-11-11 16:53) [58]

to DiamondShark © (11.11.04 16:32) [56]:
>А конкретные места где ты -- человек, будут?
>Как целое.
Понял, улетаю.

← →
msguns © (2004-11-11 17:06) [59]

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

← →
DiamondShark © (2004-11-11 19:16) [60]

> 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 как таковой??
Впрочем, вопрос скорее риторический. Т.е. вы вроде и сами понимете.

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