Guidance on MVVM inspired ideas

Guidance on MVVM inspired ideas

Old forum URL: forums.lhotka.net/forums/t/7187.aspx


Paul Czywczynski posted on Sunday, June 28, 2009

Rocky, a while ago you mentioned you wanted to see where VS2010 is going regarding the MVVM paradigm. I am not trying to jump on the popularity wagon with MVVM I do like the advantage of unit testing the different layers.

When we started our app WPF was beta and MVVM was a glimmer in a guy's blog post. Currently we're still developing against CSLA 3.0.4 but are planning to move to 3.6 soon. This weekend I decided to start prototyping some of the MVVM features in our old application. My goal is to be able to write a unit test for our CSLA object (done...) and make a form that didn't have a code-behind file but instead use a ViewModel and unit test it.

Currently I am at a crossroads. Should I use a CslaDataProvider/ObjectDataProvider? In our app we use the DataProviders so we don't have to write async code for working with data. Although with 3.6 I know you have written your own async code to deal with Silverlight and we plan to utilitze that once we move to 3.6. So with 3.6 and a ViewModel do we need to utilize the CslaDataProvider anymore? Seems to me that CslaDataProvider's commands could be replaced with the ViewModel.

In my prototype ViewModel I have my ReadOnlyList wrapped in a ListCollectionView because I need the ViewModel to act upon selected items. Should I set the form's datacontext directly to the ViewModel and write my own async code until we upgrade to 3.6 or use a CslaDataProvider with IsAsync=true instead?

I am looking for guidance on how to reach my goals.

form <-> CslaDataProvider <-> ViewModel <-> CslaObject
  (I am not sure how to get the commanding to work between the CslaDataProvider and ViewModel yet)

form <-> ViewModel <-> CslaObject

or stick with what we have been doing for years

form w/ code-behind <-> CslaDataProvider <-> CslaObject

-Paul


RockfordLhotka replied on Sunday, June 28, 2009

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.

RockfordLhotka replied on Sunday, June 28, 2009

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