RemoteObject
 

Доброго времени суток, постараюсь поставить вопрос максимально корректно.

Спрашиваю у более опытных разработчиков для того чтобы они навели на путь истинный. Что такое RemoteObject мне понятно, это класс для взаимодействия с удаленными объектами как это видно из названия, но механизм его действия мне не очень понятен.

Могу предположить что: создается канал связи от клиентского приложения (Flex) к серверному допустим на (.NET), на серверном приложении хранится некий объект класса А, Flex формирует запрос на сервеную часть и получает в ответ тот самый объект класса А сериализованый в AMF тут мне вроде все понятно, допустим я вношу изменения в полученный с сервера объект класса А изменяю его название (name), в таком случае отправляется ли на сервер какая-то информация об этом и можно ли как-то изменить объект на сервере ?

Если кто-нибудь объяснить подробнее буду очень благодарен.

нет без вашего участия ничего не отправляется. изменить можно, кто мешает?

очень мутная технология.

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

Гляньте здесь

Лет 5 назад юзали флюорин. Не знаю как он сейчас - вот нашел http://forum.fluorinefx.com/index.php

Насколько я понимаю, это очередная реализация RMI/CORBA, только вместо клиентской заглушки используется компонент RemoteObject, общение идет как и у всех флексовых сервисов поверх HTTP, только RO использует AMF, что и является преимуществом.

Несколько примеров.

RemoteObject - это какой-то пра-пра-правнук NetConnection. NetConnection, в свою очередь, это класс управляющий соединением использующим RTMP[подобные] протоколы. В том числе, этот класс умеет парсить AMF формат. Во Флексе его назвали так потому что, наверное, идея была в том, чтобы представлять объекты созданные серверной программой на клиенте, и один экземпляр RemoteObject представлял бы один экземпляр, например, Hash<String>. Естесственно, понимание того, что это крайне расточительно пришло позже :) И никто таким образом RO не использует. В более современном варианте, RemoteObject сделали базовым классов для автоматически сгенерированных `сервисов' (т.е. объектов ответсвенных за обновление данных во всяких флексовых компонентах) - можно попробовать это сделать даже через GUI - вытащить на сцену какой-нибудь DataGrid, выбрать из Data -> Connect куда-то там, насторить куда подключаться и вам сгенерят абсолютно отстойный, но рабочий код этого самого подключения + какие-то функции управления этим подключением.
Кроме этого RemoteObject завязан на кучу разных вещей, вплоть до настроек компилятора. Например, -services настройка может задать глобально разные параметры, такие как алиасы для груп сервисов, куда нужно подключаться, формат каждого сервиса, класс, который нужно использовать для канала создаваемого для каждого сервиса и т.п. Все эти махинации, возможно, имели смысл, если смотреть на них в контексте BlazeDS (Adobe разрабатывают и предлагают купить серверную часть для работы с флексовыми приложениями). Вне этого контекста - как по мне, RemoteObject переполнен ненужными возможностями и очень сложен в использовании, гораздо проще и надежнее использовть NetConnection.

Согласен с тем, что RemoteObject есть смысл использовать только вместе с Blaze/Granite, и то обернутым в какой-нибудь Tide (для контекста; для "DI" с сервера на клиент).
Кстати да, вставки доп.констант компилирования типа -services убивают, да еще куча зависимостей (клиентские либы, генерация клиентских заглушек). Благо все это можно собрать c помощью flexmojos.