J
jack
Hi guys,
I wanted to know whats the difference between MVC and MVP pattern.
Thanks
I wanted to know whats the difference between MVC and MVP pattern.
Thanks
C
Cowboy \(Gregory A. Beamer\)
First, I must add a caveat that this answer pertains to MS's implementations
of these patterns. This is not that important, overall, but I am focused on
how MVC and MVP are implemented in .NET (MVC Framework versus Web Client
Factory), so there are some bits that may not apply to a generic MVC vs. MVP
discussion.
MVC uses three basic components, although you can put logic across many
individual classes and even into separate libraries in separate assemblies.
The three are Model (business model, which most commonly is a collection of
business objects, which may be represeted as a DataSet in thinner
implementations), view (UI) and controller (piece that marries the two.
MVP adds a view interface, which separates concerns a bit more, at least in
theory. The presenter and view are not coupled tightly as the view and
controller are, at least in theory.
Differences:
For practical purposes, the controller is in charge of everything except the
data (model) and the UI (view). This means the controller handles all
interaction, the UI is just a veneer. It is responsible for correct
rendering of the model it gets married to, but it does not handle events,
etc. This also means all actions have to be declaratively linked back to the
controller. That is MVC.
With MVP, the UI is not tightly coupled to the Presenter (or at least not as
tightly coupled). It can contain some UI related logic (not present in MVC)
and different UIs can be used by the presenter based on actions. The
controller can also do this, but the view must be bound to the controller to
work.
Why choose one over the other?
In short, it is a simplicity versus extra power thing. And, since most of us
do not need the extra decoupling of UI from presenter, the MVC pattern will
fulfill our needs.
NOTE: If you further separate the logic out into tiers, you can end up with
an extremely thin controller and have models that are data representations
without any type of access logic. Once you ahve done this, you can reuse
this logic in MVC, MVP, Silverlight, WPF, Windows Forms, etc. The point
being that the MVC Framework forcing of separation of concerns is not
necessary if separation of concerns is your primary reason for adopting the
pattern. Hope I did not muddy the water with this trip to the soapbox.
of these patterns. This is not that important, overall, but I am focused on
how MVC and MVP are implemented in .NET (MVC Framework versus Web Client
Factory), so there are some bits that may not apply to a generic MVC vs. MVP
discussion.
MVC uses three basic components, although you can put logic across many
individual classes and even into separate libraries in separate assemblies.
The three are Model (business model, which most commonly is a collection of
business objects, which may be represeted as a DataSet in thinner
implementations), view (UI) and controller (piece that marries the two.
MVP adds a view interface, which separates concerns a bit more, at least in
theory. The presenter and view are not coupled tightly as the view and
controller are, at least in theory.
Differences:
For practical purposes, the controller is in charge of everything except the
data (model) and the UI (view). This means the controller handles all
interaction, the UI is just a veneer. It is responsible for correct
rendering of the model it gets married to, but it does not handle events,
etc. This also means all actions have to be declaratively linked back to the
controller. That is MVC.
With MVP, the UI is not tightly coupled to the Presenter (or at least not as
tightly coupled). It can contain some UI related logic (not present in MVC)
and different UIs can be used by the presenter based on actions. The
controller can also do this, but the view must be bound to the controller to
work.
Why choose one over the other?
In short, it is a simplicity versus extra power thing. And, since most of us
do not need the extra decoupling of UI from presenter, the MVC pattern will
fulfill our needs.
NOTE: If you further separate the logic out into tiers, you can end up with
an extremely thin controller and have models that are data representations
without any type of access logic. Once you ahve done this, you can reuse
this logic in MVC, MVP, Silverlight, WPF, Windows Forms, etc. The point
being that the MVC Framework forcing of separation of concerns is not
necessary if separation of concerns is your primary reason for adopting the
pattern. Hope I did not muddy the water with this trip to the soapbox.
B
bruce barker
MVC is the classic isolation of the view layer from the application
layer. typically there is a message system to pass messages between the
layers. This allows good separation of the UI layer from the application
layer.
Those that use TDD (test driven design) want less logic in the UI layer
as its hard to write unit tests for UI elements (as few come with
mocks). Thus MVP was born. It abstracts the UI behaviors (clicks, hides,
setting UI properties) from the UI layer (event, etc) into their own
layer. this allows units tests to be written for the behaviors. The MVP
is just an extension of the MVC pattern.
-- bruce (sqlwork.com)
layer. typically there is a message system to pass messages between the
layers. This allows good separation of the UI layer from the application
layer.
Those that use TDD (test driven design) want less logic in the UI layer
as its hard to write unit tests for UI elements (as few come with
mocks). Thus MVP was born. It abstracts the UI behaviors (clicks, hides,
setting UI properties) from the UI layer (event, etc) into their own
layer. this allows units tests to be written for the behaviors. The MVP
is just an extension of the MVC pattern.
-- bruce (sqlwork.com)