You know the local grocery shop on the same street as your home. There is one shopkeeper, also the proprieter, who takes care of business. You go in and he smiles as you greet each other. You tell him what you want. He personally goes to the shelves and brings the stuff back to you. If it isn’t available, he’d tell you that too. After all the items you wanted are in your shopping bag, you hand the shopkeeper his due money, which he takes with a smile. After greeting each other once again, you leave.
This shopkeeper has it easy, even though he does all the work by himself. This is because he has simplified his business by making sure that he serves a small community. He has inventory that he can count on his fingers and only enough customers that he can personally deal with. What if he were to take orders over phone too? He’d have to manage delivering those items too. What if he were to serve customers from the entire city? More work for him. Very soon, that friendly smile on his face will disappear and he will feel an unquestionable need to split his role at the shop to multiple persons he can employ and manage.
This is what the multi-city chains like Big Bazaar, Walmart and Carrefour have done by employing thousands of staff in their business. Splitting up roles among employees into various categories and using their help to run a smooth business. And this is precisely what you do by employing software development models like MVC or Model-View-Controller.
What exactly is MVC
It is common for experienced software developers and project managers to casually use terms like MVC as if it were a household term, while you, as a non-tech person or as a junior software developer who just got started, is left scratching your head. Let me help you understand what MVC means.
A software developed using the MVC model contains three components.
- Model: Every software system is trying to help streamline some work inside a system in the real world. E.g. banking software helps us reduce the number of physical banks, where otherwise we’d need to go to manage our money. An inventory system at a business relieves an inventory manager from having to count inventoryon his/her fingers.
Models are software representations of the components of the real-world system. For instance, the banking software would have models such as savings account, loan, currency, etc. Every software system will somehow get the objects represented by these models into the hands of those who need them. E.g. items are shipped to customers, payments are credited to merchants.
- View: Software systems need to interact with people to get work done. This means that the users need to work with screens, voice detection and gestures, sensors detect inputs, alarms are fired and emails and SMSes are sent. Every component in the system that directly interacts with a user is a view. They can either get an input from the user or show the user some output.
- Controller: Controllers are the orchestra directors that keep the system working smoothly by mediating between the models and the views. Controllers take care of calculations, business logic and validations. They will use the inputs gathered by the views, interact with the models to find the suitable output and then direct the views to give that output to the user.
An example of MVC in real world
We will look at an example of MVC as it plays out in the real world. The example is that of a business that fulfills phone and onine orders. Clearly, we cannot have just a lone shopkeeper taking orders, procuring inventory and shipping them. There will be a business with employees who work together to keep things ticking. Here is how things fit in the MVC model.
Models: The role of the models in this system are chiefly the inventory. The items that are bought by the business in order to sell to the customers. Customer accounts are also examples of models. The company tracks customers and their buying patterns in order to attract them with offers that incite a repeat business with them. Bills and invoices are also models in the system and so are payments. Orders placed by customers are also models.
Views: As mentioned, views are the what are directly seen by the users of the system. For the customer, the web page on which his/her order is placed is a view. If someone is calling in to purchase, then the person who takes and confirms the customer’s order is playing the role of a view. The delivery man who delivers the goods to the customer is another example of a view. The customers receive their goods from the delivery man’s hands.
Controllers: In this business, two persons pull the strings. They even talk to each other all the time. The fulfillment manager listens to the persons who take orders over phone. This manager also constants checks the database of online orders to see there are new ones to be fulfilled. He procures goods from the other important controller, the inventory manager, and initiates the process of shipping through the delivery man. The inventory manager is responsible for keeping inventory at a level which exceeds the demand slightly. He/she talks to the fulfillment manager about which items from orders can be fulfilled and which will have to wait until items are available.
One of the biggest benefits of using the MVC model to build software is portability, especially for views and models. Did you create a login screen for a system? Why not use the same screen with minor modifications in another system? There are login screens everywhere these days. Or what about the customer account model that you created for your banking project? Perhaps this model stores the customer’s name, date of birth, address and gender? Doesn’t it fit the eCommerce project you were planning to build? Just take the customer model from the banking project and snap it right into the eCommerce project.
However, controllers are a little difficult to use across different systems. Controllers take care of business logic and that role is difficult to play well across different systems without heavy modifications.
This happens in real life too. A delivery man who delivers pizza can deliver music CD-ROMs too. His work is to drive his vehicle and deliver consignment to the customer. He plays the view role. If you have piles of blue jeans lying around in a warehouse and no one is willing to buy them in your eCommerce business, why not put them into a cloth rental business? The jeans are examples of models and you can simply move them from one system to another.
But let’s look at a controller’s job. In our case, the fulfillment manager is a good example to look. In the change from pizza to CDROM business, the fulfillment manager’s role doesn’t change too much. Instead of talking to the kitchen chef to make the ordered pizza, he has to talk to the inventory manager to procure the ordered CDs. The ordered object will somehow land in his/her hands and he/she can hand it off to the delivery man for delivery. But let’s the case of the purchase to rental market for jeans. In the purchase market, a pair of jeans once sold is gone and the fulfillment manager doesn’t have to worry about it anymore. But in the rental model, he has to take on an entirely new role, where he/she takes care of returns. Jeans have to be tracked, returned ones have to be checked, customers need to be reminded about delays and penalties collected for delayed returns. Deposit amounts will have to be charged to cover for defective returns. The role is heavily modified across the two businesses and the fulfillment manager has new skills and techniques to learn.
As software grows complex, it becomes necessary to streamline it in a way that the real world solves its own problems of complexity. One of the ways is to break a system down into compartmentalised roles. This is exactly what the MVC model does. Do you already use MVC? If not, how do you plan to break down your system to fit the MVC model? Get going now and reap the benefits.