Model View Controller (MVC) Pattern<\/h2>\n\n\n\n![\"](\"http:\/\/users.infragistics.com\/tsnyder\/MVC%20View.jpg\" "\\"Model")
<\/figure>\n\n\n\nThe 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 implementations, 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<\/a>),<\/p>\n\n\n\nModel View Presenter (MVP) Pattern<\/h2>\n\n\n\n![\"](\"http:\/\/users.infragistics.com\/tsnyder\/MVP%20View.jpg\" "\\"Model")
<\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\n
Key Benefits<\/h2>\n\n\n\n
Before using any pattern a developer 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 the list below). But, there also a few drawbacks to consider. The biggest drawbacks are adding complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I\u2019m my experience a have seen a few solutions eliminate a large amount of complexity but being refactored to use either pattern.<\/p>\n\n\n\n
\n- Loose coupling \u2013 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.<\/li>\n\n\n\n
- Clear separation of concerns\/responsibility<\/li>\n<\/ul>\n\n\n\n
o UI (Form or Page) \u2013 Responsible for rending UI elements<\/p>\n\n\n\n
o Presenter\/controller \u2013 Responsible for reacting to UI events and interacts with the model<\/p>\n\n\n\n
o Model \u2013 Responsible for business behaviors and state management<\/p>\n\n\n\n
\n- Test Driven<\/strong> \u2013 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.<\/li>\n\n\n\n
- Code Reuse<\/strong> \u2013 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.<\/li>\n\n\n\n
- Hide Data Access<\/strong> \u2013 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 typically works with the MVP\/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler \u2013 Patterns of Enterprise Application Architecture for more details)<\/li>\n\n\n\n
- Flexibility\/Adaptable<\/strong> \u2013 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.<\/li>\n<\/ul>\n\n\n\n
Key Differences<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Here are the key differences between the patterns:<\/p>\n\n\n\n
MVP Pattern<\/h3>\n\n\n\n\n- The view is more loosely coupled to the model. The presenter is responsible for binding the model to the view.<\/li>\n\n\n\n
- Easier to unit test because interaction with the view is through an interface<\/li>\n\n\n\n
- Usually, view presenter map one to one. Complex views may have multi presenters.<\/li>\n<\/ul>\n\n\n\n
MVC Pattern<\/h3>\n\n\n\n\n- Controllers are based on behaviors and can be shared across views<\/li>\n\n\n\n
- Can be responsible for determining which view to display (Front Controller Pattern<\/a>)<\/li>\n<\/ul>\n\n\n\n
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 blueprint and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.<\/p>\n\n\n\n![\"](\"https:\/\/download.infragistics.com\/marketing\/Blog-in-content-ads\/Ultimate\/Blog-incontent-Ultimate-650x200.jpg\")
<\/figure>\n\n\n\n
<\/figure>\n\n\n\nThe 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 implementations, 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<\/a>),<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Before using any pattern a developer 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 the list below). But, there also a few drawbacks to consider. The biggest drawbacks are adding complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I\u2019m my experience a have seen a few solutions eliminate a large amount of complexity but being refactored to use either pattern.<\/p>\n\n\n\n o UI (Form or Page) \u2013 Responsible for rending UI elements<\/p>\n\n\n\n o Presenter\/controller \u2013 Responsible for reacting to UI events and interacts with the model<\/p>\n\n\n\n o Model \u2013 Responsible for business behaviors and state management<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Here are the key differences between the patterns:<\/p>\n\n\n\n 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 blueprint and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.<\/p>\n\n\n\nModel View Presenter (MVP) Pattern<\/h2>\n\n\n\n
<\/figure>\n\n\n\nKey Benefits<\/h2>\n\n\n\n
\n
\n
Key Differences<\/h2>\n\n\n\n
MVP Pattern<\/h3>\n\n\n\n
\n
MVC Pattern<\/h3>\n\n\n\n
\n
<\/figure>\n\n\n\n