Should you return a BindingList from a business layer (or service layer, domain model, etc.)?

Question

I need a BindingList in my UI to provide two-way databinding between my collection and a DataGridView. However, it doesn't seem correct to return a BindingList from your business layer (or domain layer, service layer, data layer, etc.). That is, I'd only be using a BindingList because of a UI requirement, and now this UI need would be coupled with my domain layer.

What is the "proper" decoupled way to do this? Should I be returning an IList and then copying it into a BindingList for presentation purposes? From a real world perspective, is this overhead worth anything?

Answer 1

I think that the domain layer would return the more generic types and whether they be notifying (ObservableCollection<>) or not (IEnumerable<> or IList<>) is up to the requirements.

The UI layer can deal with tranforming them as they wish (or not) into IBindingList if they need that functionality.

We have used BindableLinq to great success to achieve the goals of notifying/synchronised binding list's (possibly with filters) at the UI layer.

Answer 2

There is no copying of an IList (at least I hope you do not really want to create a copy/clone). All you usually do is creating another reference on the same IList object. So returning an IList object is nothing bad.

You may return e.g. an List object and REFER to it out of the bindingList (which is located in your UI).

In my opinion it is better to return an IList (List, HashTable aso) object than an BindingList as you may use the former on different UIs (Console, Web, Win, Service). E.g. using a bindingList would not be of any advantage in a web application.

Answer 3

I don't know what the "proper" way is, but I have used frameworks like CSLA in the past and I know that it used a BindingList and now an ObservableCollection for the business lists. This made using the business objects in the UI very simple as the UI would update when items were added or removed from the lists. If you return an IList and then copy it into a BindingList you need to manually monitor and handle changes to the IList and translate those to the BindingList. My personal preference is to have a feature rich business layer when possible which would use a BindingList or ObservableCollection to present the business layer to the UI.

Answer 4

If you want the UI elements to edit the business model without implementing your own event handlers, the business model has to have a BindingList.

Anytime you do something like new BindingList<MyWidget>( list ) you are decoupling the binding from the root list. If an item is edited, it will all work fine, but additions and deletions will not be reflected in the original list.

I recently tried implementing something like this, by tapping into the BindingList ListChanged event, which updated my model to reflect the BindingList changes, but if the model was changed by the controller it didn't update the BindingList in the UI.

You could produce special accessors to your lists that raise events every time you add or remove items from the list, but this is just re-inventing the BindingList wheel with more overhead.