Building ASP.NET Applications Using MVP Architecture: Part 2

Please go through the Part 1 first.

In my previous article I talked about why MVP is required, how it overcomes the problem of cluttered UI code and Unit Testing.

In this article we will go step-by-step and see how ASP.Net MVP applications can be developed.

What are we developing?

We are about to develop a customer screen with the 2 functionalities:

1. Allow adding new customers with details like, Customer Type (Gold, Silver or Normal), Customer Code (must be a 5-letter string), Amount and Age.
   (All are compulsory fields.)
    
2. Shows the existing customer in a grid in the following format:
   
   a. Show them in a green color if they are gold, in yellow if silver.
   b. The Amount will be shown in green if it's more than 5000, in blue if between 1000 and 5000 and in red if below 1000.

The output should look like this:



Development

• Every software development starts with database development.
  
  Create a Customer Table as follows:
  
  
   
• Let's create a Visual Studio solution with four folders
  
  
  
  
  Let's start with the code development.
   
• From where to start? Model, Presenter or View? As the name suggests the Model comes first.
  
  1. Model
  
  a. Entities
  
  A class with set and get properties to represent an in memory representation of data.
  
  
  
  b. Data Access Layer
  
  It will talk to the database and does the necessary tasks.
  
  
  
  c. Business Access Layer

         Validations and other business logics are performed here.

2. ViewInterfaces

Before moving into the Presenter we should develop ViewInterfaces, so that we are not required to worry about Views while developing Presenter (because View will extend these interfaces).

As I said in Part 1 of this article, the MVP View will have only 4 kinds of methods; they are:

1. Bindings: We bind control data to the entities and vice versa.
2. Focus Control: Set focus to the controls.
3. Display Control: Show/Hide controls.
4. Event Handlers: To perform actions by calling Presenter methods.
   

(Decision making is taken away from View to Presenter)

So our task is to identify those methods and put them in an interface.



3. Presenter

OK, everything seems settled now, the Presenter knows how to access the methods in the UI (i.e., via ViewInterfaces).

But there is a problem!!

We know which interface to refer to but where should it be referenced from, in other words an interface must be initialized to some class but where it's done?



OK now we have referenced the view, which we can use to call methods defined in the view while writing the business logic.

Let take a look into some of the presenter methods.




4. View

It's time to build final component called View.

First thing we need here is reference to presenter.

You can see we are passing "this" as a parameter to the Presenter object so that in the Presenter we get the reference to view.

Let's take a look at the part of View.

As you can see we don't have any kind of decision making in view.

That's it we are done with the development.

Conclusion

In short MVP 

• Makes UI less cluttered 
• Makes Unit testing easier as decision making codes are moved into presenter.
• If you want to create a new UI with some other color scheme or want to create a thick client application, just derive your new UI with ViewInterface and override methods and that's it

Refer following link to see how to perform unit testing using visual studio.

http://msdn.microsoft.com/en-us/library/ms379625(v=vs.80).aspx

Hope you enjoyed reading the article.

Don't forget to share the link and put some good comments.