Технология работы с IB/FB

← →
msguns © (2003-04-10 18:38) [0]

Имеется в виду работа через "родные" компоненты InterBase: TIBQuery, TIBSQL, TIBDataSet, etc

Работу через TIBTable не рассматриваю (хлебнул этого "добра" еще с парадоксом+BDE).

Вижу 3 способа, которые перепробовал.

Способ только запросов. "Толстый клиент"
------------------------------------------
Все отображаемые датасеты "получаются" из TIBQuery, куда параметрами подставляются нужные значения - условия. Для вертикальных связок Мастер-детал используется св-во DataSource.
Модификации (удаления/изменения/вставки) делаются TIBSQL или "сторонним" (не отображаемым) TIBQuery для удобства подстановки параметров. Все через защищенные блоки. По завершении блока модификаций следует Commit/CommitRetaining и обновление всех отображаемых (а также калькуляционных - для итогов) запросов.

Все работает весьма чудненько.

Неудобство: код получается огроменным с кучей обращений к переоткрытию НД и позиционированием на текущую запись после ЛЮБЫХ модификаций в любых активных таблицах. Уже вовсю стараюсь пользоваться внутренними процедурами типа RefreshDataSet1 с позиционированием после переоткрытия на запись, ID которой получаю вх.параметрами - все равно текст "тяжел".

Способ с изменяемыми датасетами. "Толстый клиент"
-----------------------------------------------------
Используется TIBDataSet с соотв.св-ми Select/Update/Insert/DeleteSQL. Не надо делать позиционирование и переоткрытие, но, пробегая отладчиком по коду, увидел, что он делает за меня все эти переоткрытия, позиционирования и т.д. При этом еще весьма капризен к типам данных, подставляемым из контролов (я не даю юзеру редактить в гриде, а выбрасываю спец. панельки или формочки, где можно редактить или ввести новую запись) - через присвоение ParamByName("xxx").AsFloat/Integer etc
для TIBQuery все работало безпривередно.

- Способ "Тонкий клиент"
---------------------------
Все (или почти все) модификации делаются на сервере через ХП или триггера. Доступ же по способу 1 или 2-му. Неудобство: если проект делается по принципу "одна прога-одна БД", то из приложения неясна совершенно вся "кухня" и надо постоянно глазеть в IBExpert (к примеру).

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

Заранее благодарен всем откликнувшимся

← →
Sergey Masloff (2003-04-10 22:53) [1]

Все способы имеют право на существование. Описаные проблемы решаемы, а в п. 3 что из "морды" не ясно что в "ядре" - так оно может и хорошо?
Вот еще один способ: описать программные объекты соотв. предметной области. Добавить им методы общения с базой (через IbQuery или IBSQL). Работаю так - есть одна read only транзакция через которую работают все поиски и отборы, результаты отбора отображаются в DBGrid, вся настоящая работа ведется через свои объекты. То есть отобрал нужный объект, засосал его из БД и работай. Потом вызвал метод Store и в короткой пишущей транзакции сунул его в базу. У меня например объекты - TxxPolicy, TxxRisk, TxxLimit, TxxCond, TxxDocSum.... В другой предметной области будут другие. Нужно ввести и понятие списка (коллекции) объектов. Писанины много но появляется очень много вкусностей, начиная с недерганья сервера на каждый чих и кончая возможностью реализации сложной логики. Еще - я реализовал эти объекты в отрыве от интерфейса пользователя - для интерфейса объекты отдельные, которые с бизнес-объектами взаимодействуют. Писанины еще больше - но при необходимости можно использовать бизнес-объекты без интерфейса, вызывать их из других приложений и так далее. Вобщем, эксперимент удачный (несмотря на удлиннившийся этап разработки) зато поддерживать и развивать, по субъективным впечетлениям, проще. У программы уже полторы сотни установок, полет нормальный. Правда, если бы сейчас начинать заново я сделал бы чуть-чуть по другому. Вынес бы работу с базой (загрузка-сохранение)в отдельные объекты которым бы бизнес-объекты передавал бы как параметры. По крайней мере хочу попробовать да не знаю когда - сейчас 90%процентов времени пишу под Oracle, большой проект, корпоративный стандарт, шаг вправо-влево попытка побега. Не до экспериментов особо...

← →
Johnmen © (2003-04-10 23:00) [2]

Только личный опыт.
Для IBX (кратко):
Использование TIBDataSet для редактируемых НД; кеширование, если надо; редактирование с использованием DBAware компонент, но, если выгоднее, то и обычных; TIBQuery по необходимости, напр. для отчетов; TIBStoredProc для поддержания ХП; иногда, именно иногда с целью сокращения накладных расходов, TIBTable; по возможности в необходимые моменты CommitRetaining; бизнес-логика - максимально в базу...
Для FIBPlus - учитывая функциональные возможности и особенности...

Продолжим обсуждение...

Технология работы с IB/FB Найти похожие ветки