Блог Александра Божко
Архивы
Рубрики
Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Прежде чем я начну повествовательную часть этого поста, хочу поздравить блог Delphi в Internet с юбилеем. Хорошая работа, Влад. Содержательные посты, а главное после их прочтения приходят отличные идеи. Я уверен, на базе примеров из блога можно реализовать несколько успешных проектов. Только где на все найти время?

Но, об идеях потом, а пока о DataSnap. Речь пойдет не о банальном описании технологии, а об  организации конкретного проекта.

Предпосылки

В серии постов “Редизайн интерфейса приложения” (серия отнюдь не завершена) я вкратце обрисовал над чем я работаю.  Но кроме того, что я рассказал, есть еще некоторые нюансы. Дело в том, что у приложения есть Web версия. Она написана на ASP (не .Net) и обеспечивает примерно тот же функционал.  Вообще изначально это были два разных приложения, работающие на разных БД. Но потом вследствие расширения возможностей каждого из них,  мы привели их к общему знаменателю. Оказывается бывает и так, эволюция проектов – штука непредсказуемая. В последней версии нам удалось полностью синхронизировать БД и теперь обе программы не просто обмениваются данными, но и могут работать с одной базой напрямую.

После перевода приложения на DevExpress и некоторого расширения функционала встал вопрос: “Куда двигаться дальше?” Естественно, нужно расширять функционал. При том сразу в двух приложениях. И вот здесь руководство приняло единственно верное, на мой взгляд решение – вынести бизнес-логику в отдельный уровень и сделать ее общей. А интерфейсы, соответственно, оконный и веб – привязать к уровню приложения. Попутно перевести веб часть на .Net (это ужас, попробуйте найти человека, который будет сопровождать старый ASP код), ну, а оконное приложение придется разбивать на две части.

Выбор технологии

Собственно, это тот этап на котором мы сейчас находимся, и данный пост – отчасти попытка посоветоваться с читателями блога. Проблема в том, что с одними и теми же наборами данных хочется работать и в Delphi и в ASP .Net приложении. При том очень не хочется влазить в дебри com-объектов, интерфейсов   и прочих “тяжелых” вещей. И ничего лучшего чем DataSnap в голову мне не приходит. Обновленный DataSnap буквально воспели Марко Кэнту и Боб Сварт, написав подробные руководства по практическому применению. И складывается впечатление, что это действительно не сложно. А главное, по крайней мере, Delphi Prism позволяет написать клиента, работающего с сервером на писанным на обычном Delphi. Вот вам и совместимость с .Net. Конечно, вряд-ли ASP .Net разработчик спрыгнет с C#, но коль скоро, в Призме есть какие-то компоненты, то есть и сборки. А если есть сборки, то в теории можно все это прикрутить к Visual Studio. К тому же, в Интернете есть какие-то солюшны по этому вопросу.

Ну, а в качестве скромной платы за дельные советы (уверен, они будут),  я расскажу как привязаться через DataSnap к базе MS Access.

Тестовое приложение

Если честно, задача связывания ADO (dbGo) и DataSnap не такая уж и сложная, но в Интернете мне не удалось найти ни одного примера… Все демонстрации основаны на использовании DBExpress в качестве механизма доступа к данным. Хотя везде говорится о возможности использовать практически любой набор компонентов. И только внимательное прочтение этого документа (он переведен на русский)  позволило разобраться, что нужно изменить в тестовом примере, что бы заставить заработать приложение с БД MS Access. Примеры для книги Марко Кэнту Delphi 2009 Handbook находятся в открытом доступе, предлагаю модифицировать наиболее простой из них. Глава 12, First3Tier2009.

Сервер

Форма FormFirst3Tier2009Server нас не интересует. Тут все настроено правильно и должно так и остаться. Привязка к данным осуществляется в DSFirst3TierServerModule. Изначально мы видим связку компонентов TSQLConnection -> TSQLDataSet -> TDataSetProvider.

Здесь нам просто нужно настроить подключение к БД через dbGo. TADOConnection->TADOTable (или, другой ADO датасет)->TDataSetProvider.

Теперь запускаем серверное приложение в режиме Without Debug и переходим к клиенту.

Клиент

Оказывается в клиенте все еще проще. Насколько я себе смог уяснить, клиентская часть для связи с БД всегда будет использовать DBExpress. Поэтому тут нам вообще ничего не надо менять. Просто запускаем приложение и наслаждаемся его работой. Почему-то мне изначально казалось, что в клиенте я тоже должен использовать dbGo соединение. Это не так. Замечательная иллюстрация идеи многозвенности. Мы можем как угодно менять уровень приложения, но уровень интерфейса – не меняется. На практике, конечно, все сложнее, но сам принцип понятен.

Следующим шагом я попытаюсь привязаться к серверу из Delphi Prism. А затем и из Visual Studio. Но об этом я расскажу, когда сделаю пример.


Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

20 комментариев: DataSnap в Delphi 2009/2010 #0

  • Спасибо, Александр! Постараюсь и дальше не разочаровывать. Одну идею пытаюсь реализовать – по Гуглу. Посмотрим, что выйдет.
    По сабжу поста: читал где-то или слышал, что DataSnap прекрасну дружит с JSON, но толи я не туда смотрел, то ли лыжи не едут. Нашел пару классов для JSON, но они какие-то куцие. Можете чего-нибудь посоветовать в плане работы DataSnap с JSON – примеры, книги, статьи? Интересуют именно “штатные” средства Delphi, т.к. всевозможные библиотеки сторонних разработчиков уже использовал.

    • А вот я как раз читаю перевод мануала Боба Сварта, там это упоминается. Сейчас разберемся…

    • >Нашел пару классов для JSON, но они какие-то куцие

      Сторонние?

      Я использую JSON – SuperObject (Франц) (http://www.progdigy.com/?page_id=6) и просто счастлив в плане удобства и элегантности, тотже lkJSON нашего соотеч. ему явно проигрывает. Одной строкой кода можно получить всё что нужно не создавать/удалять объект.
      “штатные” насколько мне известно будут 2011

      • 2Юрий, назвать SuperObject куцим я бы не решился :) Отличная штука. Сейчас как раз его и использую, когда возникает необходимость. Просто хотелось бы обходится минимумом стороннего. В Delphi 2010 есть описания классов вроде бы как для поддержки JSON, но вот как из использовать я так и не врубился.

        • Влад, Я думаю, что DataSnap с JSON будет немного различаться работа от тогоже SuperObject.
          В DataSnap у нас есть клиен. объект и серверный объект(прокси), клиентский управляет серверным, по средствам либо XML либо JSON либо ещё чемлибо (и тут они дают выбирать). Саму JSON формировать не придётся ,как XML, т.е. работайте на более высоком уровне. Ну это моё виденье как скорее всего это будет работать. А отказываться от SuperObject из-за того что он не в стандарте – х.з. тем более у них GPL лицензия

        • http://www.andreanolanusse.com/blogen/datasnap-2010-sending-and-receiving-objects/
          DataSnap 2010 – sending and receiving objects

          DataSnap 2010 brings support for JSON …

  • Идея классная, только не совсем понял 2-е звено (Сервер прил.) будет нативный или нет(.нет)? просто написано ADO (dbGo).
    Почему ADO а не DBExpress?

    • Будет нативный, это точно. Стандартные компоненты из набора dbGo. Потому, что они использовались в предыдущей версии приложения. Да и подружить DBExpress с Access проблематично, как я понял.

      • Будет нативный – считаю классная идея, интересна как она будет
        (имел опыт участия: где 2-e звено
        a)как DCOM/Борланд Сокет Сервер – ужасно неудобно,
        б) как .net, через SOAP (клиент Del ловил xml преобраз в xml для CDS) – скорость плохая, неудобно
        с) как .net через Ремоутинг (клиент .net) – скорость просто ужас.
        (Ну это моё сугубо личное мнение))

        да ADO с Access – по скорости самое медленное что есть

  • по идеи новый ДатаСнап должен обскакать их

  • А, кстати, что еще есть кроме ADO с Access?
    Сторонние, разве что? Или DBExpress все же можно прицепить?
    BDE не в счет…

    • По моему ничего. Ну по крайне мере я незнаю.
      Я тут имел виду наверно Access как сам посеве)) С любой SQL CУБД или DBF он не конкурент

  • А, ну да. Я сам его не люблю. И даже скорость в нем не главное зло. Там БД сама любит падать, потом ее чинить приходится.

    • Да, уж)) Я бы на вашем месте не 3-х звенку а перевод БД с Аксеса на какойнибудь FB или MS SQL сделал бы (ну если вы конечно Аксесовский интерфейс не используйте)

  • Александр, ещё 2 вопроса интересны

    1) Рассматривали ли Вы аналоги DataSnap типа когонибудь РемОбджект, …?
    2) В вашей архитектуре На N клиент. соединений с Сер.Прил. – сколько соединений с СУБД(1 или N или M)?

    • Ремобджект – не рассматривал… Хотя в принципе Призма сама по себе их продукт…

      Одно получается, если, конечно не делать специальных телодвижений.

  • Я совсем не очень программист ) Пытался переделать этот пример для подключения БД Access, создаю ConnectionString, CommandText для ADODataSet, включаю их, со стороны сервера все хорошо, данные есть, но клиент отказывается работать, пишет Project First3Tier2009_Client.exe raised exception class TDBXError with message ‘Remote error: Authentication failed’.
    Подскажите в чем может быть проблема? Если есть примеры приложения DataSnap с подключением БД из уже работающего приложения буду благодарен за ссылку.

Оставить комментарий

Ваш email не будет опубликован. Обязательные поля отмечены *

Вы можете использовать это HTMLтеги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика