I just wrote this in a non-related thread (so it kind of got buried):
The question is which MVVM pattern? There are several variants with different pre-conditions and consequences.
Many of the MVVM pattern variants assume an anemic Model, such as a bunch of DTO/proxy/entity objects you get back from calling a service or something like EF or L2S. Those variants require that you do a lot of work in the VM to overcome the lack of functionality in the Model, and that's fine.
However, CSLA .NET ensures that your Model is far from anemic. In fact, it is incredible rich, with the DataTable being the only thing I know of that comes close. Fortunately there are variants of MVVM where the VM exposes the Model as a property, along with various methods (commands) that can be bound to buttons, etc.
That type of MVVM implementation works really well with CSLA .NET.
On the other hand, if you use one of the "anemic model" variants of MVVM with CSLA objects, you'll have to do more work in your VM or sacrifice a lot of functionality. Your VM could have to implement and delegate (bi-directionally) all the data binding interfaces, authorization, business rule and other functionality that is built directly into CSLA.
In either case (anemic or rich Model), if your object graph is complex (parent-child-grandchild-etc) your VM can become incredibly complex very rapidly, as you try to flatten or duplicate the shape of the Model.
I've had people argue that the point of the VM is to "reshape" the Model for the UI. And I agree that if your Model was not designed using good OOD (is data-centric rather than respnsibility-driven) then your VM will probably have to do that - which is really lame, and simply means you did a crappy job with your object model.
On the other hand, if you use responsibility-driven design for your business objects, your object model should naturally follow the shape of the use case, as should the UI. Since they follow the same use case, the objects should already be the right shape.
Lots of opinion there, but that's my current way of thinking about MVVM.
Yes it is good. Some variants work really well with CSLA. Other variants cause you to do so much work that I can't possibly imagine it is of long-term benefit.
Or to put it another way - I think the MVVM pattern is a fine thing. I think the data provider model is not all that different, because a data provider control is just a simple VM.
CslaDataProvider, in particular, is a pretty decent VM for common view/edit screen scenarios.
I much prefer the CslaDataProvider in CSLA .NET for Silverlight, because it isn't constrained by the pre-built data provider model in WPF. The WPF data provider base class is really a limiting factor.
Also, I much prefer the InvokeMethod implementation of commanding that we put into Silverlight, because it is a lot more flexible and powerful than commanding (and at the same time is simpler).
I really don't want CSLA to become a UI framework - my goal has always been to support Microsoft's plumbing (data binding and related components like data providers, data sources, etc).
However, the MVVM pattern today is so incredibly immature that you have to create everything from scratch. And that sucks. I personally don't want to spend that much time writing pages and pages of expendable UI code (because the V and VM are both UI elements).
In other words, I really think MVVM needs to grow up, and be componentized and RADified before I'll find it to be really compelling.
And to answer your other question - I haven't had time to play with the XAML data binding support in VS10, so I don't know if they use MVVM or not. But clearly my primary goal will be to make sure CSLA objects play very well with the VS10 designers.
I won't try to make MVVM bad, but until it shows signs of increasing productivity and reducing code, I can't get too excited about it.
All that said, I could certainly see something like the Silverlight CslaDataProvider and InvokeMethod controls being added to Csla.Wpf. I'd have to call the data provider something else (CslaObjectManager?), but those two things work so nicely in Silverlight that I really miss them when I have to do any WPF work these days.
Copyright (c) Marimer LLC