Wizard business object(s)?

Wizard business object(s)?

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

Russ posted on Monday, September 19, 2011

I’m using CSLA 4.1 to build a SL4 application using bxf, MVVM and I’m trying to determine the best CSLA business objects to use to support a wizard interface. You know, the typical user wizard that has a series of pages that the user needs to complete and press the next button to proceed.

I can envision using a single Entity Root stereotype object and letting the view model manage the next and previous page navigation or I could see using an Entity Root stereotype object for each page in the wizard. The latter approach provides the benefit of tying the next button the CanSave property and letting the rules engine do its thing. The latter approach has the disadvantage of having to create and maintain several BOs for each wizard.

I would appreciate any guidance that anyone is willing to share.






JonnyBee replied on Monday, September 19, 2011

Hi Russ,

Most of the time I end up doing the first version. And that is because the user has to complete all wizard pages before I can save or do the create.

An alternative would be to have a "root" object with a separate child object per page and pass the root object to the next/previous page. Last page can only Save if the "root" object is Savable.



Russ replied on Monday, September 19, 2011

Thanks Jonny,

I will follow your lead and use the first option of having only one Editable Root object for the wizard.

How have you structured this in the past?  One Editable Root object, one View Model and a View for each page in the wizard?  Or have you used a single View with an items container like a tab control or list box control to hold the wizard pages?

Thanks again



JonnyBee replied on Monday, September 19, 2011

I got to admit that most of my wizard pages have been in WinForms.

One key factor here is that you should keep a 1:1 relationship between viewmodel and business object.

IE: If you VievModel descends from Csla.Xaml.ViewModel - whenever the dependency property Model is set the ViewModel calls BeginEdit on the object.
So the ViewModel (much like BindingSource in WinForms) assumes it has total ownership of the Model. Meaning that if you create 5 ViewModels to the same object - the object will have 5 serialized snapshots in memory (and EditLevel at 5).

I expect others to chime in too -  but this is why you may opt for #2 in my post and create a ViewModel for each wizard page with a Child Object per ViewModel.

Russ replied on Thursday, September 22, 2011

Thanks Jonny,

I still think I will try option #1 however I will try to control the UI naviagtion using rules and BO properties that the View can bind to that tell the next and previous buttons when they are enabled.

Copyright (c) Marimer LLC