Archive for the ‘Architechture’ Category

My MVP Wireframe/Walkthrough

Thursday, March 13th, 2008

My friend Iftekhar was asking for a simple wireframe/walkthrough of MVP pattern. So here it is for him (and anybody else if they need ;) ).

First I created a website. It has one page ‘Default.aspx’ with two labels, one textbox, one dropdown and one button. Then I created 2 class library projects for presenter and Viewfactory (interfaces for each webpage). I created one IDefault interfce and implemented it in the code behind of ‘Default.aspx’.

IDefault interface:

public interface IDefault

string username { get;set;}

string role { get;set;}

void DisablePanel();

void ShowMessage(string msg);

void ShowHistory(string msg);


Now I also created a presenter class for the default page. It has a private IDefault property. Now the codebehind will instantiate the presenter by passing itself to it. The presenter will initialize its private IDefault with the view instance.

The Default.aspx.cs file:

public partial class _Default : System.Web.UI.Page, IDefault

DefaultPresenter _presenter;

protected void Page_Init(object sender, EventArgs e)

_presenter = new DefaultPresenter(this);


protected void Page_Load(object sender, EventArgs e)

username = TextBox1.Text.ToString();

role = drpList1.SelectedValue.ToString();



On the other hand the presenter class is as follows –

public class DefaultPresenter

Private IDefault _default;

public DefaultPresenter(IDefault def)

_default = def;


Now every business logic Default.aspx.cs needs to perform to update the GUI, the presenter will have it done with the interface. This is the basic beauty in it. The view became pluggable and more testable. It’s like instead of going and look for the business logic classes and call it to view, view itself goes to the logic and let that do its work in its own place. Once presenter is done with all its hocus pocus it just calls methods of the interface ( actually the view) to update the UI components accordingly.

Now to test the Model, I am keeping track of the value enter in textbox and selected value of the drop down. As its not directly connected to manipulating the UI components, I put it in the model. Presenter just ask the model to log the event and if it wants to show it to view, model returns something. Here also I have a IHistory for more testability and cleanliness.

The History and IHistory:

public interface IHistory
string Createhistory(string username, string role);

public class History:IHistory

#region IHistory Members

public string Createhistory(string username, string role)


return “No open session”;


return String.Format(“{0} logged in at {1} as {2}”, username, DateTime.Now, role);



In a nutshell –

  • First design your view interfaces,
  • create web pages implementing them ( or you can design the aspx/ascx with the designer first then write interfaces. I donno what the wise and learned people will say, I just didn’t get any difference, though most of the time it depends on what are you doing).
  • Then create presenter classes who will work with the interface to service the view. Write methods to calculate everything for the desired behavior of view in the presenter and at the end just call the interface methods so that view gets updated.
  • And if you need some more things you want to code about, do it in model.

Viola, just 3/4 projects and you are done.

The full solution file is here.

I am a humble learner. So if I made some mistakes or you would like some other angles to look at it, do say.

Some more reading on Dependency Injection and MVP

Wednesday, March 12th, 2008

In my new office I was studying the following articles.


I came to read these when I started to study about Unit Testing on ASP.NET projects. And here all use MVP. Its all new experience for me.
I have always been a fan of NTiers applications pattern. But now I am required to work on MVP with Feels little out of my normal brainwave, but its stimulating. Stepping out of my comfort zone, thinking architectures in a sort of reverse way, or top-down and bottom up in parallel. Currently the architectures I have managed to put up of Dependency Injection is through constructor injection. I am loving how pluggable and traceable the solution is becoming using MVP.

I am trying to explain or map MVP from a NTierian’s point of view. Lets say a solution have 4 projects (DAL, BLL, Facade and website). In NTiers Website will communicate with Facade. Facade will communication with BLL and website. BLL will communicate with DAL and facade. In NTier BLL handles the business logic with Data layer. Website’s ASPX pages handles the UI related business logic themselves in their code-behind files.

Now say if I am to translate the design in MVP. There is no 101 relation there. See the website will be called the ‘VIEW‘ but it will not handle the business logic related to the population of the GUI, a ‘PRESENTER‘ will do it with the help of the interfaces for each view ( Factory method). Now ‘MODEL‘ will act as the facade here who will handle all sorts of other logics, both Presenter and DAL have communication with it. Good to know that the DAL will always be DAL, no matter what framework it is in.

The work flow of MVP and MVC from Nikola Malovic

Actually I don’t know if I am right or wrong. Its just 3 to 4 days I am playing with MVP and this is what I felt. I am a complete beginner in t, so if anyone is reading do leave your view on it, and correct me if you find me wrong. It will be highly appreciated. My MVP readings will be found at Delicious.

I am working on a sample project where I am using MVP. I will write about it once i am done :).

For shortnote there are 3 types of dependency injection – Constructor Injection(I use it for NMock Unit testing my presenters), Setter Injection(Spring.NET framework), and Interface Injection(Avalon). I am still not wise enough to shade some lights on those. I will do that someday.