My example: If you have derrived property like NamePresentationWidth, which is some calulated width based on a Name property multiplied by a Font factor, then the Font selection should be part of the/a model and databound in some fashion. Then, if either of the objects settable properties are changed (Name or Font), the derived property will report changed.

I guess my point is: even if you only have a need for this in memory while a UI view is active, it is still a model, just a model to store the data/state of a veiw. IMHO, that is exactly what a ViewModel was originally intended to be. So, it may not belong directly in your data model (I would need to know more ot comment further) it still is something to do in a standard model fashion.

Hope that helps.

Rick Weyrauch

I agree the purest approach would be to hold all the information in the model and use derived attribute. However in my real situation (the sample is very simplifyed) I have a diagram with a plenty of elements of different types, each of them has plenty of properties, the most of them ate managed by specialized framework. The only thing I need to manage in model is the serialized diagram that depends on all these elements and their properties. The framework makes xml-serialization automatically, so it would be not practicable to neglect this feature and to construct xml with model means. My point is to reduce the amount of these serializations - because of that I came to the idea to do it on Idle.

I hope you understand my motivation now.

/Efim