Exposing business objects to the UI

I've been working the past few months with the Composite UI Application Block (CAB) and the Smart Client Software Factory (SCSF). They're all great but the documentation throws me for a loop sometimes.

In an entry called "Map Business Entities into User Interface Elements" it suggests creating a mapper class and using it to convert some business object into a UI one. This makes sense however the implementation and references cause my head to hurt.

In a typical MVP pattern, you have the Model (your business object), the View (the UI), and the Presenter (a go-between guy). The presenter knows about both the view and the model. It needs to inform the model to update based on messages recieved from the view, and tell the view about changes in the model. Neither the model or the view have any knowledge of each other.

Introduce the mapper which knows about the Model and the View. This is the other side of the equation so when given a business object, the mapper will spit out a drop down list, a grid control, or whatever UI element is appropriate to display something from the business layer (say a list of customers).

In the example Microsoft provides via the guidance package, the view has a method that accepts a business object which then calls the mapper to translate it into a ListViewItem. The view then updates its UI control (a ListView control) by adding list items to it created by the mapper.

However this means that you're exposing you business objects to the user interface, which creates a coupling between the UI and the business layer (at least from a deployment perspective). If you don't do it this way you have to have the presenter (which should know about domain objects so that's ok) update the view but what is it going to update it with? Certainly not a ListViewItem which will make the presenter dependent on the windows form control assemblies.

Without creating a intermediate object (like a CustomerDTO with nothing but getters/setters) are we really bound to have the UI reference the business layer and is the documentation here really a best practice for exposing business objects to the UI? How do you guys do it?

2 Comments

  • Have you considered using the Visitor pattern for this? So you'd have an IViewItem that the presenter interacts with and youd have an IPresenterVisitor that you would have your control interact with. Create controls that derive from the controls you are using and implement the interface on them and then have override the events in the control to pass itself to the presenter for model interaction (like databinding and so on). I use this to accomodate databinding collections to asp.netforms so that I don't have to have a kind of placeholder object during binding to allow the presenter to be viewtype agnostic.

    Do I misunderstand?

  • I prefer separating business objects from GUI elements. Data binding GUI controls such as data grid favors data tables so that controls can re-draw themselves on changes to underlying data source. However, this can be achieved by implementing INotifyPropertyChanged interface by business objects but in that case business objects are doing the work of entities rather than its sole responsibility of implementing business logic.

    I've not yet found suitable solution to how I can completely separate my domain model to GUI. One design I've tried is extract business entities from business objects. Entities can be use by GUI controls to display data. Opinions from others appreciated.

Comments have been disabled for this content.