Marius Gheorghe

Building software : make it work, make it good, make it fast

Model Viewer Presenter. Take 3

In the past months i have been implementing in my projects MVP Passive View. You can find the description here. It works pretty good (in Windows Forms and Silverlight projects) and , from my point of view, it's far better than the "other" MVP implementation because the view remains without any logic responsability.

Here's how i implement it. Basically for each view action there is a associated method in the presenter.

public class OrderViewPresenter
  private OrderViewDialog dialog = null;

   public OrderViewPresenter(OrderViewDialog d) 

dialog = d; 

  public void DisplayData()
//invoke the Order Business Object and load the order
Order o = .......
d.textBoxOrderDate = o.OrderDate;

 public void CreateNewOrder()
//create the new order base on the dialog data


First and most important thing somebody should learn as a programmer is....

....Separation of concerns

As a employee of a company which does outsourcing, i get to work with a lot with bad smelly, rotten code. Things like reinventing the whell (like rewriting a function which already exists in the framework), breaking the DRY principle (copy & paste programming) end up beeing just small nuisances for me. What really irks me is code that breaks the separation of concerns. All too often i end up debugging code written by so called "senior programmers" which looks something like this : - big function (+ 200 LOC) - everything is in the event handler in the UI. (buttonOk_OnClick) - read UI data - go to database to retrieve some data - add some logic - go again to the database to retrieve another needed data - add more logic, also using some hardcoded values. -save into database I hate this kind of code. Separation of concerns should be the first thing someone should learn when he writes code for a living.

Model Viewer Presenter. Take 1

I have decided to write some posts on Model Viewer Presenter. If you don't know, Model Viewer Presenter ( MVP from now one for the sake of my fingers) is a pattern which , among other things, "dictates" how to separate logic from UI. You can think of it as a way to "implement" separation of concerns. Here are the MVP pieces:

- Model : this is you business object.
- View : this is the UI object (Windows/Web form, PocketPC window etc)
- Presenter (or "the glue") : this is the object which gets the data from the model, modifies it and passes it to the view.

One of the things for which MVP is touted is "presenter reusability". Write you presenters correctly, they say, (without referencing the View from the Presenter) and , when you port the application from other platforms, you just need to rewrite the view. Personally i think that's wrong ( in the sense that you won't need this). Web applications are different from desktop applications which are different from mobile applications. If you "port" a application from a platform to another this "presenter reusability" thingie won't hold.

Here is an example : Shopkeeper is a MVP web application.

Also here is the "port" to the desktop platform (a smart client application)

The web application has 10 views/presenters. The desktop application has....3 views/presenters. Yeap...that's right. That functionality was encapsulated, in the case of the desktop application, in just 3 views/presenters.
Conclusions :
- platforms are different (suprise heh ?!)
- use MVP for what it really is. The best way to enforce separation of concerns.