I can see where you are coming from, but there are big implications to what moving such highly used types.

Personally I do not use INPC or OC on my data models (biz objects). I do use them on my ViewModels, but my VMs are coupled with WPF anyways. My data models are generally wrapped by my VM, so my data models are portable.

I agree with the IColor, but that also has large implications also. I think that's going to be a design limitation we have to live with! At this moment, I think we should consider ourselves lucky there isn't a new color structure!

Holy Crap. I didn't realize anyone read my blog ;)

I wonder what the implications really are though - would there be a performance decrease? I can't really see why? I could imagine there might be some problems with moving OC<T>, although I can't think what they'd be, but I definitely can't see how moving an interface could hurt all that much. Especially if you leave everything in the same namespace as before.

I do use MVVM, but I'd say at least 80% of the time, my model objects are well positioned to be bound to directly. I don't need to attach any new view specific behavior or properties to my models. This problem becomes more significant when you've got a hierarchy of objects that you want bound to all at once.

For instance - if I wanted to display in a tree a hierarchy of People to Pets to Toys. What happens when a different thread on a different screen adds a new toy to one of the pets. If you're using stripped model classes, you have to write all sorts of code so that your view model is made aware that something has changed. But if the hierarchy of objects is created using OC<T> - all the plumbing is already done for you.

Do you just end up writing all that extra code? Is there a trick that I don't know about?

Well consider how many programs you could potentially break by moving that interface, even if it remains in the same namespace. For instance, your new code would compile, but what about programs already compiled and out in the wild. When you use a type in an external assembly, the external assembly filename is also taken into account when resolving a type, not just the namespace. Older applications would be looking for the type in another assembly. This would break backwards compatibility.

On MVVM...It's my opinion (and it's really just that!), that the purist approach to the pattern is that your view should always bind to a view model. Your business objects/model should have mechanisms to notify your VM (or any subscriber) if something has changed on another thread.

That being said, I am not a purist! I have done what your are describing quite a bit. I usually do this with the proxy types generated from service references (INCC and OC are used by default in the generator). But service references, with their generated nature, negate any concerns of having a portable model. If my business objects are not generated, keeping them portable is usually taken into account when they are being designed.

I agree that the "purist" approach will take more code, but if the project is quite complex, that is a good way to keep maintainability. For me, the size of the application determines how much scaffolding is needed. It's pretty easy to take a 1k LoC application to 5k LoC, just by abstracting everything to non-existence!

Cheers,

-Jer

BTW, I found your blog via Dotnetkicks!