Should we prefer immutable models when using SourceCache?

[Snailya]

Hi, I have a design question about SourceCache.

In Rx, immutable DTOs are usually preferred because they make state easier to reason about. But in DynamicData, SourceCache has a Refresh method which looks more useful for mutable models (when the object content changes but the key stays the same).

My scenario:

• I separate a lightweight Location (id + parentId) from expensive LocationData (properties).

• I want downstream to know if only the tree structure changed (rerender tree) or if the property data changed (rerender detail).

• If I use immutable DTOs, I would have two streams: one for Location and one for LocationData. Both share the same key (id) so their lifetime is coupled — when a Location is removed, its LocationData is removed too.

• If I use a model instead of immutable DTOs, I would implement the LocationData with a GetData method then trigger the data change by refresh Location, the view could filter out the structure changed by WhereReasonsAreNot(ChangeReason.Refresh)
  , and only the property change by WhereReasonsAre(ChangeReason.Refresh)

So my questions are:

• Is the recommended practice still to use immutable DTOs with SourceCache (and just call AddOrUpdate with a new object on change)?

• Or is SourceCache designed mainly for mutable models, with Refresh as the normal way to signal changes?

• In real-world apps, when should I prefer Refresh vs AddOrUpdate?

Thanks a lot for clarifying!

[JakenVeina]

Is the recommended practice still to use immutable DTOs with SourceCache (and just call AddOrUpdate with a new object on change)?

On a personal level, I would say yes, immutable state is recommended, but both scenarios are equally valid, and (in theory) equally supported.

Or is SourceCache designed mainly for mutable models, with Refresh as the normal way to signal changes?

Nothing about SourceCache limits you to either approach.

In real-world apps, when should I prefer Refresh vs AddOrUpdate?

The main use-case for mutable models, I'd say, is for use with WPF/MVVM apps. Constantly swapping out {Binding} targets in a WPF or WPF-like app is a great way to tank the app's performance. The whole tech stack is geared towards binding mutable objects that implement INotifyPropertyChanged. Similarly, the most popular use-case of DynamicData is probably paired with ReactiveUI, for which the story is the same: change notification is built around INotifyPropertyChanged not IObservable<>.

[Snailya]

Am I right to understand that the refresh method was born after supporting ReactiveUI?So that the UI will not refresh entirely.
If so could I make a conclusion that always prefer immutable models and call AddOrUpdate in the service? I've also noticed that the Transform operator would not trigger on refresh by default.

[JakenVeina]

Am I right to understand that the refresh method was born after supporting ReactiveUI?

Myself, I don't know, I wasn't around that long ago.

If so could I make a conclusion that always prefer immutable models and call AddOrUpdate in the service?

It's really down to personal preference and measured performance. Me, I generally prefer immutable state, because it makes debugging a lot simpler. I'm I need a mutable top layer for UI bindings, I'll transform TO that, from immutable sources.