DBAware компоненты - за и против

← →
Кулюкин Олег © (2002-03-12 08:57) [0]

Не раз сталкивался с точкой зрения что лучше не использовать компоненты с закладки "Data Controls", а считывать данные в свои структуры и все операции с ними проводить ручками.
Плюсы такого подхода - полный контроль. Легко передать объект в процедуру. Данные можно визуализировать любым способом, не ограничиваясь Гридами-ДБЕдитами-ДБЛукАпами.
Минусы - то что раньше делалось кликом мыши, теперь требует основательного проектирования, тестирования и т.д (короче, возрастает объем работ).

Кто что думает по этому поводу?
Кто отказадся от DBAware компонентов и почему?

← →
Кулюкин Олег © (2002-03-12 09:02) [1]

2 Модератор
Прошу прощения, это должно было попасть в "Потрепаться".
НЕ туда отправил :(

← →
Виктор Щербаков © (2002-03-12 09:11) [2]

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

← →
Polevi © (2002-03-12 09:51) [3]

Можно пользоваться, главное чтобы собственного изготовления были :-)

← →
Роман Василенко © (2002-03-12 10:31) [4]

Эээ... Я долгое время пользовался "альтернативными" методами. Вот что скажу: 95%-97% задач, связанных с какой бы то ни было структурой эффективнее всего решаются посредством обстракции, именуемой TDataSet. А вот, что там уже на голове у него сидит - вопрос другой.

← →
drpass © (2002-03-12 10:39) [5]

Когда как. Если функциональности Data Controls для поставленной задачи вполне хватает, то почему бы ими не пользоваться?
А когда нужно что-то большее (или красившее :), и сроки не поджимают, тогда мы сочиняем свое

← →
Andrey © (2002-03-12 11:08) [6]

Придерживаюсь той же точки зрения что и drpass.

Также хочу предложить пару интересных ссылок противникам DBGrid-а.
http://delphi.bugs.ru/grids.shtml
http://spenov.narod.ru/DBGridEditor/DBGridEditor.html

← →
Sergey13 © (2002-03-12 11:16) [7]

Ну тогда и писать лучше на асемблере. Причем желательно в "своей" операционке. Вааще что угодно можно сварганить. Какого контроля тебе не хватает? И как ты собираешся отображать данные? И кто будет поддерживать твои программы(только не я)? И кто будет платить за такие извраты (проектирование и реализация собственных контролов)?

← →
vuk © (2002-03-12 11:26) [8]

У себя мы стандартные гриды не используем. Перешли полностью на компоненты от DevExpress. И, кстати, в этом вопросе не согласен с противниками использования сторонних компонентов. Использовать их можно, и если они решают требуемые задачи - даже нужно, поскольку это экономит время и деньги. Естественно, необходимо тщательное тестирование до принятия решения об использовании.

← →
Кулюкин Олег © (2002-03-12 12:31) [9]

2 Sergey13 © (12.03.02 11:16)
Не покажите ли где шла речь о собственных контролах?

> И как ты собираешся отображать данные?
Есть DrawGrid, TreeView и ListView.

← →
Andrew Kaufman (2002-03-14 05:27) [10]

2 Кулюкин Олег © (12.03.02 12:31)
> Есть DrawGrid, TreeView и ListView.
Вот только учитывая их (TreeView и ListView) тормознутость и легкую глюкавость, рекомендую VirtualTree by Mike Lischke.
Не так давно перешел на него, и очень доволен. Хотя поработать ручками над немного больше, но и результаты несравненно выше.
Если кто заинтересуется:
http://www.lischke-online.de/VirtualTreeview/VT.html
Полностью бесплатен, с исходниками.

← →
Sergey13 © (2002-03-14 09:07) [11]

Кулюкин Олег © (12.03.02 12:31)
>Не покажите ли где шла речь о собственных контролах?

Ну так если ты предлагаешь не использовать "компоненты с закладки "Data Controls",а считывать данные в свои структуры " а про "Есть DrawGrid, TreeView и ListView" ты не писал, то что я должен был подумать? Я и подумал, что ты собираешься изобрести свои методы отображения информации из БД. Ведь если тебе просто не нравится работать со стандартными(из поставки) "Гридами-ДБЕдитами-ДБЛукАпами" и ты предпочитаещь пользоваться другими(своими - чужими не суть) - это совсем другой вопрос. Я и сам ими не пользуюсь, кстати.

2Кулюкин Олег © (12.03.02 08:57)
>Минусы - то что раньше делалось кликом мыши, теперь требует >основательного проектирования, тестирования и т.д (короче, >возрастает объем работ).
Ты же сам себе отвечаешь в своем вопросе. Чем больше кода пишешь тем потенциально больше ошибок, тем меньше производительность (как правило), тем труднее сопровождение, тем...8-( Кроме этого, такой подход плох еще и тем, что начинаешь больше думать не о функционале программы которую пишешь, а о всяких "интерфейсных" делах, и на это уходит все больше времени. В результате можно сделать "красиво и оригинально", но при этом "тормозно и глюкаво".
Хотя я не отрицаю, что для каких то специфических работ такие вещи необходимы. Но таких случаев я при работе с БД, я думаю много меньше 1%.

← →
Кулюкин Олег © (2002-03-14 10:51) [12]

2 Виктор Щербаков © (12.03.02 09:11)
> Но при разработке учетного софта с большим количеством справочников они зачастую дают почти всю необходимую функциональность пользовательского интерфейса.
ДА, тут поспорить не могу.

2 Andrew Kaufman (14.03.02 05:27)
> Вот только учитывая их (TreeView и ListView) тормознутость и легкую глюкавость, рекомендую VirtualTree by Mike Lischke.
Наслышан, посмотрю.

2 Sergey13 © (14.03.02 09:07)
> Я и подумал, что ты собираешься изобрести свои методы отображения информации из БД
Нет :) Дорого обойдется.
Но, ИМХО, DBAware контролы хороши исключительно для отображения справочников. Да и то в гриде начинаешь ручками ячейки раскрашивать...

>Кулюкин Олег © (14.03.02 10:51)
А мне кажется что работа с БД на 99% и состоит из работы со справочниками и другими ТАБЛИЧНЫМИ данными. И не мудрено, так как БД это, в конечном итоге, и есть набор ТАБЛИЦ.

>Да и то в гриде начинаешь ручками ячейки раскрашивать...
Мне вообше кажется(я уже писал) что ты, по моему, слишком много внимания уделяешь "раскрашенности". Иногда это и не плохо, но чаще, кроме ряби в глазах, ничего не дает. Только мешает. ИМХО чем стандартнее интерфейс, тем лучше.

есть в паскале такое соглашение: "к данным и методам класса, объявленным в секции private могут обращатся: 1) методы этого класса; 2) все, что находится в том же модуле (unit)".

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

в итоге получается ситуация, когда очень сложно (а иногда и невозможно) написать своего потомка от стандартных.

например, TDBLookupListBox является потомком TDBLookupControl. оба класса описаны в одном модуле. это позволяет TDBLookupListBox обращаться к private членам своего родителя.
наш потомок от TDBLookupControl, естесственно, будет располагаться в другом модуле и private члены родителя ему не видать, как своих ушей. а нужны!

borland должен был сделать эти нужные члены protected, но у них (благодаря одному модулю) были развязаны руки и о нас они не думали.

вот это главная претенция к vcl и dbaware в частности.

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

это нормальный и правильный подход (dcom, corba, ejb и т.д. - все о том). и хотя borland декларирует и поддержку com, corba и т.п., но ничего не делают для помощи написания клиентских приложений. контролы в клиентском приложении уже должны не с полями в бд взаимодействовать, а с атрибутами объектов. стандартных компонентов таких нет.

такую поддержку можно ввести, написав какие-либо потомки TDataSet, которые будут, например, через IDispatch получать список пропертей объекта и представлять их в виде полей для работы обычных dbaware-компонентов.
вариантов много, но стандартного от borland ничего нет :(

это еще одна претензия.

← →
Donal_Graeme (2002-03-14 17:14) [16]

> чем стандартнее интерфейс, тем лучше.

а кто устанавливает стандарты и что именно считать стандртом? :-)
по-моему стандарт в данном случае понятие расплывчатое. Кто к чему привык, тот то стандартом и считает.

2 paul_shmakov
> но есть и другая проблема. особенно в больших системах удобно представлять архитектурные абстракции ввиде классов
Точно!
Об этом я и говорил начитая тему.
Если нужно манипулировать сложными данными на клиенте, то лучше хранить эти данные в своих классах.

DBAware компоненты - за и против Найти похожие ветки