Как строить приложения с Rich/Smart клиентом?

6yrop

Может кто подскажет интересные ссылки по это теме?
Платформы Java, .NET
Интересует механизм обмена данными между клиентом-сервером-базой данных.

redzor

есть фреймворк hippopotam. Лежит на sourseforge. Мы с помощью него делали десктоп приложение с богатым гуем (джава). Там его описание есть. Попробуй. Документация там тоже есть

olga1969

Ну можно вообще через сокеты все гонять
А вообще - в механизме обмена данными столько всяких деталей, что...
Что Танненбаум про это написал огромную книгу "Распределенные системы" или что-то в этом роде...

6yrop

А вообще - в механизме обмена данными столько всяких деталей, что...

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

olga1969

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

Веселый парень...
Ну, вот например (неполный, я так думаю) список механизмов взаимодействия для Java-платформы:
-Sockets
-RMI
-EJB
-Servlets/JSP
-JMS
-типа SOAP
-и еще куча разных lightweight frameworks (hippopotam возможно один из них, лень проверять)
Выбор конкретного механизма зависит от типа приложения (мда, банально как-то получилось...)
Каждый из этих механизмов пытает помочь программисту бороться с "большим количеством деталей" в той или иной степени

6yrop

Ну, вот например (неполный, я так думаю) список механизмов взаимодействия для Java-платформы:
-Sockets
-RMI
-EJB
-Servlets/JSP
-JMS
-типа SOAP
-и еще куча разных lightweight frameworks (hippopotam возможно один из них, лень проверять)

ну что ж судьба у джавы такая, куча всякого барахла , а если серьезно, то все что ты назвал, кроме EJB, спецификации для ниижних уровней, меня же интересует как бизнес-данные будут передаваться между машинами: какими порциями и по каким событиям.

olga1969

ну что ж судьба у джавы такая, куча всякого барахла

А что в этом плохого? Что нравится, то и бери.

все что ты назвал, кроме EJB, спецификации для ниижних уровней

Ну... Я бы все RMI и Servlets не относил к нижним уровням. Хотя они конечно ниже, чем EJB
К слову, в классы/объекты, моделирующие бизнес-данные, передаются в RMI по сути так же, как и в EJB.
Конечно, сокеты - это очень низкий уровень. Загонять все в байты и стринги и гонять по сети, а потом восстанавливать из этого объекты - дело долгое. (Но кстати на простых данных работает нормально.)
Поэтому и придумали удаленные вызовы процедур и удаленные вызовы методов - чтобы вызов объекта, живущего в удаленной ява-машине выглядел как вызов локального объекта. И чтоб данные передавались между удаленными объектами, как между локальными. Эта базовая функциональность есть в RMI.

меня же интересует как бизнес-данные будут передаваться между машинами: какими порциями и по каким событиям

Хм... ) Что значит какими порциями и по каким событиям? Как определишь удаленные методы, так и будет. Хочешь, целые объкты гоняй, хочешь кучу объктов в массиве. А события - ну, наверно это с действиями пользователя должно быть связано. Или ты другие события имеешь ввиду? Может, ты имеешь ввиду синхронный/асинхронный вызовы?

6yrop

А события - ну, наверно это с действиями пользователя должно быть связано. Или ты другие события имеешь ввиду?

вот вот, логично предположить, что обращение к серверу/базе инициируется непосредственно пользователем. Но есть такой патерн, как lazy load, в нем загрузка инициируется не непосредственно пользователем, а обращением объектов приложения к свойству объекта. Имхо, для пользователя это несколько неожиданно...

olga1969

вот вот, логично предположить, что обращение к серверу/базе инициируется непосредственно пользователем. Но есть такой патерн, как lazy load, в нем загрузка инициируется не непосредственно пользователем, а обращением объектов приложения к свойству объекта. Имхо, для пользователя это несколько неожиданно...

Ну, вообще говоря, пользователь ничего о lazy load знать не должен - это дело программера, он должен скрыть от пользователя все технические детали. Вообще-то, и для программера это очень обременительно - самому реализовывать множество технических деталей. Это скорее всего похоронит весь проект, если он большой. Чтобы освободить программиста от подобных важных нудностей и появились технологии типа EJB. Но разные фреймворки предоставляют естественно разные возможности. Если у вас проект, в котором нету миллиона бизнес-объктов, то и lazy load уже становится ненужным, можно все сразу в память загрузить.

6yrop

Ну, вообще говоря, пользователь ничего о lazy load знать не должен - это дело программера, он должен скрыть от пользователя все технические детали.

а это не технические детали, когда пользователь делает запрос данных, то он понимает, что это обращение к удаленной машине через Интернет и готов подождать 1-2 секунду (так же как ты пользуешься форумом). А вот когда приложение само вдруг полезло на сервер, потому что в коде стоит обращение к свойству и это обращение происходит первый раз, вот это с точки зрения пользователя странно.

olga1969

...когда пользователь делает запрос данных, то он понимает, что это обращение к удаленной машине через Интернет

Ой... Это мы с вами знаем.
Думаю, у какой-нибудь барышни из турагенства, которая ищет билет на самолет, представления обо всем этом совсем другие... Вы думаете, она в курсе о lazy load ?

а это не технические детали

Готов спорить. См ниже.

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

Вообще-то, если брать клиентское приложение, то ему должно быть глубоко пофигу, как сервер баз данных или фреймворк работают с большими выборками данных, все ли они грузятся куда надо или только по запросу. Клиенту главное получить данные. И lazy load гарантирует, что он их получит. Но только когда обратиться в первый раз. И на самом деле, если lazy load не будет, то пользователю придется ждать уж точно не 1-2 секунды.
И что должно быть странного с точки зрения пользователя? Зачем ему знать, как работает код внизу? Ему нужно, чтоб все было быстро, в пределах пары секунд. А кто там внизу, когда, что и с кем - это уж пользователю-то точно по барабану. Это может быть не по барабану только программисту.

6yrop

Ему нужно, чтоб все было быстро, в пределах пары секунд.

к примеру, если нажатие каждой клавиши будет в приделах пары секунд, пользователя это не устроит явно . Т.е. действия пользователя делятся на два вида:
1. он ждет мгновенной реакции со стороны машины
2. он готов подождать пару секунд

6yrop

И на самом деле, если lazy load не будет, то пользователю придется ждать уж точно не 1-2 секунды.

это почему? пользователю не надо сразу много данных, он просто не сможет их все посмотреть

olga1969

И на самом деле, если lazy load не будет, то пользователю придется ждать уж точно не 1-2 секунды.

это почему? пользователю не надо сразу много данных, он просто не сможет их все посмотреть

Потому что если не будет lazy load, то придется делать, например, все бизнес-объекты сразу доступными для клиента. Если у вас их тысячи, то ни один сервер такое не потянет, особенно если это надо делать по каждому клиентскому запросу. А если еще, например, эти объекты нужно сериализовать и передать клиенту, то это вообще полный Пэ. Вот lazy load как раз и не создает все сразу, и зачастую именно потому, что пользователю не надо сразу много данных, он просто не сможет их все посмотреть, как было правильно отмечено. Зачем тогда делать никому не нужную работу?

Вот, скажем, гугл найдет по запросу 100 000 ссылок, и что, он должен сразу же сгенерить все 10 000 страниц своего ответа, по 10 ссылок на странице ? Все равно ведь никто 10 000 страниц просматривать не будет. Он сгенерит страниц 20, скажем, а если вы полезете дальше, то он сгенерит еще 20. Да, пользователь заметит некоторую дополнительную возню, ну и что?
Естественно, промежуточный результат выборки будет где-то там храниться, но генерация сразу всех 10 000 страниц - это уже лишнее, это гугл не переварит, если для каждого юзера все сразу генерить. Я не знаю, как там все на самом деле. Думаю, что еще есть всякий кэш и прочие оптимизации.

6yrop

надо разделять
1.загрузку по требованию пользователя — обычная ситуация — одно из событий инициированное пользователем
2. lazy load в коде приложения, например, обращение к свойству order.Customer. Произошло ли это обращение в обработчике "долгого" события от пользователя или еще где, вообще говоря, не известно.

olga1969

надо разделять
1.загрузку по требованию пользователя — обычная ситуация — одно из событий инициированное пользователем
2. lazy load в коде приложения, например, обращение к свойству order.Customer. Произошло ли это обращение в обработчике "долгого" события от пользователя или еще где, вообще говоря, не известно.

ээм... я не совсем понял, в чем разница

6yrop

ээм... я не совсем понял, в чем разница

разница, в том, что UI-программист пишет order.Customer и не знает долгая эта операция или нет, если долгая, то надо сообщить об этом пользователю, хотя бы песочные часы поставить.

olga1969

разница, в том, что UI-программист пишет order.Customer и не знает долгая эта операция или нет, если долгая, то надо сообщить об этом пользователю, хотя бы песочные часы поставить.

Ууу...
Весь сыр-бор из-за UI-программиста ?
Ну, вообще говоря, UI-программист может спросить разработчиков бизнес-логики, является ли операция долгой или нет. И что мешает ему поставить песочные часы в любом случае, вне зависимости от того, как операция выполняется?
Да, кстати, я бы еще добавил, что если UI-программист пишет код типа order.Customer, то это... кхм... не очень удачный дизайн в смысле ООП и прочего

6yrop

Да, кстати, я бы еще добавил, что если UI-программист пишет код типа order.Customer, то это... кхм... не очень удачный дизайн в смысле ООП и прочего

а как правильно?

6yrop

Ну, вообще говоря, UI-программист может спросить разработчиков бизнес-логики, является ли операция долгой или нет.

а разработчик бизнес-логики тут причем? загрузка данных к локиге бизнеса никакого отношения не имеет.

olga1969

Да, кстати, я бы еще добавил, что если UI-программист пишет код типа order.Customer, то это... кхм... не очень удачный дизайн в смысле ООП и прочего

а как правильно?

Ну, например, так:

orderManager.getCustomer(order)  

В order.Customer плохо то, что во-первых, идет прямой доступ к содержимому объекта order, что, как учит ООП, нехорошо. Но это дело спорное, поэтому я тут не настаиваю. Но проблема еще в том, что как бы UI-программист пишет код, который получается сильно связанным с бизнес-логикой. Если приложение большое, то потом следить за всем этим ужасно трудно и чревато ошибками. Лучше все же как разграничить UI-код и код бизнес-логики. Например, сделать четко определенные точки входа в бизнес-логику. Паттерны Facade или Mediator, например, подошли бы. Ну, еще есть паттерны Model-View-Controller и Presentation-Abstraction-Control и ряд подобных про то, как отделять бизнес-логику от UI.

olga1969

а разработчик бизнес-логики тут причем? загрузка данных к локиге бизнеса никакого отношения не имеет.

Согласен, не имеет. Ну, назовем это тогда системная логика

6yrop

В order.Customer плохо то, что во-первых, идет прямой доступ к содержимому объекта order, что, как учит ООП, нехорошо.

это так на C# записывается. На Java это выглядит так order.getCustomer

6yrop

ты можешь на пальцах объяснить чем такой вызов
orderManager.getCustomer(order)
лучше такого
order.getCustomer?

6yrop

Ну, вообще говоря, UI-программист может спросить разработчиков бизнес-логики, является ли операция долгой или нет.

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

И что мешает ему поставить песочные часы в любом случае, вне зависимости от того, как операция выполняется?

мышка будет мигать, не приятно

olga1969

ты можешь на пальцах объяснить чем такой вызов
orderManager.getCustomer(order)
лучше такого
order.getCustomer?

Возможно, я не совсем удачный пример привел, но суть его была в том, что есть класс OrderManager, который известен в UI, и все, что нужно отображать в UI из бизнес-логики касательно order'ов , нужно тянуть через OrderManager. Тогда в UI-коде нужно только знать о существовании OrderManager'а и его операций, и UI-код отделяется от кода бизнес логики.
Вообще, наверно, имя OrderManager не совсем удачно, оно не отражает сути и роли этого класса как медиатора между UI и бизнес-логикой. Лучше назвать типа UIOrderManager. Кстати, часто нужно бывает еще преобразовывать бизнес-данные в формат, удобный для UI, и эту функциональность тоже можно повесить на UIOrderManager.

olga1969

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

А ты как хочешь, чтоб UI-программист обо всем сам догадывался ?
Ему без общения с разработчиком бизнес-логики не обойтись. Например, если нужно сложный процесс отобразить. Все равно будут детали, которые надо согласовывать.

мышка будет мигать, не приятно

Это был железный аргумент. Я сдаюсь...

olga1969

мышка будет мигать, не приятно

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