http://channel9.msdn.com/Blogs/Charles/Announcing-the-Official-Release-of-Rx

Здравствуйте, z00n, Вы писали:
Z>http://channel9.msdn.com/Blogs/Charles/Announcing-the-Official-Release-of-Rx

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, z00n, Вы писали:
Z>>http://channel9.msdn.com/Blogs/Charles/Announcing-the-Official-Release-of-Rx
А>Наблюдаю за развитием Rx уже давно, но никак не могу для себя определить где и как она может мне сгодиться и чем она лучше стандартных средств языка?
А стандартных средств и нет. Вернее их всегда мало, и нужны какие-нибудь "костыли" типа AsyncOperation, AsyncEnumerator или т.п. Rx приходит на замену ублюдочному IAsyncResult, и это радует. Мы недавно закончили переход на Rx в своем проекте. Должен отметить, что все без исключения места, связанные с асинхронными запросами и обработкой данных, стали гораздо читабельнее, а возможность комбинации запросов (вставки одного Observable в другой) так совсем прелесть. Rx также, как Linq в свое время, провоцирует на пересмотр, используемых ранее подходов в лучшую сторону.

Здравствуйте, Аноним, Вы писали:

А>Наблюдаю за развитием Rx уже давно, но никак не могу для себя определить где и как она может мне сгодиться и чем она лучше стандартных средств языка?

Главное преимущество Rx в том, что она позволяет организовать понятный и логичный поток данных. Отчетливо можно проследить условия возникновения и уничтожения вычислительного процесса, переключения между потоками и при этом, в большинстве сценариев, совершенно не нужно думать об особенностях синхронизации (блокировки и ожидание).

Вот, например, простенькая реализация отображения содержимого последнего созданного файла на диске С. Предполагается, что этот код запускается в потоке представления (например, конструктор модели представления).

var scheduler = new SynchronizationContextScheduler(SynchronizationContext.Current);

var watcher = new FileSystemWatcher("c:\\")
        {
            IncludeSubdirectories = true,
            EnableRaisingEvents = true,
        };

// Представление файла в виде обозреваемой коллекции байт. 
Func<string, IObservable<byte[]>> observableFile = 
    filePath => Observable
        .Return(filePath, scheduler) 
        .Do(_ => this.IsLoading = true)
        .SelectMany(path =>  new FileStream(path, FileMode.Open).AsyncRead(2>>16))
        .ObserveOn(scheduler)
        .Finally(() => this.IsLoading = false);

Observable
    .FromEvent<FileSystemEventArgs>(watcher, "Created")
    .Do(e => scheduler.Schedule(this.Document.Clear())) 
    .Select(e => observableFile(e.EventArgs.FullPath))
    .Switch()
    .ObserveOn(scheduler)
    .Subscribe(
        bytes => this.Document.Add(bytes),
        error => this.HandleException(error));

В случае реализации средствами .NET — весь этот код будет размазан по одному, а то и нескольким файлам. Например, чтобы отписаться от события, в классе нужно будет заводить поле класса _watcher и метод обработки события. А организация асинхронного чтения вообще уведет в код, оперирующий обертками над IAsyncResult, а это сомнительное удовольсвие. Безусловно, пример несколько надуман, но при должном усердии подход, применяемый в Rx очень хорош. MxMsk уже сказал, что в нашем проекте все асинхронные задачи переведены на Rx (с полноценными отменами, прерываниями, разветвлениями и адекватной реакцией UI).

Здравствуйте, a_vzhik, Вы писали:

_>Здравствуйте, Аноним, Вы писали:

А>>Наблюдаю за развитием Rx уже давно, но никак не могу для себя определить где и как она может мне сгодиться и чем она лучше стандартных средств языка?

_>Вот, например, простенькая реализация отображения содержимого последнего созданного файла на диске С. Предполагается, что этот код запускается в потоке представления (например, конструктор модели представления).


_>// Представление файла в виде обозреваемой коллекции байт.
_>Func<string, IObservable<byte[]>> observableFile =
_> filePath => Observable
_> .Return(filePath, scheduler)
_> .Do(_ => this.IsLoading = true)
_> .SelectMany(path => new FileStream(path, FileMode.Open).AsyncRead(2>>16))
_> .ObserveOn(scheduler)
_> .Finally(() => this.IsLoading = false);


В выделенном утечки ресурсов нету?? Dispose() не мешало бы сделать (вроде в Rx есть что то типа Observable.Using() )

Здравствуйте, MxMsk, Вы писали:

Z>>>http://channel9.msdn.com/Blogs/Charles/Announcing-the-Official-Release-of-Rx
А>>Наблюдаю за развитием Rx уже давно, но никак не могу для себя определить где и как она может мне сгодиться и чем она лучше стандартных средств языка?
MM>А стандартных средств и нет.

С багами встречаться не приходилось? В релизе их много?

Здравствуйте, a_vzhik, Вы писали:

_>В случае реализации средствами .NET — весь этот код будет размазан по одному, а то и нескольким файлам. Например, чтобы отписаться от события, в классе нужно будет заводить поле класса _watcher и метод обработки события. А организация асинхронного чтения вообще уведет в код, оперирующий обертками над IAsyncResult, а это сомнительное удовольсвие. Безусловно, пример несколько надуман, но при должном усердии подход, применяемый в Rx очень хорош. MxMsk уже сказал, что в нашем проекте все асинхронные задачи переведены на Rx (с полноценными отменами, прерываниями, разветвлениями и адекватной реакцией UI).

Скажу свои впечатления от кода, человека не сведущего в Rx — сложно много операторов с неясным смыслом — т.е. если у меня болит зуб — надо защимить палец дверью и теперь зуб не болит, но зато болит палец!!! )
Так вот мне представляется ситуация с Rx схожа вышеописанной ситуацией.
Когда-то давно пытался "войти" в Rx — на тот момент сколь-нибудь доходчивой информации не было — а как с этим сейчас?
Нужно ли сначала изучить километры справки, чтоб что-то начать на Rx?

Здравствуйте, Jack128, Вы писали:

J>В выделенном утечки ресурсов нету?? Dispose() не мешало бы сделать (вроде в Rx есть что то типа Observable.Using() )
Да, здесь стоит добавить Observable.Using. Хотя возможно, что AsyncRead сам заботится о ресурсе. Кстати, в релизе этого метода нет. Ранее в Rx была сборка ClientProfile с методами чтения и записи потоков через Observable. В релизе я этой сборки не увидел, как не увидил и аналогов. Может у кого-нибудь есть информация, отчего так?

Здравствуйте, MxMsk, Вы писали:

MM> Может у кого-нибудь есть информация, отчего так?
Так всё, связанное с async-ом и с Ix пока в экспериментальных сборках, нет?

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

Здравствуйте, _FRED_, Вы писали:

_FR>С багами встречаться не приходилось? В релизе их много?
Один раз я нарвался на dead lock, но это только помогло придумать другую, более кошерную реализацию — и с меньшим количеством кода и без side effect-ов. Конечно, мы не все методы Observable используем. В основном Select и SelectMany, параллельные запросы через When, накопление при помощи Buffer, вызовы UI через ObserveOn, аналоги using и finally. Помимо этого, встречается прерывание одной последовательности другой, продуцирование значений от событий и типичных асинхронных вызовов. Всё это работает без сбоев уже несколько месяцев. Ни разу не было багов, связанных с Rx.

Здравствуйте, Аноним, Вы писали:

А>Скажу свои впечатления от кода, человека не сведущего в Rx — сложно много операторов с неясным смыслом — т.е. если у меня болит зуб — надо защимить палец дверью и теперь зуб не болит, но зато болит палец!!! )
А>Так вот мне представляется ситуация с Rx схожа вышеописанной ситуацией.
А>Когда-то давно пытался "войти" в Rx — на тот момент сколь-нибудь доходчивой информации не было — а как с этим сейчас?
А>Нужно ли сначала изучить километры справки, чтоб что-то начать на Rx?
Отсутствие внятной справки — это огромная ложка дегтя в Rx Соглашусь с тем, что смысл некоторых методов действительно не ясен и иногда пишешь наобум . Например, Materialize. Тем не менее, потихоньку Rx добавляется в MSDN. Если правда, что она станет частью .Net Framework, то потихонечку во всем разберемся

Здравствуйте, Sinix, Вы писали:

MM>> Может у кого-нибудь есть информация, отчего так?
S>Так всё, связанное с async-ом и с Ix пока в экспериментальных сборках, нет?
AsyncRead — простой метод расширения, ничего особенного он не делает и с async-ом имеет общего только название В нем использовался метод Observable.Iterate, который в релизе пропал или был заменен каким-то аналогом.

Здравствуйте, Jack128, Вы писали:
J>В выделенном утечки ресурсов нету?? Dispose() не мешало бы сделать (вроде в Rx есть что то типа Observable.Using() )

Конечно утечка есть, спасибо. Создание файла нужно обернуть в Observable.Using().

Здравствуйте, Аноним, Вы писали:
А>Скажу свои впечатления от кода, человека не сведущего в Rx — сложно много операторов с неясным смыслом — т.е. если у меня болит зуб — надо защимить палец дверью и теперь зуб не болит, но зато болит палец!!! )
А>Так вот мне представляется ситуация с Rx схожа вышеописанной ситуацией.
А>Когда-то давно пытался "войти" в Rx — на тот момент сколь-нибудь доходчивой информации не было — а как с этим сейчас?
А>Нужно ли сначала изучить километры справки, чтоб что-то начать на Rx?

Вы знаете, это обычная ситуация — смотреть на новый язык/фреймворк/парадигму и тихо удивляться "зачем так сложно и непонятно?".
Конкретно мне для входа в Rx понадобилось понять концепцию Observable как вывернутого Enumerable (это описывается почти во всех статьях), внимательно прочесть брошюру с девятью лабораторными работами "DEVHOL202 – Curing the asynchronous blues with the Reactive Extensions for .NET" (на 40 страниц с неприлично большим количеством картинок и кода) и бегло пробежаться по документу "Rx Design Guidelines". И, конечно, заставить себя начать использовать Rx. Например, я написал порядка 15 реализаций асинхронного чтения файла в стиле Rx, пока не понял как это нужно делать правильно.