MIDAS

← →
Alex_Sudakov © (2002-11-29 11:50) [0]

Господа, раскажите (или посоветуйте, где почитать), в чем преимущество использования серверов приложений? А то пока не ясно, стоит его писать или нет (кроме бизнес-логики). Не понятно, в чем преимущество использования RemoteDataModule перед прямым соединением с сервером БД. Растолкуйте, а то не сталкивался никогда...:)

← →
Alexandr © (2002-11-29 11:55) [1]

1) Бизнес-логика в одном месте
2) Свой механизм секурности
3) Устойчивать к обрывам связи
4) Уменьшение траффика
5) Меньше требования к клиентским компам
и много чего еще...

← →
Romkin © (2002-11-29 11:58) [2]

в RSDN #2 ;-P
Кратко -
Возникает разделение кода - сервер приложений работает с базой данных, и на нем лежит ответственность за сохранение целостности данных и синхронизацию работы пользователей. На клиентской части остаются средства представления данных пользователю и контроль ввода данных.
При разработке приложения можно сначала создать модули сервера приложений, провести тесты на работоспособность, и только потом написать клиентскую часть. При этом как бы ни был написан клиент, можно быть уверенным, что в базу данных будет записана правильная информация. Это дает также то преимущество, что при написании новых блоков приложения логика работы с БД будет опробована до написания значительной части самого приложения.

Независимость от конкретной СУБД. Действительно, на рабочих станциях не нужно устанавливать клиентскую часть сервера баз данных, соединение с сервером приложений обеспечивается одной библиотекой midas.dll. Клиентскую часть в этом случае значительно проще устанавливать на рабочие станции, требуется практически только она, без дополнительных библиотек доступа к серверу БД. Это также позволяет повысить защищенность приложения, поскольку на рабочих станциях отсутствует прямой доступ к серверу БД.
При переходе на другой сервер БД достаточно переписать только сервер приложений, не затрагивая клиентскую часть. Необходимо также учитывать, что при групповой разработке приложений обычно часть программистов специализируется на базе данных, другая часть - на интерфейсе пользователя. При этом каждая группа программистов может работать над своей частью приложения, не отвлекаясь на особенности работы другой группы.
Значительно упрощается синхронизация работы пользователей, которую теперь обеспечивает сервер приложений, при этом независимо от имеющихся средств сервера БД. Также становится возможным перенести остальные особенности работы приложения на сервер приложений, что довольно часто приводит к ускорению разработки.
Транзакции в базе данных, контролируемые сервером приложений, максимально короткие по длительности, что в некоторых случая значительно

Резко уменьшается поток данных между клиентским приложением и серверной частью. Дело в том, что иногда приходится при расчетах обращаться к дополнительным справочникам в БД, которые в данном случае можно обрабатывать прямо на сервере. Кроме этого, пакеты данных MIDAS, как правило, значительно компактнее данных, поступающих с сервера БД, что позволяет клиентской части соединяться с сервером приложений, допустим, по модемной связи без особого замедления скорости работы.
Поскольку основная обработка данных происходит на сервере приложений, который обычно устанавливается на наиболее мощном компьютере, клиентская часть требует значительно меньше ресурсов на рабочих станциях.

← →
BorisUK © (2002-11-29 12:00) [3]

Alexandr ©
Поясни пож.
<<3) Устойчивать к обрывам связи
Это ты что имеешь в виду :)

У меня проблем - если соединение разорвано - опять востановленно,
а выбора данных за это время небыло. Ну клиент просто висел и невига не делал, то потом любой запрос возвращяет ошибки...
Приходится делать переконект.
Так что - объяснись :)

← →
Alexandr © (2002-11-29 12:05) [4]

вот. а трехзвенка от этого спасет. Твои данные будут безбедно продолжать жить на сервере. А связь хоть через 5 минут обрываться.

← →
Romkin © (2002-11-29 12:11) [5]

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

← →
Noname_ (2002-11-29 12:20) [6]

2Alexandr:
А если оборвется связь между сервером приложений и сервером БД? (Тем более, что рекомендуется держать их на разных машинах из соображения производительности.)

2Alex_Sudakov:
Не слушай чепухи о бизнес-логике, секурности и т.д. Единственный плюс сервера приложений - уменьшение количества сессий на сервере БД при большом количестве работающих с БД. Но компенсируется это гораздо большей сложностью разработки и возможными проблемами производительности сервера приложений. Тем более, что любой современный офисный комп, в котором установлен Celeron 1GHz (меньше не бывает), вытянет самого толстого клиента. Если с твоей базой не будут работать одновременно несколько сотен юзеров, забудь о трехзвенных приложениях, как о страшном сне.

← →
Alexandr © (2002-11-29 12:24) [7]

сон действительно страшный.
Но если его реализовать на хорошем уровне (а трехзвенка это не обязательно MIDAS), то успех будет гарантирован.

← →
BorisUK © (2002-11-29 12:26) [8]

Какое закрытие соединения вы имеете в виду?
Connected:=false?
В этом случае данные разве сохранятся?
Я знаю как строится brifcase модель, но для этого необходим писать некоторое количество кода...
Само то оно не сохраняется.
А я говорю про то что при разрыве соединения инициированого не сервером или клиентом , а например, сетка отвалилась или модем...
То клиент не знает об этом пока не попробует затребовать новые данные.
И вот тут то, есл вы делаете коннект с проверкой прав все обламывается...
просто connected:=true не поможет.
Приходится переконекчиваться заново... Но это мелочи :)

← →
Alexandr © (2002-11-29 12:31) [9]

трехзвенка трехзвенке рознь.

← →
Romkin © (2002-11-29 13:00) [10]

2BorisUK Сохраняются данные, куда они денутся? Сам попробуй: открой ClientDataSet и отсоединись от сервера - все работает, когда захочешь закачать данные/изменения будет автоматическая попытка установить коннект с сервером - ну а тут уж смотри, у меня при соединении по модему (удаленный вход) выводится окно дозвона, дозваниваешься - и вперед. А вот если рвется соединение по локальной сети рекомендую прибить админа ящиком пива, все равно он не нужен, что это за сеть, в которой регулярно соединение пропадает?!

← →
stone © (2002-11-29 13:13) [11]

2 Alex_Sudakov © (29.11.02 11:50)

Суть трехзвенки состоит в реализации информационных систем выходящих за пределы локальной сети, либо очень большой локальной сети. Один из основных плюсов - снижение стоимости парка компьютеров в целом. Для клиента не надо покупать мощный компьютер, да и серверов может быть несколько, а, соответственно, с ролью сервера в принципе может справлять достаточно мощный компьютер с архитектурой рабочей станции (я имею в виду 1 процессор, без RAID-массивов и т.д.). Все это в целом ведет к значительному снижению стоимости внедрения проекта.
А если у тебя небольшая БД (2-3 млн. записей) и всего пару десятков пользователей, а сама программа крутится в пределах одного офиса, то городить трехзвенку смысла нет.

Да я соглсен с тобой Romkin :)
Можно работать с локальными данными, а при вызове AplayUpdates
он сам пытается востановить соединение.
Но попробуй убери все из настроек компонента соединения с базой на сервере приложений на этапе разработки
(Подсовываем их динамически в режиме диалога - Логин и пароль к СУБД) и твоя программа обломается, так как будет пытаться законектится по пустым параметрам! Разве что работать с DBF там это не надо , но это я не обсуждаю!
У меня просто ситуация еще сложнее....
При разрыве соединения (даже временном - выткнул сеть и воткнул)
теряется сесия и следовательно установленное рабочее место и права на выполнение многих операций.
Пришлось сделать процедуру невидимого переконекта по старым параметрам...
Хотя, казалосьбы канал пропал и снова появился..
Однако знать бы почему эта сволоч не может найти куда она только что данные передовала.
Вот так то.
А вообще Romkin где такие медальки, как у тебя, берут?
Я тоже хочу :)

Да кстати про Админа - с сетью все в порядке это я сам её терроризирую .. Так сказать в экстремальных условиях гоняю :)

Извращенец ^-))
Соединение пропадает, потому что DB handle, ессно, уже другой нужен. А так в любом случае, если хочешь спастись от разрыва, приходится сохранять все параметры соединения на клиенте, другого никогда не будет

Спасибо за столь полный ответ...:) Буду думать...:)

MIDAS Найти похожие ветки