Need help shifting from Winforms to WPF/MVVM

Need help shifting from Winforms to WPF/MVVM

Old forum URL:

reagan123 posted on Wednesday, August 03, 2011

I'm trying to shift from using Winforms/CSLA 3.1.7 to WPF/MVVM using the current CSLA release.  I'm having issues on translating my winforms UI approach.

The old approach typically had a grid that was bound to a read only list of objects.  Once the user selected an item, I would then fetch the editable object and bind it to the UI.  The user could then edit/save the record.

I'm tying to do a simple translation to MVVM and i'm getting a bit lost.

I have my CSLA objects:

Can anyone help me identifiy what my view model should look like to expose these objects to my view?  I know this is a big question, but I'm a bit lost.

Thank you.

RockfordLhotka replied on Wednesday, August 03, 2011

The way I tend to approach this, is to have a viewmodel that exposes properties - one property per object the view requires.

The ViewModelBase and ViewModel classes in Csla.Xaml help simplify the common case where the view binds to one primary model object.

If you have multiple model objects that aren't part of one object graph, then you need to either add properties to your viewmodel, or create a viewmodel from scratch. I typically add properties to my viewmodel, because I usually have one primary model object, and other secondary (usually read-only list) model objects.

A more complex view might have multiple viewmodel objects - for different logical parts of the view.

For example, if you display your PersonInfoList on the left side of the view, that side of the view would have a viewmodel - probably a ViewModel<PersonInfoList>. I'd use a TriggerAction (or other technique) to bind the datagrid's SelectedItemChanged event to an EditPerson method on this viewmodel.

On the right side of the view, you might have the area to edit the selected person. So that would be bound to a different viewmodel - probably a ViewModel<Person>. The EditPerson method in the first viewmodel would create an instance of this ViewModel<Person>, and provide the resulting viewmodel to the view as its binding source.

None of that is hard really - except that it needs to be done so the viewmodels have no knowledge of the view :)

So with what I just described, my primary viewmodel would be the ViewModel<PersonInfoList>, and it would have a PersonViewModel property that exposes the ViewModel<Person>. This way, the right side of the view can just bind to the PersonViewModel property, and when that property is set by the EditPerson method everything just happens automatically through binding.

In short, I tend to have one root or primary viewmodel for a view, along with other child viewmodel objects as needed.

The CSLA 4 MVVM video series demonstrates this approach.

reagan123 replied on Wednesday, August 03, 2011

Thank you so much for the quick reply.  I'm going to try to absorb this a bit and then try to setup a test implementation.

I really appreciate your help and time.

Michael replied on Tuesday, August 16, 2011

Hi Rocky

We're still stuck with .NET 3.5 and CSLA 3.8.3 for now, with VS 2010. How much different is the MVVM approach for 3.8.3? Will the version 4 video series help me?

Kind regards

jamie.clayton replied on Tuesday, August 16, 2011


I'm in the CSLA 3.8.2 + VS 2010 boat and the MVVM video series did help me understand all the tasks required for applying ViewModels with XAML and how to use VS2010 more productively. I have wrapped my CSLA BO with the ViewModel(of T) and changed my XAML UI to bind to these Views, but the going is much slower that I thought.  My code is much cleaner that the Windows Form code, but it's far from codeless behind the XAML windows/customControls. My applications are too large to convert everything at to ViewModel implementations, but I will end up converting all my existing XAML to bind to Csla.Xml.ViewModel.

After viewing the PDF documents for CSLA 4 and video series I quickly realised that the CSLA code doesn't provide a MVVM framework (BXF is probably too basic for LOB apps).  MVVM also implied you would need and IOC framework as well. So the MVVM approach is solid in my books, but it's left me with lots more questions and planning before I dive any further. Essentially you really need to build a spike application with a framework before settling on one.

Rocky points out, that the main tenant of MVVM is unit testing the UI.  If your a TDD/BDD shop, then that's the first thing I wanted to see with all the MVVM frameworks. And that's where I got very disappointed. Many of the MVVM discussions are around unit testing the ViewModel BO logic that we already have unit tests and business rules working (thanks to CSLA!), rather than how Views and iCommands/TriggerActions/ViewNavigation/ViewMessaging should be unit tested.  I've spent about 3 very full working days/nights researching MVVM frameworks and I've got mixed opinions, but to save your time -

  1. I like Cinches Mediator communication naming and the Command fail/success approach.
  2. Chinch isn't available on Nuget.
  3. I like Prims Region concept for managing views.
  4. I like MVVMLights communication pub/subscribing flexibility.
  5. MVVM light doesn't have any formal documentation, just videos and articles by people.
  6. I'm not sure why ICommand wasn't included in the CSLA MVVM video series as every MVVM includes an example.

So in summary, I get the impression none of the existing MVVM frameworks fit perfectly with CSLA, mainly because they are all trying to implement copies of what CSLA does so well. Each framework implementation uses different terminology. It's going to be a personal choice and a fairly involved one from my perspective.


RockfordLhotka replied on Tuesday, August 16, 2011


We're still stuck with .NET 3.5 and CSLA 3.8.3 for now, with VS 2010. How much different is the MVVM approach for 3.8.3? Will the version 4 video series help me?

It should help, yes. The video series includes content at the end, where I talk about the things that are different in VS 08 and CSLA .NET 3.8. Most of the differences have more to do with using .NET 3.5, SL 3, and Visual Studio 2008 than they do with using CSLA .NET 3.8.4.

You will probably need to switch to 3.8.4, or at least merge the current Csla.Wpf (or Csla.Silverlight) code into 3.8.3, to completely follow the videos. I back-ported some CSLA 4 features into 3.8.4 to get the necessary functionality working in 3.8.

Copyright (c) Marimer LLC