Introduction
With the advent of newer technology and framework, architecture design has become very important for development of application. Utilization of the same business functionality across platform based Web application and smart client needs a tactful architecture. Another challenge has been to fit in unit testing framework with the application. MVC failed to achieve this. MVP proved to be a boon to achieve this milestone.
MVP vs. MVC
Demerits of Model View Controller
- Unit testing not possible. Websites do not have a DLL of their own. To achieve this, websites need to be converted to web applications.
- UI tightly coupled with controller and most of the business logic resides in UI.
- UI contains intrinsic object of .NET, thus making unit testing impossible.
- Work stream distribution is next to impossible.
Why MVP ?
- Work stream distribution for Designer (UI) and Developer.
- View is decoupled from Presenter and Model (Service & Data Access).
- This design helps smart client and web application to utilize the common Presenter and Model.
- Unit testing framework goes well with Presenter.
- Presenter contains the business logic and the reference of model.
Logical Architecture
Physical Architecture
Best Practices
Data Access Layer
Service Layer
- Service contains a list of all operations which is used by an application.
- One or more web sites or windows application can utilize these services.
- Region out each functions for maintenance purposes.
- Service layer provides an interface which gives access to all data related operations (i.e. from different conventional data sources or by referencing components accessing various data sources).
Presenter Layer
- Create one
BasePresenter
which will have all the common attributes across application such as custom exception or initialization of service class.
public class BasePresenter
{
public IServiceProvider m_Service=null;
public BasePresenter()
{
m_Service=new Services.ServiceProvider()
}
public void ProcessPresenterLayerException()
{
}
}
- Must have
public
methods and private
methods as given below:
Public void LoadCustomerList()
{
Ilist<demand> customerList = new list<demand>();
customerList = GetCustomerList(m_View.CustomerID){}
}
Public void SortCustomerList(){}
Public void PagingCustomerList(){}
Private IList<demand> GetCustomerList(int customerID){}
Public
methods exposed to 'View' must not have any return parameter or input parameter. - Name
public
method that relate to UI operation terminology terms (Load
/Populate
/Add
/Remove
) - Name
private
method that relate to back-end operation it actually does such as Get
/Insert
/Update
/Delete
- Make sure
public
methods have try catch
block while called private
methods don't. - Do not make use of intrinsic .NET method calls, e.g.
httpContext.Current.Server.mappath/Server.transfer/server.execute
, etc.
Domain: Business Entity
- Initialize
private
members wherever possible.
private int _demandID = int.MinValue;
private string _demandName = string.Empty;
- Make use of parameterized constructor and default constructor. Create cyclic constructor if possible.
Public Sample (int a, int b, int c): base (a)
{
……
}
public Sample(int a, int b, int c, int d):this(a,b,c)
{
..
}
References