Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

3-х звенная архитектура

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Рассматривается проект с применением 3-х звенки.
Есть СУБД, сервер приложений, само клиентское приложение.
Вопросы с организацией связи между сервером и клиентом:
1. Протокол передачи данных на основе XML. Т.е. сервер формирует некую выборку данных в XML-ном виде, потом эти данные сжимаются и передает на клиента. Клиент в таком же виде передает данные на сервер, плюс в виде XML передает на сервер имена вызываемых процедур/функций (не SQL) с типом, количеством и значениями параметров.
Вопрос: насколько оптимальна такая схема обмена данными? Если какие либо схемы попроще, понадежней и т.п.?
2. Прием и отображение табличных данных на клиенте.
Тут 2 варианта:
а) полностью вся работа с данными идет на сервере, а клиент только получает таблицы (в виде XML) и отображает их
Достоинства:
- вся логика сосредоточена в одном месте
Недостатки:
- большой трафик
- придется писать свою модель отображения данных, при этом заморачиваться с кешированием (что бы запрашивать с сервера только видимую для пользователя часть данных и хранить в кеше 1-2 страницы для ускорения отображения)
б) На клиенте предусмотреть свою локальную БД (акцесс, sqlite), которая будет синхронизироваться с сервером. При этом для каждой сущности кроме ее ID вводить время изменения. Сервер же хранит и выдает данные по запросу, в зависимости от времени изменения.
Достоинства:
- небольшой траффик
- возможность локально работать (при подключении к серверу синхронизировать данные)
- не надо ничего писать своего, для отображения данных (подойдут стандартные объекты)
Недостатки:
- придется писать 2 логики работы с данными (на сервере и на клиенте)
- довольно сложный процесс синхронизации.

Кто разрабатывал подобные системы, поделитесь соображениями.
277
05 июля 2011 года
arrjj
1.7K / / 26.01.2011
Цитата: oxotnik333

а) полностью вся работа с данными идет на сервере, а клиент только получает таблицы (в виде XML) и отображает их
Достоинства:
- вся логика сосредоточена в одном месте


Оправдан ли такой способ в плане производительности серверной части?

Цитата: oxotnik333

Недостатки:
- большой трафик


сами себе противоречите

Цитата: oxotnik333

....потом эти данные сжимаются....


Так что не думаю что трафик будет больше обычного sql-трафика

Цитата: oxotnik333

- придется писать свою модель отображения данных, при этом заморачиваться с кешированием (что бы запрашивать с сервера только видимую для пользователя часть данных и хранить в кеше 1-2 страницы для ускорения отображения)


В написании своей модели отображения данных думаю нет проблемы, а вот с кэшированием...впринципе запрос 1-й страницы данных с сервера не так затратен в плане производительности как запрос всего, но... Если мы всю выборку будем хранить на сервере это вызовет лишнюю и неоправданную жратву оперативы на серваке. Если мы будем на сервере для нового кэша делать новую выборку то страницы могут просто не сойтись и пользователь "потеряет" строки.

Цитата: oxotnik333

б) На клиенте предусмотреть свою локальную БД (акцесс, sqlite), которая будет синхронизироваться с сервером. При этом для каждой сущности кроме ее ID вводить время изменения. Сервер же хранит и выдает данные по запросу, в зависимости от времени изменения.
Достоинства:
- небольшой траффик


Не думаю что это оправдано, всё равно кэш обновлять столько же трафика как и простые запросы +дополнительный расход системных ресурсов на синхронизацию

Цитата: oxotnik333

- возможность локально работать (при подключении к серверу синхронизировать данные)


Данные могут потерять свою актуальность задолго до синхронизации, не думаю что хорошая идея.

Цитата: oxotnik333

- не надо ничего писать своего, для отображения данных (подойдут стандартные объекты)


Это не такуй уж и плюс, по сравнению с разработкой системы безотказной синхронизации.

Цитата: oxotnik333

Недостатки:
- придется писать 2 логики работы с данными (на сервере и на клиенте)


Ctrl+C Ctrl+V

Цитата: oxotnik333

- довольно сложный процесс синхронизации.


полностью согласен + как решать спорные вопросы (например один пользователь в офлайне изменил данные по клиенту, а другой пользователь удалил этого клиента - чей кэш прав)?

1
05 июля 2011 года
kot_
7.3K / / 20.01.2000
у меня в подобной схеме использовалась локальная БД для клиента. Это позволило гибко обеспечивать работу клиента вне зависимости от качества канала. Синхронизация в этом случае не привязывалась ко времени (ИМХО завязываться на время вообще большая ошибка) - она привязывалась к статусу записи.
11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: arrjj
Оправдан ли такой способ в плане производительности серверной части?


Клиентов не так уж и много будет, и они не будут постоянно в онлайне сидеть

Цитата: arrjj
сами себе противоречите
Так что не думаю что трафик будет больше обычного sql-трафика


При способе "б" траффик все же меньше получается

Цитата: arrjj
В написании своей модели отображения данных думаю нет проблемы, а вот с кэшированием...впринципе запрос 1-й страницы данных с сервера не так затратен в плане производительности как запрос всего, но... Если мы всю выборку будем хранить на сервере это вызовет лишнюю и неоправданную жратву оперативы на серваке. Если мы будем на сервере для нового кэша делать новую выборку то страницы могут просто не сойтись и пользователь "потеряет" строки.


Вот как раз есть проблемы, как постранично тащить данные, в какой момент данные запрашивать и т.д. Пока не представляю как это можно реализовать...

Цитата: arrjj
Не думаю что это оправдано, всё равно кэш обновлять столько же трафика как и простые запросы +дополнительный расход системных ресурсов на синхронизацию


Алгоритм тут примерно следующий: у сервера запрашивается его текущее время, и от этого времени пляшем, т.е. с клиента уходят данные на сервер только те, которые были изменены (в раеле это несколько записей БД получается), с сервера на клиента несколько десятков строк (данных других клиентов), против п. "а", когда надо тянуть все абсолютно (постранично, но все рано тянуть)

Цитата: arrjj
Данные могут потерять свою актуальность задолго до синхронизации, не думаю что хорошая идея.


Каким образом? Данные напрямую удаляться не будут, будет выставляться только признак возможности отображения.

Цитата: arrjj
Это не такуй уж и плюс, по сравнению с разработкой системы безотказной синхронизации.


Ну как сказать... если учесть большой гимор и недопонимание как отображать в реальном времени данные с сервера, то скорее большой плюс

Цитата: arrjj
Ctrl+C Ctrl+V


Немного сложнее будет, но унифицировать объекты по работе с данными можно будет.

Цитата: arrjj
полностью согласен + как решать спорные вопросы (например один пользователь в офлайне изменил данные по клиенту, а другой пользователь удалил этого клиента - чей кэш прав)?

по последней дате изменения - кто последний, тот и папа

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: kot_
у меня в подобной схеме использовалась локальная БД для клиента. Это позволило гибко обеспечивать работу клиента вне зависимости от качества канала. Синхронизация в этом случае не привязывалась ко времени (ИМХО завязываться на время вообще большая ошибка) - она привязывалась к статусу записи.


К времени сервера привязка. Т.о. исключаем расхождение во времени между 2-мя компами, часовые пояса и т.п.
А что значит статус записи?

341
05 июля 2011 года
Der Meister
874 / / 21.12.2007
имхо репликация - всегда геморрой и без острой нужды использовать её не нужно.
почему не хочешь заюзать любой промышленный ремоутинг?
11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Der Meister
почему не хочешь заюзать любой промышленный ремоутинг?


Если бы я знал что это, то наверно поддался на уговоры...

1
05 июля 2011 года
kot_
7.3K / / 20.01.2000
Цитата: oxotnik333
К времени сервера привязка. Т.о. исключаем расхождение во времени между 2-мя компами, часовые пояса и т.п.
А что значит статус записи?


При наличии локальной БД привязка ко времени сервера - большой гемор. Даже без локальной - тоже самое. Уж поверь. Любая завязка "на время" отымеет тебе мозги так что мало не покажется.
Статус записи - текущее состояние объекта. Например если запись отправлена на сервер - локальный оператор не может ее модифицировать. И т.д. Справочник состояний так же храниться на локальной БД и может быть синхронизирован - что позволяет гибко менять логику поведения огромной сети машин без вояжа по стране.

341
05 июля 2011 года
Der Meister
874 / / 21.12.2007
Цитата: oxotnik333
Если бы я знал что это, то наверно поддался на уговоры...

wcf, json.net, rmi и т. д.

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Der Meister
wcf, json.net, rmi и т. д.



Другими словами серелизация объектов?
ЗЫ: скорей всего в Qt будет делаться, посему "ремоутинг" несколько не применимо будет

277
05 июля 2011 года
arrjj
1.7K / / 26.01.2011
[QUOTE=oxotnik333]
Клиентов не так уж и много будет
[/quote]
Тогда и проблема трафика и проблема производительности серверной части уходят на второй план.
[QUOTE=oxotnik333]
К времени сервера привязка
[/quote]
<<А если у пользователя севшая батарейка на биосе? :) М.б. идея kot_ статусы для записей (отредактирована/добавлена и т.д.) лучше (клиент->сервер)? Но как быть с синхронизацией в другую сторону сервер->клиент?

Ну и создание начального кэша тоже добавляет вопрос. Впринципе если пользователи в офлайне только добавляют записи и всё, то это не проблема, а если он захочет отредактировать запись, которой нет в кэше?

З.Ы. на QtScript можно сделать очень гибкую и функциональную систему;)
11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: arrjj
Тогда и проблема трафика и проблема производительности серверной части уходят на второй план.


Проблема трафика исключетельно в интересах клиентов (многие через жопорез сидят)

Цитата: arrjj

<<А если у пользователя севшая батарейка на биосе? :) М.б. идея kot_ статусы для записей (отредактирована/добавлена и т.д.) лучше (клиент->сервер)? Но как быть с синхронизацией в другую сторону сервер->клиент?

Ты не понял насчет серверного времени: сервер выдает свое время, и для программы клиента это будет являться ее внутренним временем, т.е. ко времени машины клиента само приложение обращаться не будет.

Цитата: arrjj

Ну и создание начального кэша тоже добавляет вопрос. Впринципе если пользователи в офлайне только добавляют записи и всё, то это не проблема, а если он захочет отредактировать запись, которой нет в кэше?

Если ее нет, то и редактировать нечего будет. Сначала обновляемся с сервера, потом редактируем что получили. Если нет соединения с сервером, сиди соси палец.

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: kot_
При наличии локальной БД привязка ко времени сервера - большой гемор. Даже без локальной - тоже самое. Уж поверь. Любая завязка "на время" отымеет тебе мозги так что мало не покажется.
Статус записи - текущее состояние объекта. Например если запись отправлена на сервер - локальный оператор не может ее модифицировать. И т.д. Справочник состояний так же храниться на локальной БД и может быть синхронизирован - что позволяет гибко менять логику поведения огромной сети машин без вояжа по стране.


Извини за тупость, но чет я плохо понимаю принцип действия.
Какой нибудь жизненный пример можешь привести?

277
05 июля 2011 года
arrjj
1.7K / / 26.01.2011
Цитата: oxotnik333
Проблема трафика исключетельно в интересах клиентов (многие через жопорез сидят)


Выдать всем по 3Г модемчику?))

Цитата: oxotnik333

Ты не понял насчет серверного времени: сервер выдает свое время, и для программы клиента это будет являться ее внутренним временем, т.е. ко времени машины клиента само приложение обращаться не будет.


Да понял я всё вот и говорю если нет соединения с сервером то как отслеживать новые/изменённые записи, какое время брать за стартовое? Выход - в кэше хранить статусы записей.

Цитата: oxotnik333

Если ее нет, то и редактировать нечего будет. Сначала обновляемся с сервера, потом редактируем что получили. Если нет соединения с сервером, сиди соси палец.


В этом случае вся идея офлайн работы встаёт под вопрос. Или каждый раз кэшировать(обновлять/синхронизировать) все данные необходимые для офлайн работы.

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: arrjj
Да понял я всё вот и говорю если нет соединения с сервером то как отслеживать новые/изменённые записи, какое время брать за стартовое? Выход - в кэше хранить статусы записей.

В этом случае вся идея офлайн работы встаёт под вопрос. Или каждый раз кэшировать(обновлять/синхронизировать) все данные необходимые для офлайн работы.


Это вопрос...
С другой стороны можно поставить для измененных в оффлайне записей время большее (не важно какое) чем последнее время, полученное с сервера, тогда ври онлайне, клиент отправляет данные, измененные в последенй оффлайн сессии, а сервер их у себя раскладывает уже со своим временем, ну и на клиента это время попадает и он запоминает его. Если с нескольких клиентов данные одинаковые меняются, то сохраняются те, кто последний подцепился к серверу. Как то так...

87
05 июля 2011 года
Kogrom
2.7K / / 02.02.2008
oxotnik333, я правильно понимаю, что твоему ТЗ соответствуют как системы управления версиями, типа SVN или Mercurial, так и социальные сети? Но ведь для каждого случая будет оптимален свой подход. Возможно, надо конкретизировать ТЗ.
11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
oxotnik333, я правильно понимаю, что твоему ТЗ соответствуют как системы управления версиями, типа SVN или Mercurial, так и социальные сети? Но ведь для каждого случая будет оптимален свой подход. Возможно, надо конкретизировать ТЗ.


Это система для автоматизации бизнесс-процессов в конторе. Что то среднее между 1С и документооборотом.

1
05 июля 2011 года
kot_
7.3K / / 20.01.2000
Цитата: oxotnik333
Извини за тупость, но чет я плохо понимаю принцип действия.
Какой нибудь жизненный пример можешь привести?



Ну на пример. У меня обмен должен идти в обе стороны - с клиента на сервер, с сервера на клиент. Работа идет в пакетном режиме. Под пакетом понимается XML-файл определенной струкуры. Пакеты бывают нескольких типов - грубо говоря пакет с данными и пакет синхронизации. Пакет с данными модифицирует данные, пакет синхронизации - только меняет статусы. Система оперирует сущностями - типа клиента, документа, платежа и т.д. Каждая сущность подчиняется какому то набору правил - например документ может быть создан - его статус 0. Документ подготовлен к отправке - его статус -1. Документ отправлен на сервер - его статус - 2. Документ принят сервером - его статус 3 и так далее. В каждом статусе есть набор действий-переходов - например со статуса 0 документ может получить статус либо 1, либо 7 (удален оператором), либо 8 (требует корректировки на сервере), либо ... либо.
Со статусом 2 документ может получить только статус 3. И так далее. Соответственно есть набор операций (создать, открыть, редактировать, печатать и пр.)и для каждого статуса этот набор ставится в соответствие. Битовые маски и прочая фигня. Идея я надеюсь понятна?

1
05 июля 2011 года
kot_
7.3K / / 20.01.2000
Цитата: oxotnik333

Ты не понял насчет серверного времени:


"не советую - съедят" (с)Стругатские.
Кстати описанная мной система легко работает на любом типе сети начиная с флешконет заканчивая оптоволокном.

87
05 июля 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
Это система для автоматизации бизнесс-процессов в конторе. Что то среднее между 1С и документооборотом.



То есть что-то типа такого:

http://v8.1c.ru/doc8/

Так? Если оно, то проще рассуждать, да и есть с чего "сплагиатить"...

11
05 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
То есть что-то типа такого:

http://v8.1c.ru/doc8/

Так? Если оно, то проще рассуждать, да и есть с чего "сплагиатить"...


Если ты еще не понял, то меня интересуют технические детали организации и передачи данных, от одинэс этого никак не получишь, ибо закрытый код. Саму 1С использовать моветон, ибо тогда все превращается в банальную поддержку этого продукта и много на этом не поднимешь, и ко всему этому при распределенных офисах настраивать все это взаимодействие большой геморой и работа больше для админа. Единственное что можно оттуда почерпнуть это интерфейс пользователя, но этот вопрос больше на заказчике лежит.

11
06 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Выяснил тут, что в Qt есть некоторые вкусные фишки в MVC, которые позволят обойтись без локальной БД и соответсвенно без синхронизаций ее с серверной. И можно будет тягать только отображаемые данные.
В общем пока буду прорабатывать вариант 2.а.
Остается открытым вопрос по актуальности протокола обмена данными через XML структуру... возможно в Qt найдутся объекты, которые после некоторого допила можно будет приспособить напрямую, без XML прокладки.
87
06 июля 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
Если ты еще не понял, то меня интересуют технические детали организации и передачи данных, от одинэс этого никак не получишь, ибо закрытый код.



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

Про закрытый код:
http://www.opennet.ru/prog/sml/55.shtml

Цитата: oxotnik333
Саму 1С использовать моветон, ибо тогда все превращается в банальную поддержку этого продукта и много на этом не поднимешь, и ко всему этому при распределенных офисах настраивать все это взаимодействие большой геморой и работа больше для админа.



Я понимаю ход твоих мыслей, потому и не советую использовать 1С.

11
06 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Технические детали могут различаться в зависимости от типа программы.


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

87
06 июля 2011 года
Kogrom
2.7K / / 02.02.2008
Цитата: oxotnik333
Технические детали то как раз боле менее универсальные в подобной архитектуре. Тем более что на эту архитектуру можно потом насадить любую логику.



Странный ты человек. Попросил выбрать из двух вариантов, а потом потом рассуждаешь об универсальности технических деталей. Например, если упростить детали, то Вконтакте использует вариант 2а, а Mercurial - вариант 2б. И оба используют правильный способ.

11
06 июля 2011 года
oxotnik333
2.9K / / 03.08.2007
Цитата: Kogrom
Странный ты человек. Попросил выбрать из двух вариантов, а потом потом рассуждаешь об универсальности технических деталей. Например, если упростить детали, то Вконтакте использует вариант 2а, а Mercurial - вариант 2б. И оба используют правильный способ.


Оба варианта имеют право на существование, и в конечном итоге выполнят свою цель, вне привязки к логике бизнес-процесса. Т.е. для них обоих бизнес-модель может быть любая, оба варианта являются "универсальным" механизмом по работе с данными.
А вот реализацией они различаются. Я хотел узнать плюсы и минусы каждой реализации ну и пути решения.
Еще попутно хотел узнать другие "универсальные" варианты по передачи/синхронизации данных.
Бизнес-логику сейчсас рассматривать бессмысленно, т.к. ее еще надо из заказчика выудить, а пока я не в курсе что там конкретно будет, но на пердасу данных это никак не влияет.
ЗЫ: это примерно тоже самое что и платформа 1С, в которой можно написать бухгалтерию или кадры или документооборот. Логика разная, а ядро постоянно.

87
06 июля 2011 года
Kogrom
2.7K / / 02.02.2008
Выскажу некоторое предложение. Возможно, близка к теме будет книга Мартина Фаулера "Шаблоны корпоративных приложений". Но тут нужно одобрение более близких к этой теме товарищей.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог