for flooders
:: Главная :: Решения :: Статьи :: Сайт М. Дроздова :: Файловый архив :: Книга по VFP 9 :: Русский Help Online :: OFF-LINE Форум
   Лисоводы   всех   стран,  объединяйтесь !!!  

Список Форумов  :: Обсуждаем проекты
  

Создание клиент-серверных приложений
Friktus
Автор

Сообщений: 105
Откуда: Томск
Дата: 20.04.05 06:09:26
Решил вот написать такую прогу, точнее их даже 2, с использованием SOAP протокола. Нужно написать клиента - ну тут вообщем-то особых сложностей нет. Гораздо сложнее обстоят дела с сервером. Анпример создание тех же самых уникальных ключей в момент добавления записи, использование транзакций, добавление/изменение записей сразу же в двух связанных таблицах и т.п.
Интересно было бы услышать мнения по поводу различных подходов к созданию подобных приложений и в частности по работе с SOAP протоколом.
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Igor Korolyov

Сообщений: 34023
Дата: 21.04.05 00:16:46
Hi Friktus!

Созданием ключей как и обычно занимается сама база. (Я так понимаю ты решил
в качестве СУБД использовать собственно фоксовую dbc? тогда NewID тебе в
руки, или AUTOINC - но если фокс <9 то лучше всё-же NewID - без
GETAUTOINCVALUE() получается форменное извращение )
Естественно что "создание записи" происходит именно на сервере - у клиента,
если это необходимо - используются суррогаты типа -1, -2, -3 ... Которые
потом (на сервере уже) заменяются реальными ключами - при этом "каскадно"
идёт замена и FK в подчинённых таблицах. Если же само построение интерфейса
упростить (запретить на нём "кэширование" больших объёмов информации - т.е.
как только "документ" готов - сразу его слать на сервер "записываться" и
только потом переходить к вводу очередного - ну и кроме того не вводить
нигде более чем 2-х уровневые документы - т.е. шапка+строки - но не
шапка+строки+строки-к-строкам) - то можно в простых случаях и вовсе без этих
псевдо-ключей обойтись - т.е. оставить пустое PK и соответственно пустое FK
в подчинённых.
Транзакция только на сервере - в процедуре сохранения.
Данные на сервер передаются в виде ОДНОЙ пачки - т.е. И шапка И строки - в
одном XML-е - тут должон сильно помочь XMLAdapter. Сервер очевидно
реализуется как Stateless - т.е. МЕЖДУ вызовами методов он ничего не
запоминает.
Довольно много по теме есть на сайте Михаила Дроздова (кстати намечается его
выступление по этой-же теме на DevCon в Уфе ) - то что там фигурирует
больше COM+ не должно смущать - SOAP и соответственно WebService - это лишь
своеобразная "надстройка" над COM+/DCOM - т.е. компоненту лучше в любом
случае разместить в COM+ приложении - а уж потом опубликовать как
Web-сервис.
Надеюсь что пример от MS (Sapmles\WebService) разобран "по косточкам".




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Friktus
Автор

Сообщений: 105
Откуда: Томск
Дата: 21.04.05 05:55:59
Здравствуйте, Игорь.
Спасибо за информацию насчёт Михаила Дроздова, попробую поискать там что-нить полезное. Вообщем-то основная моя проблемма - это много пробелов в теоретической области разработки и проектирования СУБД. Даже с самим SOAP протоколом я связался чтобы восполнить этот пробел "методом тыка", так сказать. Технология на мой взгляд очень многообещающая. Со временем всё большее и большее количество систем в качестве сети передачи данных используют интеренет, а для И-нета формат XML - идеальный вариант. Собственно с простыми приемами работы подобных приложений я разобрался и уже написал небольшой сервер и АРМ. (с написанием АРМа, кстати говоря, проблемм вообще не возникает, возможно только вся закавыка именно в способах общения с сервером, вот тут то и приходиться изобретать велосипед). Идеальным вариантом стало бы для меня написание АРМа, а в качестве СУБД использовать SQL-сервер, т.к. SQL сам взял бы на себя значительную часть работы за счёт использования триггеров и встроенных процедур. Вот как раз нечто подобное хотелось бы сделать и самому, НО, однако же в том же самом MSDN'е нет таких примеров и вообще информация по триггерам и их использованию весьма и весьма скудная. :-(
Ещё хотелось бы познакомиться с примерами использования классов при представлении данных. Например создать класс типа "документ" представляющий собой простейший документ: шапка и табличная часть. В дальнейшем имея такой опыт можно все данные представлять как классы, причём связь с необходимыми таблицами должен взять на себя именно класс, так чтобы меня это уже не волновало вообще (т.е. добавление записей, редактирование, удаление, индексы, связи и т.п. всё это при работе с опр. объектом меня волновать уже не должно, всё это должно быть реализовано на уровне класса этого объекта).
До кучи ещё желательно познакомится с опытом написания собственного XMLAdapter'a, потому что насколько я понимаю встроенный в VFP адаптер не сможет преобразовать для меня скажем объект представляющий из себя документ в XML. Пока что приходится всё делать гораздо проще - с помощью функции CURSORTOXML преобразовывать курсорчик в XML и добавлять некоторую служебную для сервера информацию в начало строки. Изврат канечно, но пока-что хватает и удовлетворяет поставленным целям. Да к тому же то что получается у меня это уже не совсем XML, а скорее просто строка + XML.
Ну а теперь немного подытожим чего мне хотелось бы получить в итоге при написании приложения: наиболее важным будет написать приложение полностью объектно-ориентированное, т.е. чтобы работать не с отдельными табличками и полями, а именно с объектами. Ксласс, для каждого объекта должен сам взять на себя функции хранения данных в таблицах, отображения информации для пользования в необходимом виде с помощью удобного GUI и скорее всего (поскольку работа с данными возложена на класс) общение с сервером (здесь то как раз и понадобиться навык представления объекта в формате XML).
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Igor Korolyov

Сообщений: 34023
Дата: 22.04.05 01:16:56
Hi Friktus!

Ну батенька, вам тогда в книжный магазин и начинать закупаться Фаулером,
Бучем и прочими его коллегами-"бандитами" - "Шаблоны проектирования",
"Объектно-ориентированный анализ и дизайн", "Разработка корпоративных
систем" и т.п. Названия я конечно жутко перевираю - сейчас нету книг под
рукой...
Я тут увы не помощник - шапочное знакомство с сими трудами не позволяет
что-то конкретное советовать...
Если интересует, то могу попробовать повыспрашивать точные названия книг, и
даже возможно ISBN - хотя думаю что просто пойдя на какой-нить Online
книжный магазин почитав аннотации уже можно чего-то подобрать...

P.S. IMHO МНОГОЕ в тех книгах не очень хорошо стыкуется с фоксом - грубо
говоря все "полностью объектные" построения исключают из работы мощнейший
фоксовый SQL движок - и в результате мы получаем "практически тот-же
Java/C++ код", только на порядок более медленный, более сложный в
сопровождении и в итоге - нецелесообразный.
Найти же компромисс весьма и весьма непросто... Так что крепко подумай
прежде чем решится на 100% объектную разработку.




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Friktus
Автор

Сообщений: 105
Откуда: Томск
Дата: 22.04.05 07:45:23
Да, согласен. В процессе тестирования такого подхода уже натолкнулся на множество касяков. Например: предположим я захочу с помощью классов представлять покупателей (customers) - задачка весьма простая. И формочки для отображения можно легко сделать, и работать удобней. Но, однако же как создать справочник покупателей? Допустим что класс такой создать не проблемма, и работать с ним в принципе можно. Но вот отображать... Фоксовские гриды заточены под таблички или массивы, а вот с объектами они не справятся. В итоге придётся писать конверторы и т.п. Вообщем этот подход мне не кажется таким уж хорошим. Как альтернативу можно было бы создать класс для работы с документом (шапка + табличная часть). Однако опять же если создавать справочник документов в виде класса, то придётся привязываться к табличкам, а не к ранее созданному классу "документ".
В итоге получается что использовать классы в Фоксе не выгодно, SQL движку они конкуренцию не составят. Возможно что применение классов где-то и необходимо, но писать полностью объектно ориентированное приложение не получиться. Значит будем работать по-старинке: таблички, связи, массивы... ;-) Кстати сказать: в MSDN'е входящим в VFP8 я нашёл только один документ по подобной тематике "Data Storage with Objects", и как видно из примера: проще подобный класс вообще не создавать (не только по удобству использования, но и даже по времени написания).
Однако есть ещё несколько вопросов касающихся написания приложения работающего в качестве сервера. Смысл затеи прост: есть сервер, который хранит данные. Доступ к нему осуществляется через SOAP протокол и IIS, данные передаются в формате XML. По сути дела вся (или почти вся) база имеется и на машине клиента (на АРМе). Сервак обеспечивает синхронизацию данных между несколькими клиентами. Таким образом при обращении к серверу клиентскому приложению не обязательно тащить все записи постоянно (засасывание всей базы будет происходить только при первом подключении), а нужно только лишь взять изменения. Соответственно объёмы данных передаваемые через сеть ничтожно малы!.
Для того чтобы клиентская программа знала какие данные нужно забирать в каждой табличке есть 3 поля RecDateNew, RecDateBegin, RecDateEnd типа DateTime. Ну допустим строить уникальный ключик можно используя пример из Samples. А вот заполнение указанных выше полей желательно было бы сделать исползуя триггеры, НО, почему это подобной инфы я не нашёл. В основном триггеры в примерах используют для проверки значений или для того чтобы чего-нить сделать в подчиненной\родительской табличке. Вообщем - как грамотно использовать триггеры мне чё-то совсем не понятно :-(
И ещё стоит проблеммка с XML'ем. Мне кажется что при использовании собственного XML-адаптера возможностей было бы гораздо больше. Например с теми же самыми документами: предположим пользователь создал новый документ, и нужно его отправить на сервак - самое простоя как я уже говорил переделать обе таблички в XML и потом склеить всё в одну строку добавив минимум служебной инфы, а на серваке соотв. разобрать всё это дело. Но есть достаточно неплохой пример другого подхода:
<claimToAgreement version="1.0">
<claimID value=""/>
<claimNumber value=""/>
<clmSenderID value=""/>
<clmSenderAddressID value=""/>
<clmSenderAddress value=""/>
<clmRegDate value=""/>
<clmOtpr>
<otprTypeID value=""/>
<otprRecipID value=""/>
<otprRecipOKPO value=""/>
<otprRecipName value=""/>
<otprStyk>
<stykStationCode value=""/>
</otprStyk>
<otprGraphPod>
<gpPodDate value=""/>
<gpWeight value=""/>
<gpCarCount value=""/>
</otprGraphPod>
</clmOtpr>
</claimToAgreement>
К сожалению примеров к использованию подобного подхода я не нашёл. :-(
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Igor Korolyov

Сообщений: 34023
Дата: 23.04.05 01:33:32
Hi Friktus!

Почитай всё-же классиков - например типовые решения "модуль таблицы" (Table
Module) и "Шлюз таблицы" (Table Gateway - он кстати очень сходен с идеей
CursorAdapter-а) вполне себе применимо и для фокса. Т.е. данные в курсоре, а
обработка - в классе... Это значительно лучше чем "размазывание" кода по
интерфейсному слою (т.е. по методам форм, контролам и т.п.) Конечно есть и
свои ограничения, и особенности. Мы сейчас тоже серьёзно анализируем эти
подходы.

Насчёт локального кэша - мне такие идеи не по душе - и так при работе в
распределённой среде высока вероятность конфликтов совместного доступа, а ты
её ещё увеличиваешь... Да и само по себе это (по сути это система
репликации) весьма и весьма непросто... В остальном конечно вопросов нет -
XML удобен и универсален, SOAP - хотя MS и забила на него большой болт - для
фокса вполне себе удобное решение...

Вложенный XML я бы делать не стал - есть у него кой какая убогость при
отображении в реляционную структуру - в реляционной базе связь оформляется
парой ключей - PK/FK - в "вложенном XML" эта же связь будет оформляться в
виде иерархии вложенности - и что гораздо более неприятно - для связей
много-к-одному (например поля из справочника) и тем более для ассоциаций
(связи типа много-ко-многим) вложенные конструкции IMHO весьма неудобны. Вот
просто вложить в один XML несколько таблиц - это да - это нормально - и
обратно в курсор вынуть можно элементарно, и аномалий описанных выше не
будет...




------------------
WBR, Igor
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Friktus
Автор

Сообщений: 105
Откуда: Томск
Дата: 27.04.05 04:42:36
Вспоминается фраза: "Учится, учится и ещё раз учится...". Придётся однако походить по книжным магазинам...
А вот насчёт XML-я и идеи покидать несколько табличек в один XML - на мой взгляд идея подходящая именно для Фокса, хотя... может и другим такой подход подошёл бы лучше нежели разбирать вложенные кострукции XML'я. Зато именно для Фокса - решение оптимально! Не нужно замарачиваться с и придумывать адаптеры всякие, всё делается всего парой функций ;-) Быстро и просто. А до кучи можно ещё и отсебятинки добавить, например условия различные для проверочки чтобы не было дублирования и т.п. Такая идея была у меня первоначальной. Теперь скорее всего на ней же и остановлюсь.
Насчёт локального кэша - изначально вариантов взаимодействия АРМ'а с сервером было много, но остановился именно на этом. Тащить постоянно (при каждом запуске программы) все записи с сервера не хотелось, потому как мне этот процесс представлялся весьма длительным особенно по мере роста объёмов хранимой информации. Ещё был вариант использовать различные фильтры, когда сервер возвращал бы данные порциями, в зависимости от фильтра. Но как то тоже не очень мне эта идея... В итоге остановился на кэшировании. Собственно трудности возникают именно при добавлении и изменении записей, а вот сам процесс обновления оказался весьма простым ;-) Для взаимодествия с сервером написал специальный класс - он должен взять на себя абсолютно все операции "общения" с сервером и насколько это возможно минимизировать предварительную подготовку данных (т.е. свести к минимуму код в методах форм и контролов) перед вызовом методов самого класса. Опять же повторюсь что очень порадовал механизм обновления записей на АРМе. Нужно вызвать один метод класса и в качестве параметров передать ему имя таблички (которую необходимо обновить), Логин и пароль (а после авторизации он естественно не меняется, хотя можно сделать и смену пользователей без закрытия программы). По имени таблички методы класса определяют её структуру и узнают когда было сделано последнее обновление. Потом на сервер посылается SQL запрос а ответом будет либо "EMPTY" либо курсор в XML'е. На основании полученного курсора производим обновление локального представления данных. При этом весь GUI можно писать предполагая что данные хранятся локально. Есть идея, кстати сказать, разбить АРМ на две части: первая будет запускаться и смотреть изменилась ли сама структура БД на сервере и есть ли новая версия самого АРМ'а, соответственно модифицировать локальную БД и закачивать обновлённую версию программы. Вторая - непосредственно сам АРМ. Своего рода online update. Весьма полезно в том случае, когда программа ещё не имеет законченного вида, но тот функционал который уже заложен делает целесообразным использование программы уже на данном этапе.
Теперь насчёт добавления и изменения: пока-что не получется придумать "уникальных" алгоритмов (т.е. чтобы 1 метод мог добавлять данные в любую таблицу на сервере), приходиться писать несколько различных вариантов. Хотя я думаю что осуществить подобное решение возможно.
Итак, при идеальном стечении обстоятельств у меня будет класс с 3-мя методами соответстующим 3-м событиям: удаление, добавление, изменение. (естественно что методов у класса будет больше, но пусть они будут использоваться самим классом, т.е. HIDDEN).
Ratings: 0 negative/0 positive

Re: Создание клиент-серверных приложений
Igor Korolyov

Сообщений: 34023
Дата: 28.04.05 15:25:32
Hi Friktus!

И всё-же ещё раз скажу - написание безотказной и помехозащищённой системы репликации (а именно это ты и делаешь по сути) - это весьма сложная и нетривиальная задача!
И кстати в этом случае твоё приложение нельзя будет назвать клиент-серверным. Их отличительная особенность - отсутствие локального хранения информации - а у тебя получается гибрид, со склонностью именно к Desktop приложению (ибо завтра у тебя возникнет вполне здравая идея - а не поработать ли мне с данными локально - сервер например временно недоступен - а изменения сбросить "потом") + система репликации данных.




------------------
WBR, Igor
Ratings: 0 negative/0 positive



Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 8 Crispy dimag  (Гостей: 6)

28.01.2021 11:16:01 exec: 0.03
Mem: 1.228 Mb

© 2000-2021 Fox Club 
Яндекс.Метрика