I want to build a view that contains a toolbar a list and a statusbar. The toolbar will contain a new button, preview button, refresh button, search text box, begin search button, an owner combobox and a hide inactive checkbox. The statusbar will contain next and previous buttons to page through the results 50 records at a time. The status bar will also contain textblocks for page number and total number of pages. I have already programmed this using WPF and CSLA 3.0 and I now want to move it to CSLA 4.0.1 and MVVM. The existing XAML form has a CSLADataProvider for the list (ReadOnlyList) and the owner combobox (NVList). I would like to know the correct way to approach the programming using the CSLA classes. I was thinking of creating: 1. a ViewModel to provide the view with the Model and the bind able commands for the search button, new button and refresh button 2. a Business object (EditableRootParent) to provide: a. read / write properties for the search textbox, selected owner, hide inactive and page number b. read only properties for the owner NVList, number of pages, records per page and the read only list c. Business Rules to reload the list if the owner, hide inactive, or page number properties change d. Methods to reload the list if the search button or refresh button was pressed Is this the right approach or is there a better combination of CSLA classes to achieve this? Thanks Russ.
Your object model shouldn't be affected by a change of UI technology. The only time your object model should be affected is if the business use case has changed.
Conceptually you can think of a ViewModel<T> as being very similar to a CslaDataProvider. They aren't quite the same, but they aren't all that different either.
The idea behind the viewmodel is that it adds verbs/commands/methods for use by the view to your business object. Typically a CSLA business object already has all the methods necessary to handle the use case, but often doesn't have everything necessary to support the various UI gestures a user might take. So the viewmodel acts as a buffer between the view and model.
I think my object model needs to change because it was incorrectly designed the first time.
Some of my old list forms have as many as 6 CSLADataProviders on them to provide NVLists to the filter comboboxes on the toolbar.
I was hoping to bind the new View to a single ViewModel that provided all the required data. If this is not possible then maybe I should have a ViewModel for the Toolbar/StatusBar and a ViewModel for the List area?
I'm looking for the simplest approach to minimize or completely eliminate the code behind.
Russ.
When I have a page/form that has multiple objects (business list, some NVLs, etc) I often use a unit of work object (usually a ROB) to retrieve them as a unit. So my "parent" viewmodel gets that UOW object, then I have a "child" viewmodel for the buisness object. Usually you don't need a specific viewmodel to manage individual read-only lists, because they don't need any extra commands (or any commands really).
Thank you Rocky, that answer solves many questions in my head.
Jean Paul
Thanks Rocky.
I think the UOW is what I’m looking for however... my list form toolbar contains a search text box, and active check box and a user combo box. I think I want to bind these to read/write properties and let the business rules initiate a GetList() on the main ReadOnlyList when they change. I cannot accomplish this if I base the UOW on an ROB.
If I base the UOW on a BusinessBase with read/write fields for PageNum, RowsPerPage, UserFK, SearchText and Active and read only fields for NumOfPages, TotalRows and MainList then I could set up all the correct bindings to the form and let the business rules refresh the MainList, NumOfPages and TotalRows when any of the read/write fields change.
My questions are 1) does this sound like a good way to proceed and 2) Can I just set the ManageLifetime = false on the CSLADataProvider to ignore the Meta-state of the UOW object (i.e. IsDirty etc.)
Russ
I typically use a ROB for my UOW types, because you rarely want to round-trip all the supporting types (NVL and so forth) back to the server when you save.
I think I understand. So I want a UOW (ROB) object that contains:
1) Properties for all my supporting NVList types so that they are only transferred from the server to the client only once.
2) A BusinessBase property with:
a. Read/write fields for PageNum, RowsPerPage, UserFK, SearchText and Active
b. Read only fields for NumOfPages, TotalRows and MainList (ROL)
c. Business rules to reload the MainList, NumOfPages and TotalRows properties when any of the read/write fields change
Question: Is this even possible? Can a ROB contain a BusinessBase property?
If this isn’t possible then maybe I need to abandon my existing UI which is based on the older CSLADataProvider model and create a new UI based on the MVVM model so I can have “Child ViewModels”.
Russ
I just reviewed your CSLA Core 3.8 Video 4 on Data Portal Configuration and found the Unit of Work information starting at 99 minutes and 30 seconds. It answers all my questions.
Thanks
Russ
Copyright (c) Marimer LLC