I have one or two spare minutes, so I'd like to talk a bit about software design, design patterns and MVC:
One good article about MVC is this one: https://msdn.microsoft.com/en-us/library/ff649643.aspx
Compared to the Wikipedia article the MSDN one for once explains the WHY. Why do people use MVC? What is the problem it solves?
And, even though being marked "Retired", it is very valid.
Once you discover the essence of why
certain architecture styles and design patterns exist, you can forget about patterns at all, and only have to ask yourself one single question which will lead you to the right design: "What parts of the system are likely to change and which parts are unlikely to change?"
It has always been that question driving all designs and it will always be just about: Change.
We design for change.
When things can change, we want to isolate them, so that once they change, they do not lead to substantial other parts of the system having to change, too, which would increase rigidity and fragility of the software.
When, on the other side, something doesn't change, we can tie it to the rest of the system as strongly as possible, so as to reduce complexity and likely increase performance.
About every behavioural and structural design pattern I know, is just driven by how to handle change, be it adaptation or extension.
If it wasn't for change, then every system could be implemented using a single file, module, class, compilation unit, etc.
Because we would never have to maintain, extend, adapt, transform, or otherwise manipulate it ever again.
But in our world, such constancy does not exist. Every software needs to be changed in one way or the other. Always.
The trick about good software design is to try to know which parts change in which ways, and then design the system to make such changes easy to do. This is the pure essence of the Software Engineering field.
There is one great article by Martin Fowler, called Who Needs An Architect?
, which has influenced me a lot. In it, Martin Fowler also quotes Ralph Johnson as he explains what he thinks "Architecture" is and how it relates to change. One great paragraph about "change" is this:
If you pick any one aspect of software
then you can make it easy to change,
but we don’t know how to make everything
easy to change. Making something
easy to change makes the overall system
a little more complex, and making
everything easy to change makes the entire
system very complex. Complexity is
what makes software hard to change.
That was just what came to my mind when I read this thread about MVC. So, sorry if it was too long and boring.