2013-04-08 12 views
10

Zarówno system. Reactive extension for .NET i new C# 5.0 (.NET 4.5) async/await pościg (lub na podstawie) future and promises constructs paradygmat (podejście).Przykład kodu ilustrujący różnicę między paradygmatami rozszerzenia async/await i Reactive (Rx)?

Czy możesz podać (*) najprostszy przykład kodu C# ilustrujący różnicę między nimi?

(*)
Czy jest to możliwe bez połączeń I/O, Internetu lub bazy danych?

Aktualizacja:
Cóż, pozwól mi przeformułować jeśli kwestia ta wydawała się być odpowiedział wcześniej.
Po co dodawać i używać rozszerzeń reaktywnych (Rx) dla .NET przy użyciu natywnego .NET Iobservable/IObserver + await/async?

Jakie są możliwe ilustracje tego, czego brakuje w Rx, który zrobił to samo, bardziej niezgrabne lub mniej wydajne bez Rx (tj. Angażowanie tylko natywnego interfejsu .NET Iobservable/IObserver + czekającego/asynchronicznego)?

+0

Czy nawet googlowałeś? Show nie daje żadnych oznak, że masz. – fredrik

+0

@fredrik, w jaki sposób powinienem udowodnić brak wyników google SERP na nim? –

+1

Po prostu powiedz, czego szukałeś i nie przyniosło to żadnego rezultatu. To pokaże dla mnie, że przynajmniej spróbowałeś. – fredrik

Odpowiedz

11

Paradygmat przyszłości/Promesa stosuje się na ogół do zwracania pojedynczej wartości w przyszłości. Być może potrzebne są ciężkie kalkulacje lub OI, a więc dlaczego nie można zagwarantować, że wrócą synchronicznie w odpowiednim czasie.

Rx (i przez proxy interfejsy IObserver<T>/IObservable<T>) jest paradygmatem obserwowalnych sekwencji. Tak jak metoda synchroniczna może zwrócić pojedynczą wartość (int), może również zwrócić wartość IEnumerable<int> z jedną wartością. Porównując to do asynchronicznego świata, Task<int> może zwrócić pojedynczą wartość int, IObservable<int> może zwrócić sekwencję z jedną wartością int.

Jeśli więc chcesz zwrócić sekwencję wartości za pomocą Task<T>, musisz utworzyć jakiś rodzaj kontynuacji lub zwrócić kolekcję/tablicę/listę wartości jako T, np. Task<int[]>. To jednak oznacza, że ​​otrzymujesz wszystkie wartości lub nie.

Task/ to również konkretny typ, w którym Rx używa interfejsów do abstrakcji z wdrożenia. Znalazłem to, aby pomóc w testowaniu jednostkowym. TaskCompletionSource<T> może jednak pomóc w uniknięciu niejawnej współbieżności podczas testowania z zadaniami.

Na koniec, oprócz głównej różnicy, że Rx ma do czynienia z sekwencjami wartości (nie pojedynczymi wartościami), Rx jest również zaprojektowany do pracy z LINQ w celu dostarczenia korzyści związanych z zapytaniami i składem, które wydaje się działać bardzo dobrze z sekwencjami (na odpoczywać jak IEnumerable<T> lub w ruchu jak IObservable<T>).

Są to ostatecznie różne narzędzia do nieco innych zadań. Istnieje pewne nakładanie się, więc czasami można użyć jednego do zrobienia tego, co jest lepsze w drugim.Mówiąc dokładniej, myślę, że Task jest lepszy w komponowaniu jednostek asynchronicznej pracy razem (Zrób to, to zrób to, to zrób to), gdzie jak Rx jest lepszy w komponowaniu sekwencji zdarzeń razem (Kiedy to zdarzenie się dzieje, zrób to z danymi z tego innego wydarzenia).

+0

Nie potrzebujesz 'Task ' dla wielu wartości, dla wielu wartości możesz użyć 'Zadanie >' i możesz również użyć interfejsu 'INotifyCollectionChanged'. –

+0

Jak wskazano "..wróć kolekcję/tablicę/listę wartości ..". W dyskusji nie chodzi o zdarzenia (które bardziej odnoszą się do RX), ale o porównanie pomiędzy 'Rx' i' Task'. Dodawanie zdarzeń, APM, wątków, wywołań zwrotnych i innych stylów asynchronicznych spowodowałoby bardzo dużą dyskusję, a nawet książkę.;-) –

4
+1

+1. Zauważ również, że działają one dobrze razem: 'Task .ToObservable()' tworzy 'IObservable ', który wytwarza tylko najwyżej jeden wynik, a 'czeka na myObservable' pozwala na asynchroniczne oczekiwanie na ostatni element obserwowalnego. –

+0

@StephenCleary, czy uda ci się zrobić to samo (lub różne) jako odpowiedź? –

3

Lubię tabelę w Reactive dokumentacji: http://reactivex.io/intro.html

Mam własny zabiorą to gdzie mogę dodać trzeci wymiar non-sk/sk.

Non-sk:

  • pojedynczy element/synchroniczny: funkcja
  • Wiele przedmiotów/synchroniczny: iterable
  • pojedynczy element/asynchroniczny: funkcja asynchroniczny
  • Multiple items/asynchronous: observing

composable:

  • pojedynczy element/synchroniczny: funkcja wyższego rzędu
  • wielu elementów/synchroniczny: LINQ/ramda/java.util.stream
  • pojedynczy element/asynchroniczny: przyszłość/obietnica
  • Wiele pozycji/asynchroniczny: RX obserwowalne

I pamiętajcie, że w zależności od implementacji, można mieć futures i obserwable rx, które mogą działać zarówno synchronicznie lub asynchronicznie w zależności od tego, co chce zrobić z nich jest synchroniczna lub asynchronicznym

Powiązane problemy