Databinding When View Differs From Model

Question

I have an entity Customer. Customer has a collection of Accounts. I have corresponding classes. The Customer class has-a List<Accounts>.

I have two views. First page shows the Customer's name, address etc. Each field is data-bound to corresponding property on the Customer object. There is a link show-accounts. On clicking that link, you get a second view. There is a grid which is data-bound to the Accounts property on the customer object.

Now I need to provide a No-of-accounts label on the first view. Problem is there is no such property on the Customer business object. I have a few approaches to do so, but I do not like either of them.

1. Add a property AccountCount on Customer object. But it is artificial. What if tomorrow I need to show the Balance in the highest account?

2. Use the Count property on the Accounts list. But this needs the list to be populated. My users rarely view the whole list of accounts. I do not see the point of loading the entire accounts table just to show the count.

3. Once databinding is complete, make a seperate call from UI directly to Data-Layer. Let a query fetch just the details. This defeats the whole layered/tired architecture. Soon everything falls into chaos, with everyone maintaining this code firing their own queries.

4. Rather that Data Binding to the business model Customer, I can Data bind to a CustomerViewModel class. This class can have the artificial CountOfAccounts property. This keeps UI specific code separate from BL. Problem is ViewModel class depends on the BO layer, but the BO does not have that property. We can populate the Accounts list and fetch the count from there, but fetching a table for just getting the Count seems overkill.

Question

What can I do when my UI wants things different from the Business Model?

Answer 1

What you are looking for is the concept of a ViewModel.

This is an object that contains only data that the view is interested in, and is very often not a 1 to 1 mapping with a business or domain model. It may be a cut down version of a business model, it may be an amalgamation of multiple different business models.

If your view needs a count, this can represented in the ViewModel. If the view also needs to display all the accounts, then the count can just be pulled from ViewModel.Accounts.Count() (or whatever syntax for your language).

If the view does not need the account list, then it would make sense to then have the account represented by a "NumberofAccounts" (or whatever name you like) property.

• inquisitive: hi, thanks. problem is with NumberofAccounts property. How does that fetch data? It has only the Business Model to talk to. BO does not have that property. ViewModel.Accounts.Count() has the drawback of populating the accounts list, all for just fetching the count. :(
• RubberDuck: That's where the "amalgamation" part comes in. The count data for the ViewModel doesn't necessarily come from the existing Accounts business model.
• inquisitive: any hint on on where can I fetch it from? I cant directly hit database. Business model does not have it. so how? The ViewModel can use multiple business-model objects as backend. But I cant use the whole Accounts list (needs useless loading). What can be clean approach. please...
• ozz: Well you need to query the database for it obviously. a select count query would get it without retrieving the actual rows.