Maintenance Form Navigation

NickTaylor posted on Thursday, November 19, 2009

Hi...

I wonder if someone can offer some best practice advice please...

I am writing a maintenance form class to provide the ability to edit data. Nothing fancy, just a typical maintenance form with the ability to add, edit, and delete records from an underlying table.

However i'm a little confused as regards navigation.

Imagine we have maintenance form which edits customers. Naturally we have a business object BoCustomer which is based on the BusinessBase class and holds information on a single customer ( obviously it has a factory method something along the lines of GetByCustomerID(int custID) ). No problems here. For my maintenance form however I will require some ability to display a bunch of customers, and allow the user to navigate around them. So we would expect to have a ListCustomers object based on BusinessListBase and give it a factory method along the lines of GetAllCustomers().

However in reality the list object is only there for the purposes of navigation as BoCustomer is never going to be a true child object, its an EditableRoot object. I would want to instantiate individual customer objects in some of my business logic code, so they have sort of become switchable objects if I adopt the above strategy. This doesn't feel right, and I believe switchable objects are frowned upon!?

I am interested to know how people tackle this issue...

Any help would be welcome.

Thanks,

Nick 

dlambert replied on Thursday, November 19, 2009

I usually just used a "lite" version of the full object for lists, search results, etc - I think you can see this in the samples as "info" objects (ie, CustomerInfo). When a user selects a specific customer and indicates that they want to edit that customer, load the "full" customer object and edit against that object.

The idea here is to keep the listing, browsing, and searching-type screens faster by not loading up all the data fields (and associated relations) that you need when you're doing edit operations on those objects.

When I initially saw this pattern, I resisted it because it felt like I was duplicating code and functionality, but it works well enough that it's worth it.

There's probably an opportunity to look at a way of deriving "info" classes based on "full" classes -- maybe dynamically, or maybe as a code-generation exercise (T4?). In practice, however, I'm not sure this is a big enough pain to warrant a ton of investment.

NickTaylor replied on Thursday, November 19, 2009

Yes, I use "lite" lists too, and totally agree that we only want to load the full BO once the user navigates to that particular customer. Some of my BO's contain child lists and can be complicated and heavy.

I agree about the duplication, but I am a convert now. I previously just queried the DB directly from within the form and returned a data-table for the purposes of navigation, but after a few posts on here, I realised that was a very bad idea! ;o) Lite lists work great as they "insulate" the UI from the DB.

Im wondering if there is anything stopping me from just using a simple binding list i.e. BindingList for the purposes of containing navigation ? I wonder then if I could do away with some of the read only lists ?

Thanks,

Nick

JoeFallon1 replied on Thursday, November 19, 2009

I believe you are over thinking this.

Lite lists of Read Only Collection (ROC) with Info classes are the way to go.

If you stick within the framework instead of mixing and matching technologies then you will be more productive.

How would you populate a dataset or binding list if you move to a 3 tier scenario with a remote data portal? No change need with a CSLA ROC. Broken app the other way.

Joe

 

NickTaylor replied on Friday, November 20, 2009

Hi Joe,

 

Ok, there is no doubt that some kind of “lite” list + info object is the right way to go here, however, what I’m trying to do may require the list to be “editable”.

 

I anticipate that when the user opens the customer maintenance form there will be no data present and the bound textboxes will be empty. The user will then have a couple of options to allow the loading of customer data into the form for subsequent maintenance. Either they can type the customer name ( or perhaps the short ID ) into a “quick find” box on the toolbar, or they can select a number of customers via a customer selection form. When the form navigation is populated, they may wish to add other customers to the navigation by typing their names into the quick find box.

 

During the editing session the user may wish to add or delete customers, or indeed change their names, all of which requires the navigation to update. Ideally then I would want a NavigationList class, and a NavigationChild class, and because I want the ability to add and remove customers from this list, and indeed change their names, I would suspect I would require NavigationList to be an EdtableRootCollection object, and the NavigationChild to be an EditableChild object. Obviously however no data is ever written back to the DB from here, and hence the info objects only contain Fetch code and no Update code.

 

As the user navigates around, I would pick up on one of the events, and would load the real BO to which all the form fields are bound. Only the true BO writes data back to the DB.

 

Am I making sense here…!?

 

Thanks,

 

Nick

JoeFallon1 replied on Friday, November 20, 2009

I think I get what you are saying. You do not want to have to re-fetch the ROC just because the user edited the name on the maint screen. You want to update it on the fly.

I recall reading a post by Rocky on this exact topic. It may be in the FAQ or one of his blog posts. He showed a way to handle this.

Joe

 

NickTaylor replied on Friday, November 20, 2009

Yes Joe, that's exactly what I want to do...!

Ill check the FAQ etc. and see what I can find out...

Thanks,

Nick

tiago replied on Friday, November 20, 2009

NickTaylor:

Hi Joe,

 

Ok, there is no doubt that some kind of “lite” list + info object is the right way to go here, however, what I’m trying to do may require the list to be “editable”.

 

I anticipate that when the user opens the customer maintenance form there will be no data present and the bound textboxes will be empty. The user will then have a couple of options to allow the loading of customer data into the form for subsequent maintenance. Either they can type the customer name ( or perhaps the short ID ) into a “quick find” box on the toolbar, or they can select a number of customers via a customer selection form. When the form navigation is populated, they may wish to add other customers to the navigation by typing their names into the quick find box.

 

During the editing session the user may wish to add or delete customers, or indeed change their names, all of which requires the navigation to update. Ideally then I would want a NavigationList class, and a NavigationChild class, and because I want the ability to add and remove customers from this list, and indeed change their names, I would suspect I would require NavigationList to be an EdtableRootCollection object, and the NavigationChild to be an EditableChild object. Obviously however no data is ever written back to the DB from here, and hence the info objects only contain Fetch code and no Update code.

 

As the user navigates around, I would pick up on one of the events, and would load the real BO to which all the form fields are bound. Only the true BO writes data back to the DB.

 

Am I making sense here…!?

 

Thanks,

 

Nick

I'm not sure I follow you. Maybe you want to make something like:

Object name - Stereotype - responsability
UserList - ReadOnlyList - select and display a list of UserInfo objects
UserInfo - ReadOnly - display a few properties of the User object, just enough to select a User
User - EditableRoot - edit a user object

If that is correct, when you change properties of User that are also on UserInfo, you want UserList to display the update information but you don't want to reload UserList from the DB.

If that's the case, refer to a blog entry

Rockford Lhotka - I Am Working On My Using CSLA NET 30 Ebook And Wrote Some Content That I Dont Think Im Going To Use In The Book

http://www.lhotka.net/weblog/IAmWorkingOnMyUsingCSLANET30EbookAndWroteSomeContentThatIDontThinkImGoingToUseInTheBook.aspx

Regards

NickTaylor replied on Sunday, November 22, 2009

Hi Tiago / Joe,

Many thanks for this link, I had tried find the entry and failed. This certainly seems to be a sensible solution to my problem, and I'll go ahead and build something around this.

Thanks again,

Nick

NickTaylor replied on Monday, November 23, 2009

The solution presented by Rocky seems to work great, and I now have a lite list associated with a bindingsource on my windows form for the purposes of providing navigation.

The updating code also works great, however when the lite list gets updated, the binding source's ListChanged event appears not to fire. I can't see an obvious coding error, and I wondered if anyone knows why this might be ?

Thanks,

Nick