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?

Published Friday, September 08, 2006 3:42 PM by Bil Simser
Filed under: , ,

Comments

Friday, September 08, 2006 7:20 PM by Guy Peled

# re: Exposing business objects to the UI

I wanted to present you with a very interesting development environment that is emerging that could be useful for you. You can see here (http://samples.visualwebgui.com/mainform.wgx) a live sample of what can be done with the technology. This application was developed the same way you would develop a WinForms application. I invite you to read more about this new development environment here http://www.visualwebgui.com. Thanks Guy
Saturday, September 09, 2006 3:01 AM by Mike

# re: Exposing business objects to the UI

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?
Saturday, September 09, 2006 6:27 AM by Udi Dahan - The Software Simplist

# re: Exposing business objects to the UI

Although Martin Fowler recently split MVP into two different patterns (Supervising Controller and Passive View), you'll probably find that Supervising Controller keeps most to the MVP spirit. In Supervising Controller, there is no need for the Mapper class. By taking into account Udi's First Principle of Design and its Extension, we introduce a "view interface" on which the Presenter depends. The Presenter would not depend on the concrete view. This interface would probably have properties or methods that accept model objects as parameters, as well as events like "SaveRequested" that would be raised by the concrete view when a button was pressed. The advantages of this approach include the fact that the Presenter is entirely decoupled from the presentation technology, making it highly testable. The concrete view, which would implement the view interface, would depend upon the model objects as well (otherwise the above wouldn't work). You seem to view this as undesirable, could you please explain why. I assume that you are discussing a N-Tier deployment model. If this is the case, consider the fact that the model objects deployed on the client tier may be different from those on the server tier. There is good reason to do this (and a topic suited for a post in and of itself), but in short think of it this way: The context of use for these model objects on the client is much different (presentation/validation oriented) than on the server (persistence + deeper validation, as well as reporting). Having a separate model for each tier allows you to best handle each context. This, in turn, requires a mapper to transform one model to the other - so it appears that the mapper stays either way :)