Распределенный DataSet

← →
Nikols © (2002-12-03 12:22) [0]

"Распределенный DataSet". Возникли мысли, решил поделиться...

Как известно, за доступ к данным отвечает обычно обьект DataSet. В распределенных системах в технологии CORBA возникает проблема доступа к данным из тонкого клиента. Появилась мысль написать "Распределенный DataSet", который состоит из двух частей:

1. На стороне сервера будет обеспечивать доступ к данным и иметь IDL интерфейс для взаимодействия с клиентской частью.
2. На стороне клиента будет создаваться потомок DataSet (DataSet имееется практически во всех языках),
который через интерфейс будет взаимодействовать с серверной частью.

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

Хотелось бы обратить внимание на следующее:

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

2. Если пойти дальше, то можно реализовать непосредственное редактирование данных с автоматическим построением SQL внутри и отображением результата из базы в клиентской части.

Вопросы:

Нужна документация по DataSet. Не разбирался ли кто с механизмом работы DataSet, который позволяет производить выборку части данных запроса и подтягивание записей по требованию. Не могли бы подсказать
какую либо документацию, или простой пример реализации? Знаю, что можно по исходникам TBDEDataSet (Delphi), но может кто то уже этим занимался?

Предлагаю обсудить нужность такой штуки... И как всегда рад критике, советам, участию в дискуссии...
В дискуссиях создана тема:
http://www.corbaejb.mastak.ru/ikonboard/ikonboard/topic.cgi?forum=6&topic=35
Прошу...

С уважением, Смирнов Николай

← →
sesam (2002-12-04 14:55) [1]

Вот уж точно: идеи витают в воздухе! Насчет TDataSet вообще - не знаю, не пробовал. А Direct Oracle Access (DOA) переделывается достаточно просто: в его основе (TOracleDataSet, TOraclePackage ...) лежит TOracleQuery. Поэтому оказалось достаточным переписать его, а также изменить методы createSession, (dis)connect, commit и rollback для TOracleSession и реализовать их (и метод TOracleQuery.execute) на сервере. Естественно, сервер должен обеспечивать как минимум, авторизацию и хранить его состояния клиента (открытые Oracle-сессии etc).
После этого любое клиентское 2-звенное DOA-приложение путем простой замены (по исходникам) названий классов становится многозвенным. Собственно, это и было шок-фактором, по которому не проходил, напр., midas: нужно было быстро и безболезненнно перевести в многозвенку большой объем приложений с достаточно расзвесистой логикой.

Удачи.

← →
sesam (2002-12-04 16:43) [2]

Вдогонку: т.к. DOA for CPP написан на delphi, проблема многозвенки для CBuilder"а решилась естественным путем. Что касается JBuilder, пришлось переделать QueryDataSet.

Ограничение на кол-во записей проще всего реализовать через QBE и _ограничение_ на размер результирующего пакета (напр., 50К) с выдачей соотв. сообщения пользователю (типа "Запрос слишком велик. Отобраны первые n записей") - пусть сперва подумает, чего он хочет, а не давит до одури PgDn :)

И в заключение: в подобных конструкциях есть несколько НО: во-первых, это чистый on-line (если отвалится сервер, пользователь потеряет старательно набитый многостраничный документ и скажет вам бооольшое человеческое спасибо) - в этой ситуации ClientDataSet ведет себя гораздо честнее; во-вторых, если некорректно закрытое клиентское приложение не вызовет серверную destroySession, вы получите "подвисшие коннекты" (привет от BONY :) - значит надо реализовывать CallBack-вызовы или др. механизмы периодической проверки "живости" удаленного клиента и, наконец, в-третьих, в любом общем решении приходится жертвовать скоростью/эффективностю, что для распределенных приложений не есть хорошо - писать их будет легко и быстро, а вот работать с ними...

Распределенный DataSet Найти похожие ветки