Over the years I have mentored many developers on using design patterns

and best practices. One question that keeps coming up over and over
again is: What are the differences between the Model View Controller
(MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer
is more complex than what you would suspect. Part of reasons I think many
developers shy away from using either pattern is the confusion over the
differences.
Before we dig into the differences lets examine how the patterns work and
the key benefits to using either one. Both (MVC & MVP) patterns have
been use for several years and address a key OO principal namely
separation of concerns between the UI and the business layers. There are
a number of frameworks is use today that based on these patterns
including: JAVA Struts, ROR, Microsoft Smart Client Software Factory
(CAB), Microsoft Web Client Software Factory, and the recently
announced ASP.Net MVC framework.
Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating
the UI (View) from its business layer (Model). The pattern separates
responsibilities across three components: the view is responsible for
rending UI elements, the controller is responsible for responding to UI
actions, and the model is responsible for business behaviors and state
management. In most implementation all three components can directly
interact with each other and in some implementations the controller is
responsible for determining which view to display (Front Controller Pattern),
Model View Presenter (MVP) Pattern

The MVP pattern is a UI presentation pattern based on the concepts of the
MVC pattern. The pattern separates responsibilities across four
components: the view is responsible for rending UI elements, the view
interface is used to loosely couple the presenter from its view, the
presenter is responsible for interacting between the view/model, and the
model is responsible for business behaviors and state management. In
some implementations the presenter interacts with a service (controller)
layer to retrieve/persist the model. The view interface and service layer are
commonly used to make writing unit tests for the presenter and the model
easier.
Key Benefits
Before using any pattern a developers needs to consider the pros and cons
of using it. There are a number of key benefits to using either the MVC or
MVP pattern (See list below). But, there also a few draw backs to consider.
The biggest drawbacks are additional complexity and learning curve. While
the patterns may not be appropriate for simple solutions; advance solutions
can greatly benefit from using the pattern. Im my experience a have seen a
few solutions eliminate a large amount of complexity but being re-factored
to use either pattern.

Loose coupling The presenter/controller are an intermediary
between the UI code and the model. This allows the view and the model
to evolve independently of each other.
Clear separation of concerns/responsibility
o UI (Form or Page) Responsible for rending UI elements
o Presenter/controller Responsible for reacting to UI events and
interacts with the model
o Model Responsible for business behaviors and state
management
Test Driven By isolating each major component (UI,
Presenter/controller, and model) it is easier to write unit tests. This is
especially true when using the MVP pattern which only interacts with the
view using an interface.
Code Reuse By using a separation of concerns/responsible design
approach you will increase code reuse. This is especially true when
using a full blown domain model and keeping all the business/state
management logic where it belongs.
Hide Data Access Using these patterns forces you to put the data
access code where it belongs in a data access layer. There a number of
other patterns that typical works with the MVP/MVC pattern for data
access. Two of the most common ones are repository and unit of work.
(See Martin Fowler Patterns of Enterprise Application Architecture for
more details)
Flexibility/Adaptable By isolating most of your code into the
presenter/controller and model components your code base is more
adaptable to change. For example consider how much UI and data
access technologies have changed over the years and the number of
choices we have available today. A properly design solution using MVC
or MVP can support multi UI and data access technologies at the same
time.
Key Differences
So what really are the differences between the MVC and MVP pattern.
Actually there are not a whole lot of differences between them. Both
patterns focus on separating responsibility across multi components and
promote loosely coupling the UI (View) from the business layer
(Model). The major differences are how the pattern is implemented and in
some advanced scenarios you need both presenters and controllers.

Here are the key differences between the patterns:

MVP Pattern
o View is more loosely coupled to the model. The presenter is
responsible for binding the model to the view.
o Easier to unit test because interaction with the view is through an
interface
o Usually view to presenter map one to one. Complex views may
have multi presenters.

MVC Pattern
o Controller are based on behaviors and can be shared across
views
o Can be responsible for determining which view to display (Front
Controller Pattern)

Hopefully you found this post interesting and it helped clarify the
differences between the MVC and MVP pattern. If not, do not be
discouraged patterns are powerful tools that can be hard to use sometimes.
One thing to remember is that a pattern is a blue print and not an out of the
box solutions. Developers should use them as a guide and modify the
implementation according to their problem domain.



1
more likely, you should tag this as homework as it really sounds like that's why you are
asking. Analog File Sep 15 '12 at 12:13
1 Answer
activeoldestvotes
up
vote10down
voteaccepted
Abstract Factory
The Abstract Factory pattern provides an interface for creating
families of related or dependent objects without specifying their
concrete classes. The client is decoupled from any of the specifics of
the concrete object obtained from the factory.
Adapter
The Adapter design pattern converts the interface of a class into
another interface that clients expect. Adapter lets classes work
together that couldnt otherwise because of incompatible interfaces. It
decouples the client from the class of the targeted object.
Chain of Responsibility
The Chain of Responsibility design pattern decouples the sender of a
request from its receiver by giving more than one object a chance to
handle the request. The pattern chains the receiving objects together
and passes the request along the chain until an object handles it. Each
object in the chain either handles the request or passes it to the next
object in the chain.
Command
The Command design pattern encapsulates a request as an object,
thereby letting you parameterize clients with different requests, queue
or log requests, and support undoable operations. The request object
binds together one or more actions on a specific receiver. The
Command pattern separates an object making a request from the
objects that receive and execute that request.
Composite
The Composite design pattern composes related objects into tree
structures to represent part-whole hierarchies. The pattern lets clients
treat individual objects and compositions of objects uniformly. The
Composite pattern is part of the Model-View-Controller aggregate
pattern.
Decorator
The Decorator design pattern attaches additional responsibilities to an
object dynamically. Decorators provide a flexible alternative to
subclassing for extending functionality. As does subclassing,
adaptation of the Decorator pattern allows you to incorporate new
behavior without modifying existing code. Decorators wrap an object
of the class whose behavior they extend. They implement the same
interface as the object they wrap and add their own behavior either
before or after delegating a task to the wrapped object. The Decorator
pattern expresses the design principle that classes should be open to
extension but closed to modification.
Facade
The Facade design pattern provides a unified interface to a set of
interfaces in a subsystem. The pattern defines a higher-level interface
that makes the subsystem easier to use by reducing complexity and
hiding the communication and dependencies between subsystems.
Iterator
The Iterator design pattern provides a way to access the elements of
an aggregate object (that is, a collection) sequentially without
exposing its underlying representation. The Iterator pattern transfers
the responsibility for accessing and traversing the elements of a
collection from the collection itself to an iterator object. The Iterator
defines an interface for accessing collection elements and keeps track
of the current element. Different iterators can carry out different
traversal policies.
Mediator
The Mediator design pattern defines an object that encapsulates how a
set of objects interact. Mediator promotes loose coupling by keeping
objects from referring to each other explicitly, and it lets you vary
their interaction independently. These objects can thus remain more
reusable. A "mediator object in this pattern centralizes complex
communication and control logic between objects in a system. These
objects tell the mediator object when their state changes and, in turn,
respond to requests from the mediator object.
Memento
The Memento pattern captures and externalizes an objects internal
statewithout violating encapsulationso that the object can be
restored to this state later. The Memento pattern keeps the important
state of a key object external from that object to maintain cohesion.
Observer
The Observer design pattern defines a one-to-many dependency
between objects so that when one object changes state, all its
dependents are notified and updated automatically. The Observer
pattern is essentially a publish-and-subscribe model in which the
subject and its observers are loosely coupled. Communication can
take place between the observing and observed objects without either
needing to know much about the other.
Proxy
The Proxy design pattern provides a surrogate, or placeholder, for
another object in order to control access to that other object. You use
this pattern to create a representative, or proxy, object that controls
access to another object, which may be remote, expensive to create, or
in need of securing. This pattern is structurally similar to the
Decorator pattern but it serves a different purpose; Decorator adds
behavior to an object whereas Proxy controls access to an object.
Receptionist
The Receptionist design pattern addresses the general problem of
redirecting an event occurring in one execution context of an
application to another execution context for handling. It is a hybrid
pattern. Although it doesnt appear in the Gang of Four book, it
combines elements of the Command, Memo, and Proxy design
patterns described in that book. It is also a variant of the Trampoline
pattern (which also doesnt appear in the book); in this pattern, an
event initially is received by a trampoline object, so-called because it
immediately bounces, or redirects, the event to a target object for
handling.
Singleton
The Singleton design pattern ensures a class only has one instance,
and provides a global point of access to it. The class keeps track of its
sole instance and ensures that no other instance can be created.
Singleton classes are appropriate for situations where it makes sense
for a single object to provide access to a global resource.
Template Method
The Template Method design pattern defines the skeleton of an
algorithm in an operation, deferring some steps to subclasses. The
Template Method