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

Official versions are :

- the desktop/server version that everyone knows.

- CoreCLR - the Silverlight version.

- the version from .NET Compact framework  (which runs on windows mobile phones, Xbox 360 etc)

- the version implemented in the .NET Micro framework.

 

The more the merrier, i guess.

You can use Gmail as SMTP server to send emails. When i launched Topi last week i decided to use Gmail instead of the mail server of the hosting company (since Gmail is much more reliable). To configure it you can simply drop this into web.config  (replace test with actual account data):

<system.net>
    <mailSettings>
        <smtp deliveryMethod="Network" from="test@gmail.com">
            <network host="smtp.googlemail.com" port="587" defaultCredentials="false" userName="test@gmail.com" password="test"/>
        </smtp>
    </mailSettings>
</system.net>

 

Make sure you use port 587 because it won't work with the other one. Also i decided to use log4net to receive logging data for email so, since log4net Smtp appender doesn't support TLS authentification, i have added this to Microruntime.

My latest project is now live. Topi is a microblogging platform for the romanian market. It was a single man effort (except for some graphic design which was made by my wife) and i'm happy with the result.

So, if you speak romanian and you're interested in a Twitter like service, then please also look at Topi.

 

Dawn of night was ok but it went downhill from there. On a sidenote i have started reading the latest Drizzt trilogy.