Why MVC?

Post Syndicated from Anonymous original http://deliantech.blogspot.com/2014/10/why-mvc.html

As you all probably know, the MVC approach has been very modern lately. MVC stands for Model-View-Controller where it is expected that your data, your visualization and your gluing and managing code has to be fully separated in separated files (they are not separated really as they are linked to each other in the same program). As I am coming from the world of the system and embedded programming it was hard for me to understand the reason behind this. 
Instinctively I thought this should be somehow related to the ease of the development. May be this makes it easier for the separation of the work of UI designers, back-end communication (and development) and the UI execution control. You can easily split the work among different people with different skills, I thought. But now I realize it is something absolutely different.
It is maintainability, therefore easier support!
And it is best illustrated with HTML.
You can easily insert JavaScript code directly within an HTML tag:
<INPUT TYPE=BUTTON onClick=”alert(‘blabla’)” VALUE=”Click Me!”>
If you go for the MVC approach, you should have a separated code that do something like this:
Separate HTML:
<INPUT ID=”myButton” TYPE=BUTTON VALUE=”Click Me!”>
Separate JavaScript:
document.getElementById(“myButton”).addListener(“click”,function() { alert(‘blabla’) })
It is obvious – MVC is more expensive in terms of code, structure, style and preparations. So why to walk this extra mile? Some programmers with my background would usually say – it has overheads and therefore is ineffective to program.

However, if you have a case of a software that has to be rewriten constantly – introducing new functionality, new features, fixing it, you have a lot of other issues to deal with. Your major problem will be the maintainability and readability of your code.
And I am sure everyone will agree that having all your control code, execution and control flow merged in the same code structure is much better, than having them split among a lot of data processing code and UI visualisations. 


If you have a huge HTML code with a lot of javascript code separated and bound directly into the tags (non MVC) it is extremely hard to know and keep in mind what are all the events that happens and what is the order of the execution of the code. MVC will make that much much easier, even though in the beginning it may be costly with an extra overhead.