Model-View-Controller : A Pattern Based on Functional Area

The Model-View-Controller pattern is one that is common and often seen in frameworks.  It provides us with a nice place to "hang" our code. The Model-View-Controller Pattern Defined We have another pattern that contains three parts.  In this case, we have the model, the view, and the controller.  These each has an area of functionality they contain and are intended to act without regard to the other areas.  The effect is not unlike other patterns that divide and delegate functionality.  The MVC pattern divides by interaction with a user.  We have the View that displays information to the user.  Then, we have the Controller that handles input.  Finally, we have the Model that addresses the core functionality and data. Clearly Defined Boundaries The power of this pattern is that we can focus on the work at hand.  We trust that the other areas will be properly designed and implemented.  This approach is useful in many cases.  However, it becomes almost invaluable in modern software solutions where there are numerous specialists involved in a given solution and as many technologies.  We also get to detach application logic from the interactions.  That allows us to have multiple delivery devices for our application and focus on each.  This pattern is perfect for the solutions where you need a web interface, and a mobile device, and a watch.  We also are free to add devices in the future without having to touch the core functionality.  Not only is this valuable for saving implementation time, it allows us to provide major updates without risk of breaking the core code.  We also reduce the regression test load for our changes and can focus those on the updated areas. Challenges The model-view-controller pattern suffers from many of the weaknesses we see in other delegation patterns.  The design and implementation must be done with the intention of placing code in the correct area.  It is not uncommon to see core logic in the view or the controller.  Likewise, the code to generate the view needs to be completely separate from the controller.  Overlap of code across the layers can break the entire pattern and render it useless for our purposes.