Building ASP.NET Applications Using MVP Architecture: Part 1

This article is all about building ASP.NET applications using the MVP Architecture.

I have divided this article into the 2 parts:

• In part 1 we will understand why MVP is required; what are all the problems with traditional 3-Tier architecture and how MVP overcomes this.
• In part 2 we will do a code walkthrough and learn how to write ASP.NET applications in the MVP architecture.

In one of my previous articles I spoke about 3-tier architecture and its maintenance capabilities.

What is MVP?

MVP is nothing but a flavor of 3-Tier architecture, which means the system is divided into 3 layers, each layer performing a specific task.

What makes it different from normal 3-Tier applications



In simple 3-Tier architecture UI asks BAL for final data which in turn communicates with DAL and in response DAL return the data to BAL which comes to UI where it will be displayed.

What are the problems with that architecture?

If we are working with the traditional 3-Tier architecture, which means:

I. Every layer knows about the next layer, which means:

• The UI knows it will get data from the BAL
• The BAL knows it has to communicate with the DAL
• But in return the next layer won't be aware of the calls to a layer; for example: the BAL never cares about who called it, it just returns.

II. We are doing 4 things in the UI:

1. Bindings: We bind control data to entities and vice versa.
2. Focus Control: Set Focus to the controls.
3. Display Control: Show/Hide Controls.
4. Event Handlers: To perform actions.
5. Decision Making: Decides what to do when.

Everything looks great except Decision making

And this creates 3 major issues

1. Cluttered UI code - regardless of how hard we try, the UI will always end up with some logical code.

Reason for such thing is final decision making can only be performed in UI.

Consider following examples

·         Consider to make a validation check prior to final update. Definitely we write the validation code in Business layer but the final decision, like what to do if fail and what to do if pass is taken by UI again ·         We are displaying different types of customers with different colors, like we are showing Gold with green, Silver with yellow and normal with white. ·         We are displaying amounts with different colors as per their value. In both cases, entire coloring and looping logic did at UI level.       Means 10% logic in UI and 90% in BAL.

If we talk in real world example, an old man asks his son to bring a Taj Mahal Poster from market and finally when he receives it, he is the one who decides where to place the poster according to its size

2. Difficult to work with multi UI- 

Consider we have a requirement where we have to build one more UI showing Gold Customers with blue color and silver with green, Or may be like where we have to build a thick client for the same, 

Yes definitely Copy-Paste will be a solution, but it makes management difficult as 10% of our logic(of decision making) is still in UI and any changes (for an instance if we don't want a validation for particular field any more) requires changes in both.

3. Unit testing of individual layers is difficult since Business logic is present in both layers.

Components of MVP How MVP solves this problem?

Components of MVP

1.  Model – Business Layer which does all the tasks related to business logic. Like validations, algorithms.
2. View – UI with which end user interacts. View just passes there event to next layer i.e., Presenter.
3. Presenter – Handles UI Logic and  talks to Model(directly) and view(indirectly –we will see how as we move further)

Note:

1. Some people used to divide Model as Business Access Layer + Business Objects + Data Access Layer, where some like Business Access Layer + Business Objects and use to put 4th Layer called Data Access Layer.

2. UI is broken into 2 parts

• View - Which will be just for display purpose and only passes its event to next part called Presenter.(It will still does three more tasks like Binding, Display Control and Focus Control) 
• Presenter – Which will handle UI logic by handling UI events and deciding what do in response to business data returned(by Model by calling appropriate method in View)

Problem solved

In MVP Decision making is taken away from UI by placing an interface between Presenter and View called ViewInterfaces.

How it works

1. In MVP, View knows who will handle its events and take decisions (here it's presenter). So view just call methods created in the presenter.
2. Presenter talk to model which performs the business logic
3. Model communicates with database/filesystem/service and collects the data and sends it back to Presenter.
4. Presenter use the data returned by Model and call the methods created in the View (Indirectly through interfaces).

Note: All the public methods in Presenter has to be with return type void

Conclusion

Now decision making can be done at Presenter as it has access to view methods.

We will do a code walk and learn how to write an asp.net application in MVP architecture in my next article.

In the mean time please try to understand 3-Tier architecture using asp.net.

Hope you enjoyed reading part1 of article.

Don't forget to put some good comments.