![]() |
|
||||||||||
|
|||||
|
Регистрация: Apr 2010
Сообщений: 25
|
Доброго времени суток, постараюсь поставить вопрос максимально корректно.
Спрашиваю у более опытных разработчиков для того чтобы они навели на путь истинный. Что такое RemoteObject мне понятно, это класс для взаимодействия с удаленными объектами как это видно из названия, но механизм его действия мне не очень понятен. Могу предположить что: создается канал связи от клиентского приложения (Flex) к серверному допустим на (.NET), на серверном приложении хранится некий объект класса А, Flex формирует запрос на сервеную часть и получает в ответ тот самый объект класса А сериализованый в AMF тут мне вроде все понятно, допустим я вношу изменения в полученный с сервера объект класса А изменяю его название (name), в таком случае отправляется ли на сервер какая-то информация об этом и можно ли как-то изменить объект на сервере ? Если кто-нибудь объяснить подробнее буду очень благодарен. |
|
|||||
|
Регистрация: Apr 2010
Сообщений: 25
|
а может у кого-нибудь есть готовые примеры или ссылки на них ? не могу разобраться в части интеграции с .NET
|
|
|||||
|
Лет 5 назад юзали флюорин. Не знаю как он сейчас - вот нашел http://forum.fluorinefx.com/index.php
__________________
Чтобы доказать, что вы не робот, причините вред другому человеку. |
|
|||||
|
Насколько я понимаю, это очередная реализация RMI/CORBA, только вместо клиентской заглушки используется компонент RemoteObject, общение идет как и у всех флексовых сервисов поверх HTTP, только RO использует AMF, что и является преимуществом.
Несколько примеров. |
|
|||||
|
Modus ponens
|
RemoteObject - это какой-то пра-пра-правнук NetConnection. NetConnection, в свою очередь, это класс управляющий соединением использующим RTMP[подобные] протоколы. В том числе, этот класс умеет парсить AMF формат. Во Флексе его назвали так потому что, наверное, идея была в том, чтобы представлять объекты созданные серверной программой на клиенте, и один экземпляр RemoteObject представлял бы один экземпляр, например, Hash<String>. Естесственно, понимание того, что это крайне расточительно пришло позже
И никто таким образом RO не использует. В более современном варианте, RemoteObject сделали базовым классов для автоматически сгенерированных `сервисов' (т.е. объектов ответсвенных за обновление данных во всяких флексовых компонентах) - можно попробовать это сделать даже через GUI - вытащить на сцену какой-нибудь DataGrid, выбрать из Data -> Connect куда-то там, насторить куда подключаться и вам сгенерят абсолютно отстойный, но рабочий код этого самого подключения + какие-то функции управления этим подключением.Кроме этого RemoteObject завязан на кучу разных вещей, вплоть до настроек компилятора. Например, -services настройка может задать глобально разные параметры, такие как алиасы для груп сервисов, куда нужно подключаться, формат каждого сервиса, класс, который нужно использовать для канала создаваемого для каждого сервиса и т.п. Все эти махинации, возможно, имели смысл, если смотреть на них в контексте BlazeDS (Adobe разрабатывают и предлагают купить серверную часть для работы с флексовыми приложениями). Вне этого контекста - как по мне, RemoteObject переполнен ненужными возможностями и очень сложен в использовании, гораздо проще и надежнее использовть NetConnection.
__________________
Hell is the possibility of sanity |
|
|||||
|
Согласен с тем, что RemoteObject есть смысл использовать только вместе с Blaze/Granite, и то обернутым в какой-нибудь Tide (для контекста; для "DI" с сервера на клиент).
Кстати да, вставки доп.констант компилирования типа -services убивают, да еще куча зависимостей (клиентские либы, генерация клиентских заглушек). Благо все это можно собрать c помощью flexmojos. |
![]() |
![]() |
Часовой пояс GMT +4, время: 08:26. |
|
|
« Предыдущая тема | Следующая тема » |
|
|