Today I want to introduce a topic that has been very important for a lot of projects I have made.
The MVC pattern.
If you ever visited a website or opened Word or really any kind of Program it is likely that you will have seen this pattern or one of its children in action.
MVC is essentially the outline and the foundation of how most applications are build. Understanding this will allow greater inside to any application and will give you more freedom when controlling them. Understanding it will also allow you to build advanced applications more easily.
Patterns are like a blue print that assign several roles to objects that they need to fulfill. These patterns help when understanding the code of others and solve specific problems.
The MVC Pattern deals with the design of applications that have any sort of UI.
It assigns 3 roles:
- M - Model
- V - View
- C - Controller
The model is the data of your application. The classes that are Model classes just take care of storing the logical data.
If you make a chess application it would be classes about the chess figures, the board and perhaps the moves that were made.
If you try to make an online shop it would be classes that represent the items that you sell, accounts that are registered and deliveries that are being made.
The instances of these classes are also often supplied by a database.
The View
The view is the UI of your application. The classes that are View classes just take care of displaying the Model and take note of user input.
In our chess application one View would be the controls that display the chessboard.
In our online shop one View would be the rows, columns and all the other html elements that create an overview of all the sold products.
The View often represents a single screen the user sees like the Menu View with all the menu buttons or the Game View with the Chess Game.
The Controller
The controller contains the actions that your user can take. The classes that are Controllers receive events from the View and change your Model depending on that.
In our chess Application there could be a game controller that makes it possible for you to move all figures.
In our online shop there could be a Controller that handles our login.
It is commonly seen that a controller is tightly interwoven with a View to the point where 1 View has 1 Controller.
Interactions between the roles
The View accesses the Model and the Controller but neither contain any code about the View.
The Controller accesses the Model but the Model does not contain any code specifically for the Controller.
The Model stands on its own and doesn't have to care about the other parts of the Program.
Effects
- Better maintainability of the UI and Controlling Logic:
Due to the strict splitting of the View to the Model and the Controller you can change the UI without affecting either of them.
You can also change the way your Controlling Logic works without having to change the model.
And if the changes to the Controlling Logic do not require new features of the UI then you don't have to touch the View either.
_ - Greater Reusability:
You can reuse the Model or the Model and the Controllers if you want to create a new Apllication with a different View.
Perhaps you want to completely revise the way your application controls - then just discard the Controller and adapt the View to the new logic.
Or you want to display a login form on every page of your Website.
Then you just create a LoginView and give that part of your UI to the LoginView and handle anything this View sends with your LoginController.
_ - Multiple people can work on the same project:
The strict splitting also allows several people to work on the same project. A few take care of the View while others take care of the Controller whileanother person tries to attatch the Model to the database.
_ - Easier testing:
The diversion of roles allows you to test each part seperately. You can chech if the Controller reacts to events correctly.
If the view displays things correctly and sends events correctly.
And you can check if the Model reacts correctly to the changes applied by the Controller or if it contains the correct data.
This lets you find mistakes more easily.
_ - More Work:
Maintaining this pattern throughout your code means you essentially have to create 2 classes for every screen or subscreen that you have.
Thats more work than just having one.
_ - Worse Code Navigation:
You will easily end up with a lot of clases that can become hard to navigate.
_ - UI directly linked to Data:
While it easy to change the UI and the Controlling Logic, changing the model will result in having to change all Views and Controllers that use this Model. This is especially problematic in Web Environments where database updates and changes are commonplace.
Modern Usage and Occurencies:
The MVC Pattern spawned a whole new generation of frameworks and new design patterns.
MVC itself is mostly competed by one of its own children which are just as common as MVC itself.
Java tends to use MVP and a few web frameworks use MVVM.
Sadly I don't think I have seen a good example of MVP in AutoHotkey yet.