Как вы относитесь к DB-Aware компонентам?

← →
Piter © (2010-02-01 20:45) [0]

То есть, к компонентам, позволяющим «напрямую» редактировать данные из базы данных. TDbEdit, TDbGrid и прочие.

Дело в том, что лично мне эти компоненты жутко не нравятся... Они неудобные, не интуитивные, я не понимаю их, хотя сложно сформулировать причины почему. Мне не нравится их «онлайновость», навигация, Next / Prev. Я как-то привык что работа с БД происходит в режиме запрос-ответ. Мне проще сделать выборку в TxxQuery, получить результат и в цикле заполнить какие-то визуальные элементы.

DB-Aware какие-то универсальные и от того бесполезные. Особым апофеозом я считаю TDBGrid, более неудобного средства редактировать записи в БД не видел. Нихрена не понятно, особенно при добавлении новой записи... В результате появляется новая строчка помеченная звездочкой с незаполненными полями. Можно сбиться и перевести курсор на другую строчку, при этом если в новой записи не заполнено NOT NULL поле то начнутся сыпаться MessageBox"ы с исключениями. Мне как-то логичнее по кнопке "Добавить" проанализировать корректность введенных данных, чем перехватывать исключения или делать обработчики навигации...
Я уж не говорю про чудовищные возможности скроллинга (по крайней мере в стандартных) в компонентах. Вот сложно описать словами, но когда работаешь с системой, где общение с БД построено на таких db компонентах - материшься в голос. Надо думать что испытывают обычные пользователи, которые как я заметил методом тыка вырабатывают правильную стратегию и порядок тыканья в дальнейшем.
Такие компоненты слабо подходят для работы с большими объемами данных. А когда данных мало и я вижу связку Delphi + DB-aware компоненты я не понимаю, а почему бы это не сделать в Excel? И вид прямо такой же, строчки да столбцы, тыкай два раза в ячейку и пиши что надо.

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

И в связи с этим у меня вопрос — кто-нибудь понял, о чем я здесь написал? :) Интересно, это лишь мое отношение к данного вида компонентам, каково ваше отношение? Может, есть какие хорошие статьи/мысли на эту тему, видимо это из области интерфейсов, юзабилити... Может быть, это простоватость delphi компонентов, а в каких-нибудь J2EE там все круто красиво и удобно? Или я недостаточно хорошо понимаю и все это можно красиво и эффективно использовать?
Предлагаю поделиться философскими мыслями ;)

← →
KilkennyCat © (2010-02-01 20:51) [1]

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

← →
DVM © (2010-02-01 20:55) [2]

> Я как-то привык что работа с БД происходит в режиме запрос-
> ответ. Мне проще сделать выборку в TxxQuery, получить результат
> и в цикле заполнить какие-то визуальные элементы.

Мне такой подход тоже больше нравится.

> Я уж не говорю про чудовищные возможности скроллинга (по
> крайней мере в стандартных) в компонентах.

А что про сроллинг? Ну есть глюки небольшие в TDBGrid но они устраняются.

← →
Piter © (2010-02-01 21:04) [3]

DVM © (01.02.10 20:55) [2]
А что про сроллинг?

ну он просто не работае ;) Это бред по-умолчанию... Даже если это можно устранить и чем-то обосновывается...
По-моему, если ситуация такая, что через TDbGrid достаточно удобно работать, то еще более удобно будет работать тупо в excel"е, там и возможностей больше.

KilkennyCat © (01.02.10 20:51) [1]
А также не устраивает идеология. Компоненты должны быть конструктором

расшифруй мысль?

← →
KilkennyCat © (2010-02-01 21:09) [4]

> расшифруй мысль?

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

← →
Piter © (2010-02-01 21:15) [5]

KilkennyCat, не, ну тогда тебе как понимаю вообще 99% компонент не нравится, это, видимо, отдельный разговор.

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

← →
Virgo_Style © (2010-02-01 21:19) [6]

Отличная вещь, если ReadOnly выставить %-) Если нет, то начинаются загогулины.

← →
KilkennyCat © (2010-02-01 21:22) [7]

> TDbGrid

меня просто бесит.

← →
KilkennyCat © (2010-02-01 21:23) [8]

> Virgo_Style © (01.02.10 21:19) [6]

да, TDbGrid я только так и использую.

← →
Piter © (2010-02-01 21:23) [9]

во во... Кажется, я не одинок ;) Да, для отображения можно еще как-то использовать, но для редактирования...

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

← →
DVM © (2010-02-01 21:28) [10]

> Отличная вещь, если ReadOnly выставить

мне кажется, все ее только так и используют

← →
DVM © (2010-02-01 21:29) [11]

> А с этой позиции, соотетственно, использовать один тип для
> отображения, а другой тип для редактирования как-то смысла
> нет...

ну не всегда удобно это совмещать и не всегда получится

← →
vuk © (2010-02-01 21:33) [12]

Отношусь положительно. Стандартных гридов не использую. Скроллинг нормальный.

← →
antonn © (2010-02-01 22:59) [13]

> Мне проще сделать выборку в TxxQuery, получить результат
> и в цикле заполнить какие-то визуальные элементы.
>

аналогично, такой подход привила работа в php

← →
Кто б сомневался © (2010-02-02 00:21) [14]

> Piter © (01.02.10 20:45)

А что мешает юзать стандартные win компоненты? tEdit , TListView

← →
korneley © (2010-02-02 00:33) [15]

> Piter © (01.02.10 20:45)

Напиши свой. Хороший. "Грид всех времён и народов". С телепатором внутри. Опубликуй. Благодарности не задержатся. Если будет за что.

← →
Германн © (2010-02-02 02:37) [16]

> Как вы относитесь к DB-Aware компонентам?
>
> Piter © (01.02.10 20:45)
>
> То есть, к компонентам, позволяющим «напрямую» редактировать
> данные из базы данных. TDbEdit, TDbGrid и прочие.
>

Нормально отношусь, ибо работал, работаю иногда с родными для BDE базами.

← →
vuk © (2010-02-02 08:46) [17]

to Германн © (02.02.10 02:37) [16]:

> ибо работал, работаю иногда с родными для BDE базами.

Э... А при чем здесь BDE?

← →
Sergey13 © (2010-02-02 09:26) [18]

> [0] Piter © (01.02.10 20:45)
> мне эти компоненты жутко не нравятся

Человек с ружьем заставляет их юзать?

А мне нравится практически все. Все интуитивно понятно и логично. Не нужны всякие лишние прокладки в виде простых визуальных контролов.
Просто при работе с БД, несмотря на кажущуюся универсальность, необходимо четко представлять как это работает и на уровне собственно СУБД (всякие там транзакции и т.п.) и на уровне прикладной задачи (что, как и в каком порядке должен вводить пользователь). И исходя из этого строить интерфейс.

← →
Германн © (2010-02-03 02:21) [19]

> vuk © (02.02.10 08:46) [17]
>
> to Германн © (02.02.10 02:37) [16]:
>
> > ибо работал, работаю иногда с родными для BDE базами.
>
> Э... А при чем здесь BDE?
>

При том, что "стандартный грид" можно использовать для редактирования без проблем.

← →
korneley © (2010-02-03 03:08) [20]

> Германн © (03.02.10 02:21) [19]
> >При том, что
> "стандартный грид" можно использовать для редактирования
> без проблем.

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

← →
MonoLife © (2010-02-03 08:16) [21]

> То есть, к компонентам, позволяющим «напрямую» редактировать
> данные из базы данных.

В он-лайн ковыряться ручками в таблицах? Иногда вынужден, поэтому, хорошо, что они такие (компоненты) есть:)

← →
MsGuns © (2010-02-03 09:51) [22]

"Без проблем" не получится, ибо при работе приложения будут постоянно возникать "нештатные" ситуации, которые, если их не обрабатывать доп.кодом, приводят к недоразуменям и ошибкам.
Для написания проги, которая будет позволять НОРМАЛЬНО редактировать таблицу в сетке, придется написать кучу кода. А иногда это вообще невозможно сделать логически корректно (например при параллельном редактировании с нескольких ПК)

ИМХО, если требуется работать с таблицей в манере экселя, то лучше всего имитировать правку в сетке, пряча собственно обмен данными с БД и "подсовывая" вместо сетки вполне недэбэшные контролы

← →
картман © (2010-02-03 10:01) [23]

Удалено модератором
Примечание: Выражения выбираем, не в пивной

← →
Sergey13 © (2010-02-03 10:19) [24]

> [23] картман © (03.02.10 10:01)

Какой "геморрой" можно получить при редактировании простого справочника в "стандартном гриде"? Если не секрет конечно. По пунктам.

← →
vuk © (2010-02-03 10:20) [25]

to Германн © (03.02.10 02:21) [19]:

> При том, что "стандартный грид" можно использовать для редактирования
> без проблем.

Это понятно. Но, еще раз повторяю, при чем здесь BDE? На мой взгляд ни при чем.

to MsGuns © (03.02.10 09:51) [22]:

> А иногда это вообще невозможно сделать логически корректно
> (например при параллельном редактировании с нескольких ПК)

Опа... А мужики-то не знают...

← →
Вариант (2010-02-03 10:51) [26]

> Sergey13 © (03.02.10 10:19) [24]

Проблема в том, что надо много учесть - например реакцию грида при перемещении по строкам датасета (а грид в Edit или Insert), реакцию грида при переходе за EOF (это правда легко контролируется)? Но всех мелочей сразу не вспомнишь. Надо предусмотреть и другие связанные с этим датасетом контролы и возможно отключать их реакцию на время редактирования. Одним словом проблемы бывают. Мне приходится сопровождать стороннюю программу, где разработчики не предусмотрели всех "прелестей" редактирования в гриде - в итоге есть и потери и запись данных не в ту строкуи прочее. Одним словом просто кинул TDBGRID и спокойно редактировать в нем без доп. кода - в дельфи 6 по крайней мере это не будет работать устойчиво. А вот создать например модальную форму для ввода данных оказывается проще и безопасней.

← →
Sergey13 © (2010-02-03 11:01) [27]

> [26] Вариант (03.02.10 10:51)

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

← →
Вариант (2010-02-03 11:32) [28]

> Sergey13 © (03.02.10 11:01) [27]

Согласен от части, проблемы в изменении датасета. На датасет влияет грид, перечисленные проблемы не возникают, если я просто редактирую в отдельной форме. Я писал код, который устраняет проблемы "грида", он не меньше, чем
"
> портацию данных в нее и обратно (это же все писать надо)

)" - чем сделать нормальную форму для редактирования. Ибо в итоге из-за "просто кинул и редактирую" мне приходится писать новую программу.

> это круто, правильно да еще и "проще и безопасней"?

Это не круто - это правильно и безопасней для данных. Ибо меня например задолбало восстанавливать данные после работы программы, в которой просто кинули грид и спокойно редактируют.... Я не скажу , что я вообще против грида. Грид и датасет(DataTable) в классах .NET например другие. Там нет всех таких проблем, ибо перемещение по гриду <> перемещению по датасету. Но в дельфи проблема существует.

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

> [28] Вариант (03.02.10 11:32)
> Ибо меня например задолбало восстанавливать данные после
> работы программы, в которой просто кинули грид и спокойно
> редактируют....

Ты думаешь будет меньше проблем если те же авторы все сделают на отдельной форме? Сомневаюсь.

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

Вот не знаю я. Используем QuantumGrid. Это вообще один из основных элементов управления в программах. Все обработчики, которые, как правило, надо написать, они на уровне DataSet и его полей. Вставка данных непосредственно из грида не используется. Редактирования в гриде - полно. Проблем нет. Видимо, что-то делаем не так.

> [29] MsGuns © (03.02.10 11:35)

Во первых можно не давать переходить на слудующую запись и заставлять заполнять все поля правильно.
Во вторых можно не делать это прямо в активном датасете. Я например частенько подсовываю (особенно для вставки новых данных) таблицу в памяти, с которой работаю все теми же ДБ компонентами. Очень удобно.

>Sergey13 © (03.02.10 11:38) [30]
>Ты думаешь будет меньше проблем если те же авторы все сделают на отдельной форме? >Сомневаюсь.

Зря сомневаешься.
"Проблемы" могут быть только на начальном этапе и только у теть, привыкших к эксельной манере.
Через некоторое время тети понимают, что в "модальной" технологии имеется масса плюсов относительно надежности и достоверности данных в базе. А технология ввода, квадратно-гнездовая или построчно-очередная - это всего лишь привычка, а привычки, как известно, иногда полезно и поменять

to MsGuns © (03.02.10 11:39) [31]:

> использовать TClientDataSet, откуда по команде заносить
> в БД полностью введенную информацию в БД единым пакетом
> (транзакцией)

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

> [34] MsGuns © (03.02.10 11:43)

Ты ИМХО с легкостью готов менять привычки других, но ни в какую не хочешь менять свои.
Если работа этих "теть" состоит из постоянного вколачивания здоровенных портянок и им УДОБНО вводить "квадратно-гнездовым" методом, то я не вижу идеологических причин не предоставить им эту возможность.

← →
Вариант (2010-02-03 11:55) [37]

> Sergey13 © (03.02.10 11:38) [30]

> Сомневаюсь

Говорим не об авторах, которые могут ошибиться, напортачить.
А говорим о подходе - просто кинул грид и редактирую или таки пишем доп. код или (на мой взгляд лучше) делаем отдельную форму редактирования с кодом естественно для редактирования. Портирование данных нужно только если не используем DBAWARE компоненты для редактирования. Я в последнее время не использую их -поэтому да - есть код и для портирования данных, но это скорее связано с условиями задач.

Считаешь ли ты, что достаточно кинуть грид, добавить DBNavigator и этого достаточно?

Пока аргументы привожу я.
Если есть аргументы у тебя -приводи. Вполне возможно я не знаю каких-то приемов работы - готов выслушать.

> [37] Вариант (03.02.10 11:55)

> А говорим о подходе - просто кинул грид и редактирую или
> таки пишем доп. код

А где я призывал не писать код? Обработчики - это не код что ли? Меня стремает писать лишний (с моей точки зрения) код только по идеологическим причинам.
Сразу оговорюсь - у меня тоже есть модальные формы и все такое, но не так много и только там, где мне показалось, что по другому никак.

> Считаешь ли ты, что достаточно кинуть грид, добавить DBNavigator
> и этого достаточно?

Иногда достаточно.

>Sergey13 © (03.02.10 11:54) [36]
>Ты ИМХО с легкостью готов менять привычки других, но ни в какую не хочешь менять свои.

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

← →
Вариант (2010-02-03 12:43) [40]

> Sergey13 © (03.02.10 12:01) [38]

> А где я призывал не писать код?

Не призывал. Я просто спросил.

> Меня стремает писать лишний (с моей точки зрения) код только
> по идеологическим причинам

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

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

Как вы относитесь к DB-Aware компонентам? Найти похожие ветки