View Presenter BusinessObject (aka VPBO) VPBO (for short) is an attempt to describe a pattern for layer structure and interaction inside of a system. It's like MVP but with a few tweaks. Notice that depending of the system, the entry point can be either the View ( in a regular ASP.NET WebForms app the request is routed to the view) or the Presenter ( in Windows Forms, WPF we call the presenter which instantiates the view).
Here's a diagram of interaction :
1.
View . Responsibilities :
- describe the UI (obviously).
- basic control validation.
2.
Presenter - the most important piece of the diagram. Responsibilities :
- invoke the business object(s) and get the data required by the view. Remember there is no model so you may need to invoke multiple business objects.
- data caching could be implemented here if it's necessary.
- using the view instance set the data in the view's controls.
- do logical data validation.
- pass to data back to BO to persist it.
3.
Business Object. Responsibilities :
- logic goes here.
How is this different from MVP/different stuff ?
- first of all notice that there is no Model. Nor there is a interface that the View must implement. This means less code to write/change and worry about.
- from my point of view, with VPBO i'm trying to describe a way for a nice layered system implemented with the least amount of code.
- some stuff are missing compared with MVP: there isn't a way to test UI.
- should the presenter contain any kind of logic ? It can contain "logic" pertaining to his associated view. No business logic. Also this logic should be written without referencing UI controls so it can be unit tested.
- the presenter can be best described as a orchestrator. Get the BO data, display it, validate it, pass it back to BO.
- if the view is complex you are encouraged to create a master presenter along with multiple smaller presenter which handle specific UI functionality.The view knows only abour the master presenter. This represents a better way to mitigate complexity. Because "rich" UI requires a ton of code, moving that code from view to presenter(s) is a better way to mitigate complexity.
- the interaction between view and presenter can, basically, be "described" with 2 methods : Display and Save. Add more methods depending on your UI requirements. Also note that defining a interface is strictly optional.
Small sample using WPF here
Subscribe