Closed activa closed 7 years ago
My stance on this is that calling a method that returns an IObservable<T>
should do nothing. It is the subscription to that returned value that should invoke any side effects or processing.
If a subscription cost needs to be amortised across numerous subscriptions then the various multicast options in Rx should be applied.
In this specific case, the argument is weak, however it then muddies the pattern and opens the door for other methods to "do work" without a subscription. I see this as a very common mistake and a source of race conditions and leaking resources (think opening a connection, starting a timer etc)
In one of your recipes, you define an extension method to create an observer for property changes:
Is there a reason why you wrap this in a call to Observable.Create() ? If I understand correctly, the only difference this will make is that the two lines of code that get the property name and compile the property selector will be executed for every subscriber, which is not necessary and even hurts performance.
The following code does the same thing and prevents the calls to GetPropertyInfo() and .Compile() for every subscriber:
Am I missing something obvious?