If you are working with WPF or Silverlight view models, then you know that one of the more annoying things to deal with is implementing INotifyPropertyChanged to support refreshing the UI when the model is changed.

In other words, you can treat the object as if it wasn’t a wrapper for reading purposes. I could make it both ways, but then I would have no way of maintaining the same instance for updates. Overall, I found the it made it quite a bit easier to deal with the task of UI updates.

Yea postsharp is a potential, more and more recently I've been thinking about what I think is one of the lacking areas in '.NET', and thats where we don't have really any control at compilation time (sure we can do pre-processors etc but thats not exactly simple)..

There are tons of places we end up pushing complex work to runtime that could well be evaluated once at compile time, I really think .NET needs a built in system that runs after compilation to IL, and can run transforms.. just as postsharp is allowing.

In WPF it's convinient to run validation in properties. When validation fails exception is thrown and 'ValidatesOnExceptions=True' in binding allows to visually accent wrong field and show tooltip with explanation.

The problem with INotifyPropertyChanged is not firing events. It's being the middle man. The View Model layer is hard to write because you have to respond to changes in the Data Model, update yourself, and forward events to the View. But when you use Update Controls, there is no data binding code in the View Model at all.

Sorry, you said "you can treat the object as if it wasn’t a wrapper for reading purposes. I could make it both ways" I understand how this works for reading, but I didn't know you could do the same for writing values to the .Value property.

I'm regular reader of your blog but for this one, I don't agree with you. I prefer to have the actual type (e.g. int PersonID ) instead of this (e.g. Observe
<int PersonID ). I feel like it makes my Model look ugly. Sorry.

First, I don't think I would ever use something like this. I don't mind the extra work, and using the wrapper classes seems like just as much extra work anyway. You've also introduced .Value all over your usages (no implicit conversion on assignment).

That being said, why did you choose to use a class instead of a struct? I would actually expect to keep value semantics versus reference semantics. It seems very odd to wrap up an integer as a class to me. You also have potential performance improvements (thought doubtful to matter in 99% of the applications out there) considering that many view model type objects contain a significant number of value types.

The distinction I draw between Model (or more precisely Data Model) and View Model is this. A Data Model is persistent. A View Model is dependent.

What you've proposed here works for the Data Model because it has storage. But it does not work for a View Model. A View Model has no storage; all of its properties are calculations that bring together properties of the Data Model.

You can also pick Obtics (
http://obtics.codeplex.com/), and you'll get real-time updates for calculated values (including Linq). I really love real-time Linq with WPF -- it completely removes the need to think what changed when and what was affected.

I have done this for our WPF based projects for ~1 year. I have been calling this PropertyModel. We have also included other presentation specific per-property metadata in our property model types.

IPropertyModel
<t : INotifyPropertyChanged {

T Value

bool IsEditable

string CustomEditorName

void SignalChanged()

...etc

}

This has made many of our binding scenarios much cleaner. We have also made a series of policies that toggle propertymodel settings. This has given us generally more reuse of common screens. For example our New and Edit screens are the same. The edit screens let us flip certain IsEditable values to false and so on.

'Serial related properties' often manifest in classes like:

class X {

Foo a;

bool isADirty;

bool wasAUserEntered;

}

This initial smell + the ugly repetitive INotifyPropertyChanged business helped us to normalise our property related data into 1 PropertyModel.

Validation is a separate concern. We have CommandModels ala this
blogs.msdn.com/.../756095.aspx
Each CommandModel has a Validator on it. Each validator is essentially a Func
<t,validationresult>
where the result has potential messages and a bool on it. This lets us compose validations together using a CompositeValidator (list of those Funcs basically). Each command is bound to the UI, we bind all our validators to enable the commands and to show messages (eg; we put tooltips over disabled buttons with the errors etc).

Fair enough. Could you demonstrate then how you would update your view model from the data model? For example, set AllowEditing when certain conditions are true?

The reason I define a view model to have no storage is because it allows you to write what AllowEditing means in just one place: the getter. If it has storage, you have to set that storage from someplace else, usually from a property changed event handler. That's seems like extra work to me. I'm curious to see how you solve that.

I would argue that there is more craft here. Also Dependency Properties are implemented in a way which actually makes them perform better in bindings because the framework doesn't have to use reflection.