Preface
This is blog #1 for me. If you hate it, please provide feedback. If you like it, please let me know what else you would like to see.
Why would you want to do this?
I have noticed a lot of questions about MVC recently, and I thought that perhaps it was time to supplement some of the other blogs out there.
Hasn't this already been covered?
I am going to make this blog a little different. I am sure you can reference some of the plumbing of MVC for BSPs and Web DynPro BSP / HowTo: Exploring BSP Development with MVC so I will not rehash that which is already available. I am not sure how many people have been taught design patterns before, but I feel there is a bit of a gap in the fundamental theory that makes up the MVC pattern, which is something I will cover here. Not all of this information is SAP specific to say the least, but it should help with a bit of the understanding of the MVC pattern as a whole from the software engineering standpoint. Hopefully, this will help bridge a few of the gaps and facilitate the overall understanding of the SAP specific and purely technical blogs.
Why on earth would I want to read this if it is not SAP specific. My project is now (and not theoretical).
A better understanding of the design pattern will allow you to create better software. If you are trying to muscle your way through a massive BSP application with multiple controllers, sub-controllers, models, and views, it will get confusing at some point. It will get a lot more confusing if you are unfamiliar with the base concepts that make up the MVC pattern.
The part you are dying to read.
What is MVC?
To start, MVC stands for Model - View - Controller. It is a software architectural design pattern that facilitates the uncoupling of the business logic (model) and the user interface (view). The controller is the intermediate component that will facilitate communication between the others.
History
While this may surprise some, the MVC design pattern is not a new concept. It was originally described in 1979 by a Smalltalk developer for Xerox ( reference ). Over the years, as applications have grown in size and complexity, the MVC pattern has become more widely used and more widely accepted.
An In-Depth Look at the Pattern
Model
In short, the model is the functional core of an application - the business logic. The model is the plumbing / guts / actual work that is the purpose of the application as a whole. With that in mind, remember that the overall purpose of MVC is the separation of business logic from the user interface (view and controller). With this separation, it will also be possible to reuse the model object with multiple application user interfaces.
The model is always completely uncoupled from the user interface components (view and controller). It cannot reference any portion of the application (or the data that is held in instance variables in the UI objects). In a nutshell, the model is a deaf, dumb, and mute box that will simply react to requests from another object or supply information to an object it is bound to that the model is essentially unaware of.
There are several different ways to look at the model.
Passive Model
In a passive model, the objects being used in the model are completely unaware of being used by any other object. The controller will update the views after the model has executed some operation and performed some bit of business logic. The "passive model" approach is well suited to the web, and most commonly used in web MVC applications... The inherently strict and static nature of HTTP requires that the view is completely rebuilt with each iteration, regardless of change.
Active Model
The "active model" is still completely separated from all other aspects of the application at hand, but defines a change notification mechanism. This is most commonly accomplished using the observer pattern. The notification mechanism will allow unrelated view and controller components to be notified of any change in the model. Because the user interface components register themselves with the model and the model is still unaware of any external objects, the independent nature of the model is not violated.
Presentation Model
On occasion, there is a need to have business logic that pertains to the user interface in particular. As the purpose of MVC is the separation of user interface and business logic, these chunks of code must find their way into a model. However, as there is no need to collapse all of the business logic into a single class, it is possible to segregate the user interface specific logic and the true business logic in separate classes (separate models). Think of this application of the pattern as MMVC in the sense that there are two models. The second model is often referred to as the "Application Model."
The View
The view is the presentation layer of your MVC application. This is the screen that your user will see and interact with. It is the only part of your application that your user will have any contact with, and in this sense is exceptionally important. From a design pattern standpoint, it is the simplest portion of the application. The view can reference data being stored in the model, but cannot modify the model. Due to the static nature of http, the view is not modified when an action is performed. Rather, the view is rebuilt based upon the presented data from the model and instructions from the controller.
The Controller
The controller bridges the logic gap between the model and the view. The controller will receive request and input from the view and call the appropriate methods in the model. Remember, the model is blind to the components around it, so the controller has to be present to bridge that gap between user interface and the business logic.
It is important to know that the controller does not sit between the model and the view. The model and view can both access the data of the model. The controller can interpret specific input and actions and request specific data from the model or call a specific series of actions. In some cases, the controller will copy data between model and view when binding is not an option, but this is less and less common.
How it all fits together
You can find a bunch of images out there that will diagram how everything fits together in MVC. At the end of the day, I feel that many new developers are misled into believing that the controller stands between the Model and View. Rather, the three components are all independent and in various states of communication with each other. The controller does act as the puppeteer for much of the application, but is far from a "pass through component" or middleman.
This is a proper interpretation of the MVC pattern. The solid line indicates direct access availability and the dashed line indicates and ability to reference. Notice that the model is unaware of any other components in this implementation.
This is the incorrect way to think of MVC. The controller is not a pass-through component that connects the view and model.
Closing
I hope you have found this quick overview to be helpful. I know that writing this out and referencing some other sites has actually helped me refresh my knowledge of this useful and easy to use design pattern. I am thinking about writing another blog about the relationships between the components and some of the rationale for using MVC. Perhaps also going over the other options out there would be helpful as well. Please let me know!
Thanks for reading,
Benjamin
6 Comments
