What is MVC and why should I follow convention over configuration?
Because of so many frameworks appearing like mushrooms now a day, I doubted if this paradigm needed a an indepth explaination. To be fair, MVC is a design pattern where in, you structure your application development into three main components: Model, View and Controller.
A clear separation of components does not make it faster to develop however, it does make it easy to maintain and scale your project from small team to as large as an army.
MVC framework exists on both Web application as well as desktop/mobile application development. If you've developed native desktop applications using GTK or Cocoa you are probably well versed in these practices and I applaud you for that because catching up with any MVC framework shouldn't be a problem.
A typical web MVC framwork would look something like this:
- You will have a seperate file that acts as a Controller. A Controller will contain routines for all your action. These actions are represented by methods or function names. Because it's an MVC, this controller represents the available actions a user can make for a particular page in the form of URL requests and thus a Controller in itself represents the entire page.
- You will have a separate file that acts as a View. A single View represents the default View that will be displayed when a particular action ( or requests ) has been triggered or completed. Each view names must correspond to an action name from a Controller. So if you have Controller that contains actions such as "create" and "edit", the View files named "create" and "edit" must also exist.
- A Model, can be anything from a Plain Object with exposed properties to a class file that represents a table from a database.
Depending on the framework it may or may not support RESTful URL. For typical MVC a full request URL that conforms to MVC pattern would look something like this: http://myapp/my_controller/create
A typical desktop/mobile MVC framework would look something similar above except that the View as something extra. That extra is called events or delegates. The events is the only way for user and an application communicates with each other. The Model in a typical MVC desktop framework can be a normal variables such as arrays or lists to class mapping a table from a database. The way you display data to view is also not your typical way compared to other GUI toolkit like VB or WinForms.
In GTK or Cocoa, a View is just that a view. It does not store or hold anything. It can only tell you when it's about to be drawn to the window, being touch, clicked etc. or being disposed out from a the main window.
Say you wan to display a list of persons from a Listbox. In old fashion way like VB/WinForms you would have to instantiate a Listbox UI and add each person to the the Listbox UI. And if you want to delete a person you have to delete that person from the Listbox UI. So clearly the VBs/WindForms toolkit acts as both a View and Model because the View itself holds a value which in this case our person list.
However, using MVC software achiture like GTK or Cocoa, you are required to have a Model that will hold the list of persons and that Model would have to be either an Array or a List. Then you would instantiate a Listbox UI ( or a TreeView ) attach a delegate or events to that UI. The UI will then fire/trigger an event. Event such as "didLoad" or "realized/shown/displayed" that tells you that the UI has been drawn to the main window only then your delegate would have to loop through your Array/List variable and display each person as the delegate iterates through the event. The MVC Listbox does not hold the value of the person but only the index of the item you iterated. So for you to be able to delete a person you would need to remove a person from the Array/List variable and tell the MVC Listbox UI to refresh. As you can see there is a clear separation of business logic from the model and the view.
From my years of experience, I've encountered a few people who does know MVC and do so because they used a framework. However, what baffles me the most is that the framework itself though being used as it is, the MVC design pattern itself is not actually being practiced by most developers.
Most people the I worked with who have been using an MVC framework spends a lot of time digging in the XML,JSON configuration file. After a few months or years, the configuration file grown from a few configuration files into monstrous redundant configuration files. Queries that could have been simplified by using Inheritance has grown into Interface hell and implementation hell of Data Access Object. Because the developer's lack of knowledge of proper delegating of business logic, the project has full of imports of unnecessary classes just to infer or defer and action.
The reason why projects grown from simple app to buggy garbage codes is because of the lack of convention. Developers tend to do as they please because it's the easiest way that makes sense to them. If a framework provides convention all the heavy lefting is done by the framework itself. Only few MVC that does this: WebObjects, Groovy, Grails, RoR, CakePHP, Laravel to name a few. Click here for a list of Web frameworks that offers convention over configuration.
If only developers would allow themselves to be open and free of programming prejudice, application development would have been smooth. Adding a simple feature would have been easy as pie rather than figuring it how to make it work because by following convention, the framework gurantees you that it will work. Example would be operations like request dispatching should work as expected if you follow naming convention. There should no longer be a need to either add dispatching configuration, nor annotate a method to map an anction to a request. Even an annotation defeats the purpose of making your application maintainable because annotation will remove portability as annotation serves different purpose framework to framework or library to library.