В прошлой части рассказа, я описал суть проблемы. Напомню вкратце, что необходимо создать трехзвенку, с 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). А заодно можно будет прикинуть стоимость средств разработки…
именно проблемы, подобные описанным Вами, и заставяют меня склоняться в сторону продуктов RemObjects – там, к тому же, в качестве бонуса присутсвует поддержка native mac os x, а значит отсутствуют проблемы с iOS App Store.
Возможно RemObjects и лучше. Но есть 2 момента. Первое и главное – я в глаза их продуктов, кроме Призмы не видел.
Второе – бюджет мероприятия. RemObjects, тоже далеко не бесплатные…
кстати, а о каких именно их продуктах идет речь?
У RemObjects вообще продуктов немного, а в плане создания многоуровневых приложений их всего два: RemObjects SDK и Data Abstract. Причем Data Abstract включает в себя RemObjects как “транспортный уровень”, то есть фактически, Data Abstract является продолжением функциональности RemObjects SDK.
DataAbstract – это полноценное решение для создания многоуровневых приложений, умеющих работать с данными. Есть даже механизм выполнения SQL запросов к гетерогенным источникам (DA SQL).
RemObjects – это “транспортный” слой многоуровнего приложения, который позволяет осуществлять удаленный вызов объектов.
По поводу цен – да, очень недешево. Зато и нужно все это добро только в специальных случаях, когда пишешь многоуровневое приложение, способное работать на различных платформах. Сервер на mono под mac, клиенты на windows и delphi, а также мобильный клиент на iphone/ipad – такой сценарий вполне реален.
Вы можите скинуть ссылку на русскоязычную литературу RemObjects SDK и Data Abstract? Если есть конечно…
Здравствуйте.
У вас, как я понял, Delphi Architect, в которой все возможности Datasnap задействованы. А на страничке DAPUG http://alt.dapug.dk/ws07092010.htm упомянуто:
Note! Everything on Datasnap requires the Enterprise version of Delphi.
Вот и интересно, есть ли ограничения на Datasnap в Delphi Prism Professional. Как думаете?
Есть ограничения, я это точно знаю. Там просто нет набора компонентов dataSnap. Я просто использовал триальный архитект “для опытов”. На самом деле, Ентерпрайз вполне достаточно.