The choice to work with INPC on the Model is driven by simplicity. Using a DO there is overkill because DOs are quite heavy and "drag" with them a lot of features that only make sense on a UI. For instance, DOs are not serializable while INPC implementations are, of course.

In MVVM Light V4, you can use the ObservableObject class and derive from this.

Hi,

The concept of being serializable is an interesting issue. In my presentation, the object is serialized using a serializer I wrote, which does not require specific attributes. However the built in serializers in .NET choke when the base classes are not marked as serializable. Honestly I never understood Microsoft’s need for that. It would be much better to assume that classes are serializable, unless marked otherwise. If you use other widespread serializers such as JSON.NET for instance, the policy there is to serialize everything public, unless it is marked as “not serializable”.

Unfortunately, the built in serializers do not do that, and so the burden is on every framework maker to add the series of attributes needed to palliate that shortcoming.

Right now, ObservableObject does not carry these attributes. Mostly, people who work in applications using MVVM Light did not feel that need, because we typically don’t use the built in serializers. They are slow and not very friendly. I see two possibilities in your scenario:

- Either use a modern serializer such as JSON.NET or

- Build your own ObservableObject, which is really quite easy. In fact you can find and modify the code on the MVVM Light site on Codeplex.

I might eventually mark ObservableObject as serializable, but I am not sure I will. Once I add this attribute, then I will get requests for others and I am not sure I want to promote the usage of the inferior serializers that are built into .NET.

Hopefully this helps a bit

Laurent

From: mike969

From: mike969