DataSnap в Delphi 2009/2010 #1

В прошлой части рассказа, я описал суть проблемы. Напомню вкратце, что необходимо создать трехзвенку, с MS Access в качестве СУБД и сервером приложений, написанном на Delphi. При этом клиенты должны разрабатываться и в Delphi (descktop client) и в .Net среде (ASP .Net application).

Все оказалось не совсем замечательно. Все официальные источники утверждают, что Delphi Prism может работать с DataSnap серверами. И это так. Но есть некоторые ограничения.

Как выяснилось, .Net приложения могут использовать только методы DataSnap. Вот, как описывает создание клиента в Delphi с помощью метода Боб Сварт:

Поместите TDataSetProvider в форму клиента и подключите его свойство DataSet к компоненту TSqlServerMethod. Затем поместите компонент TClientDataSet в форму клиента и подключите его свойство ProviderName к компоненту TDataSetProvider. Оставьте свойство RemoteServer пустым — оно использовалось только при устаревшем подходе DataSnap, а в новой архитектуре DataSnap оно не представлено.

Наконец, поместите TDataSource в форму клиента и подключите его свойство DataSet к компоненту TClientDataSet, после чего мы можем использовать компоненты TDBGrid и TDBNavigator. Подключите их свойство DataSource к компоненту TDataSource, и вы можете просматривать данные в форме клиента.

Поясню. Предварительно на сервере мы создали метод, который возвращает нам значение типа  TDataSet. И с помощью TSqlServerMethod мы к нему обращаемся в клиенте.  Если я правильно понял, то совершенно не важно какое подключение к БД используется на сервере. Главное, что бы в результате в методе сервера отдавался TDataSet. На клиенте же мы его принимаем, используя TSQLConnection (для подключения к серверу), TSqlServerMethod (для обращения к методу) и TDataSetProvider (что бы загнать DataSet, отдаваемый методом в TClientDataSet в клиенте). При этом, цитирую:

… данные доступны только для чтения, поскольку компонент TSqlServerMethod не позволяет сочетанию TDataSetProvider и TClientDataSet отправлять какие-либо обновления с клиента DataSnap на сервер DataSnap таким способом.

Т.е. клиент – однонаправленный. А вот здесь начинаются непонятности. В исходном примере на сервере тоже было задействовано DBExpress подключение. Как я уже говорил, я его заменил на DBGo. В результате клиент не может вызвать метод сервера. Не соответствие типов…  В то же время, если использовать  TDSProviderConnection, без вызова метода – все ОК. Для меня это, по меньшей мере, странно. Ведь TADOTable, который я использовал на сервере, возвращая в методе – наследник TDataSet.

Первой мыслью было – кто-то не откровенен. И на самом деле, на сервере тоже можно лишь использовать DBExpress в полном объеме (в том объеме, который нужен для построения .Net клиента).

Однако для очистки совести я сегодня поставил AnyDAC и с его помощью подключился к БД на сервере… Вопреки ожиданиям метод вызвался сразу же без видимых проблем. Более того… Он вызвался и в Delphi Prism, и соответственно в Visual Studio 2010.

Простите меня за несколько сумбурный пост, очевидно, что вышесказанное станет понятно только тому, кто хотя бы пытался смотреть примеры DataSnap.

Выводы:

• Не все золото, что блестит. С точки зрения DataSnap, не всякий DataSet - DataSet, даже если он наследник TDataSet.
• Если предусматривать возможность написания .Net клиента, то сервер усложняется, ввиду того, что .Net клиент будет однонаправленным и нам понадобится реализовывать много методов на сервере руками.

Возможно, я с чем-то недоразобрался. Но очень похоже, что ситуация обстоит именно так. Завтра постараюсь выложить и описать пример простейшего сервера и двух клиентов (нативного и .Net). А заодно можно будет прикинуть стоимость средств разработки…