Наши преимущества

Технология DataSnap

Статус
Закрыто для дальнейших ответов.
S

sunzh

Турист
Credits
0
Заманчиво спроектировать распределенную инф. систему построенную полностью на инструментарии Windows. Т .е . без установки стороннего ПО.

Рассматриваю такую связку (Delphi):
На сервере: ADOconnection к локальному набору данных, datasetprovider.
Клиент: DCOMconnection, clientdatasource. компоненты отображения данных.
С использованием модели BriefCase. Вобщем технология DataSnap в чистом виде.
Плюсом ко всему на стороне клиенты планируется реализовать связь с ГИС (геоинформационной системой)

Есть-ли у кого-то опыт подобной реализации?

з.ы. В разрезе использования в малой локальной сети.
 
Последнее редактирование модератором:
Многа умных букаф. А если серьёзно - задлянафига? Зачем BriefCase в распределённой системе? БД+репликация не вариант?
 
BriefCase для сессионной работы с данными. BriefCase - это не только portable наборы данных.

К вопросу - почему некоторыена этом форуме интересуются легкими, желательно бесплатными реляционнми СУБД для работы в малой локальной сети?

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

Преимущества Data Snap (ИМХО) - "все включено" в ОС и логику приложения, пусть она медленее чем ФБ к примеру, но использование BriefCase позволяет снизить нагрузку на сеть, т. к. работа идет с локальным набором данных в течение сеанса.

Задача - создать распределенную ИС на 2-10 рабочих станций с упомянутыми выше условиями.
 
Последнее редактирование модератором:
Что касается клиента: FB Embedded в помощь. Локальное хранилище и не требуется администрирование. Возможности настоящей СУБД никогда не лишние :)
 
Что касается клиента: FB Embedded в помощь. Локальное хранилище и не требуется администрирование. Возможности настоящей СУБД никогда не лишние
Нажмите, чтобы раскрыть...

Спасибо за совет.
Но все же тема создана про DataSnap.

Давайте обсудим такую реализацию.

Приложение-сервер через ADO компонеты (например ADOquery и ADOCommand) связывается с локальным (для сервера) набором данных посредством SQL-запросов, т. е. сервер общается с локальной БД как с с SQL сервером. Связывание таблиц и запросов тоже происходит через SQL. (запросы типа: Select * from mastertable, detailtable where mastertable.id=detailtable.master_id)

На стороне клиента ClientDataSource'ы получают эти данные через DCOMConnection.
Это вроде как и не файл-серверная ИС, но и не полноценная распределенная трехуровневая ИС типа Клиент-Сервер. Тем не менее клиенты получают только запршенную информация. т. е. ИС функционирует как Клиент-Сервер.

Хотя бы просто теоретически - насколько это эффективно и быстро?

Обязательно-ли (с точки зрения эффективности) на сервере использовать query- компоненты и SQL-связывание, или можно использовать обычные компоненты доступа и определить связи между таблицами через object inspector? Как правильно настроить при этом компоненты?
Возможно-ли подключиться к данным через ODBC, без использования BDE (BDE позволяет использовать драйверы ODBC)?
Это опять же к теме построения ИС средствами Windows.

З. Ы. Извините если вопросы тупые. Я не профи, только начинаю.
 
Последнее редактирование модератором:
Проштудировал тему
Да для малых сетей Data Snap - неплохой вариант.
Схема такая:
На сервере реляционный доступ к локальному набору данных (Access - ADO) +бизнес правила+методы COM-интерфейсов для расширения функциональности+callback's как механизм событий сервера.
На клиенте - clientdataset'ы и компоненты отображения.
Плюсы:
Никакого стороннего ПО (кроме своего)
Возможность использования BriefCase
Приступаю к реализации, модель БД почти готова.
 
База данных это только 1/3 дела, нужно сделать клиента и сервер.
 
Начиная с Delphi 2010 нет никаких проблем с созданием клиента и сервера, на клиенте размещаем компоненты dbExpress у которого провайдером БД служит DataSnap, а сервер строим как DataSnap сервер и тоже не имеем никаких проблем за исключением маршалинга собственных объектов, но и это решаемая проблема
 
Позвольте мне высказаться. Если все равно планируете гонять по сети датасеты, нафига вообще уровень сервера приложений делать. Лишнее звено (передаст) - это тормоз будет и по коду будет работы больше. Это заманчиво и красиво вначале а потом, с ростом объема запрашиваемых данных... (а в ГИС так и будет)
 
ИМХО: согласен с test1c, трех звенка в современном мире интересна только когда до основного сервера не быстрый канал связи.
 
Статус
Закрыто для дальнейших ответов.
Верх