Thursday 15 November 2012

MVC or MVP ?

MVC and MVP both terms are correct but they have there own flavor. These are two different architectural pattern used in building a robust decoupled system in modern days. If you are building an application in a decoupled manner then definitely you will get following advantages --

1. It will decrease your maintenance cost.
2. Alteration and Modification will not hamper other modules thus making the developers life easy.
3. It will allow you to do parallel development and thus reducing the development time significantly.

and so on...

So basically MVC stands for Model View Controller and MVP stands for Model View Presenter.
The main difference between the two is how the manager (controller/presenter) sits in the overall architecture

MVC pattern puts the controller as the main ‘guy’ in charge for running the show. All application request comes through straight to the controller, and it will decide what to do with the request. One of the old patter used to achieve separation of concerns.

MVP (Supervising Controller) on the other hand, doesn't mind for the View to take on a bigger role. View is the first object instantiated in the execution pipeline, which then responsible for passing any events that happens on itself to the Presenter. Advanced form of MVC.




Individual responsibilities of each layers --

MVC : 

View:
1. Renders data
2. Receives events
3. Have basic validations
4. Can interact with Model directly

Controller:
1. Helps view in complex design making tasks
2. Communicate with model
3. Performs complex validation tasks

Model:
1. Communicate with Database Layer and send appropriate data to the requester (View/Controller)

MVP :

View: 
1. Renders data
2. Receives events
3. Have basic validations


Controller:
1. Helps view in complex design making tasks
2. Communicate with model
3. Performs complex validation tasks

Model:
1. Communicate with Database Layer and send appropriate data to the requester (Controller)



Interface


An interface has the following properties:
  • An interface is like an abstract base class: any non-abstract type that implements the interface must implement all its members.
  • An interface cannot be instantiated directly.
  • Interfaces can contain events, indexers, methods, and properties.
  • Interfaces contain no implementation of methods.
  • Classes and structs can implement more than one interface.
  • An interface itself can inherit from multiple interfaces.
     
Classes and structs implement interfaces in a manner similar to how classes inherit a base class or struct, with two exceptions:
  • A class or struct can implement more than one interface.
  • When a class or struct implements an interface, it receives only the method names and signatures, because the interface itself contains no implementations, as shown in the following example.
     
Example:
 
public class Car : IEquatable<Car>
{
    public string Make {get; set;}
    public string Model { get; set; }
    public string Year { get; set; }

    // Implementation of IEquatable<T> interface
    public bool Equals(Car car)
    {
        if (this.Make == car.Make &&
            this.Model == car.Model &&
            this.Year == car.Year)
        {
            return true;
        }
        else
            return false;
    }
}


The IEquatable(Of T) interface announces to the user of the object that the object can determine whether it is equal to other objects of the same type, and the user of the interface does not have to know how this is implemented.