Как вы относитесь к 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 например другие. Там нет всех таких проблем, ибо перемещение по гриду <> перемещению по датасету. Но в дельфи проблема существует.

← →
MsGuns © (2010-02-03 11:35) [29]

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

← →
Sergey13 © (2010-02-03 11:38) [30]

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

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

← →
MsGuns © (2010-02-03 11:39) [31]

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

← →
vuk © (2010-02-03 11:42) [32]

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

← →
Sergey13 © (2010-02-03 11:42) [33]

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

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

← →
MsGuns © (2010-02-03 11:43) [34]

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

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

← →
vuk © (2010-02-03 11:47) [35]

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]

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

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

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

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

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

> [40] Вариант (03.02.10 12:43)

ИМХО есть целость и непротиворечивость данных в понятиях сервера СУБД (ключи и зависимости разные) и есть то-же самое в понятиях бизнес-логики (типа остаток=приход-расход). Грид сам по себе не может нарушить ни первое ни второе. Первому просто пофиг кто и как что-то делает. А второе зависит только от программиста.

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

> Sergey13 © (03.02.10 13:35) [41]

Нет кода - нет бизнес логики -я собственно об этом говорил.

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

Когда мы код в датасете, в котором ты проверяешь бизнес логику, привязываем фактически к гриду ( вот перемещение в гриде вызвало переход на следующую запись в датасете и надо запретить переход так как мы в dsEdit или dsInsert, делаем в обработчике(ax) датасета Abort), то это на мой взгляд и есть лишний код, не связанный с бизнес логикой. И это не единственное место, где прийдется писать подобный код и не единственная ситуация.

> [42] Вариант (03.02.10 13:55)
> вот перемещение в гриде вызвало переход на следующую запись
> в датасете и надо запретить переход так как мы в dsEdit
> или dsInsert, делаем в обработчике(ax) датасета Abort),
> то это на мой взгляд и есть лишний код

А в модальной форме ты не проверяешь заполненность всех нужных полей? Это не один и тот же код?

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

> Sergey13 © (03.02.10 14:01) [43]

Это разный код на мой взгляд. И там и там есть одни и те же проверки, и там и там я могу показать сообщение о том, что-то не так. Но в модальной форме я могу сделать это в одном месте. Мне нет необходимости отслеживать другие связанные с датасетом контролы вне модальной формы, если такие есть... Модальная форма не даст к ним обратиться. В случае с гридом же пользователю например хотелось бы видеть внятное объяснение, почему нельзя вести поиск или надо запретить такую возможность - это тоже доп. код. - это вариант, но более раскиданный по разным местам кода.
Просто мои предпочтения в форме, по крайней мере в случае простого грида (TDBGRID) для дельфи. Это мы уже сместились в тему - почему я считаю форму с кодом лучше грида с кодом.
Изначально же вопрос был - что просто кинуть грид не получится, есть проблемы,прийдется писать код и не просто в одном месте и не код бизнес логики, а код защиты от действий связанных с особенностями редактирования в гриде

> [44] Вариант (03.02.10 14:26)
> Но в модальной форме я могу сделать это в одном месте.

В обработчике БифоПост будет примерно то же самое, ИМХО. При чем для ВСЕХ форм, в которых возможно изменение датасета.

> [44] Вариант (03.02.10 14:26)
> Изначально же вопрос был - что просто кинуть грид не получится,
> есть проблемы,прийдется писать код и не просто в одном
> месте и не код бизнес логики, а код защиты от действий связанных
> с особенностями редактирования в гриде

Перечитал изначальный вопрос. Поискал слово "код" в ветке. Впервые оно встретилось в 22 посте от Ганза. 8-)

А вопрос сводился к

> Не могу грамотно по пунктам описать, почему мне не нравятся такие компоненты, ну неудобные они какие-то.

8-)

← →
Вариант (2010-02-04 06:05) [46]

> Sergey13 © (03.02.10 15:03) [45]

> В обработчике БифоПост будет примерно то же самое, ИМХО.
> При чем для ВСЕХ форм, в которых возможно изменение датасета.
>

Напиши этот код, насколько будет то же самое? Пойдет схематично, план действий по пунктам например, 1) проверка заполненности полей согласно правилам бизнес логики 2)...еще что-то.. 3) еще что-то.

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

PS:
Признаю придрался к фразе ВСЕХ форм:-) и что не был достаточно убедителен, но продолжить сегодня дискуссию возможно не смогу или мое присутствие на сайте будет ограничено по по времени. Вчера было время, был выходной -сегодня много работы.

> [46] Вариант (04.02.10 06:05)
> Напиши этот код, насколько будет то же самое? Пойдет схематично,
> план действий по пунктам например, 1) проверка заполненности
> полей согласно правилам бизнес логики 2)...еще что-то..
> 3) еще что-то.

Так ты его уже написал. 8-)
1) проверка наличия кода, количества и цены товара
2) не все поля заполнены - выход

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

офтор
Сори за дубль. Что то у меня форум глючит. Это кстати только у меня?

Удалено модератором
Примечание: Offtopic

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