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.