MVC – a Problem or a Solution?

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I’ve had enough. Stop telling me what to do and show me those kittens instead.

Software solves problems

We don’t just write software. Code doesn’t fall out of the sky into our files. We analyze the requirements, split them into small problems we know how to solve, and then we solve those small problems. Every line of code you write, have written and will ever write solves a certain problem. Be it to save the world, show kittens on a screen or make it look good in IE8. It’s there for a reason, don’t you touch it!

Problems are solvable and the solutions for these problems become part of something bigger. A black box that satisfies all initial requirements. But how do we solve these problems? Is my solution the best solution? Will other developers (or me in 2 months) understand what I did here?

One solution fits all

When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don’t use it, but seldom lets those they’re frowning upon ask why.

So why is MVC the best? Commonly regurgitated reasons are:

• Reduced Code complexity
• Code reuse
• Increased flexibility
• Decoupled code

Cool, sounds nice, but…

• Is it true?
• Do all other patterns lack these cool things?

The answer is no.

MVC doesn’t solve the Code complexity problem. It doesn’t solve the code reuse or no-flexibility problem either. And it doesn’t guarantee decoupled code.

Developers guarantee reduced code complexity. It’s us coders, programmers, developers and artists that write flexible, decoupled and reusable code. We need MVC as much as we need jQuery for document.getElementById(). We’ve been building great software before anyone had heard of MVC and we will continue building great stuff without MVC.

Don’t forget that MVC is a pattern, not a solution. It stands in line with all the others. Adapters, Factories, Singletons, Modules, Interpreters, Observers…

Patterns don’t solve problems, they help us

Patterns help us write flexible, decoupled and easy to use code. A pattern is a best practice that a developer can use to solve problems. Those best practices vary depending on the type of problem you are solving, there is no top 5. A boat might be really good at crossing water, but it can’t plough a field.

Each pattern has its strength and weaknesses and is tailored to tackle a certain situation. The Factory pattern for instance is really good at creating Objects. The Module pattern helps us write software modules in a language that doesn’t (or only partially) support modules (e.g. JavaScript). The Observer pattern’s strength is event handling and MVC helps us in decoupling layout, data manipulation and controllers.

But MVC is heavily abused, and here is why:

Somewhere down the road, someone decided that this was the best approach for everything written in PHP and accessible with a browser. Then came along the rule that a Model should have a 1-on-1 relation to a row in a database, Controllers should be thin and views have to be written in a templating language that compiles to PHP.

Then, someone noted that ‘thin controller’ is not always the best approach. They thus created the rule of fat controller, thin model.

Several iterations later, we made poor MVC give birth to HMVC, MVA, MVP, MVVM, PAC…

MVC is the new Singleton (or IE8)

Sadly enough, MVC isn’t the only abused pattern. As Keith nicely points out:

We needed something that looked like a global and acted like a global but wasn’t really a global.

Suddenly the Singleton pattern was showing up everywhere in our code. You could write crappy code without people complaining about the use of global $var. Instead we used the Singleton pattern, Global::getInstance()->var and called it OO.

Patterns are cool, developers aren’t

Don’t get me wrong, patterns are there to be used. But use them wisely. Use them together. There is nothing worse then a developer using the wrong pattern for the wrong reason with the wrong intentions.

So please, I beg you. Don’t abuse patterns.

Don’t reinvent the wheel. You are not the first developer trying to create modules in JavaScript, neither are you the first one developing event handling software. A lot of smarter, more trained professionals have done the exact same thing before you.

Having trouble separating your MySQL from your PHP? Are you writing SELECT * FROM in your HTML? MVC will probably help you, or maybe Multitier architecture is a better fit for you.

Having troubles with lazy loading/reading config data? Singleton could help here.

Is creating an object of a certain class a pain in the ass? The factory pattern can really help you stay DRY.

Having troubles getting 2 services to communicate with each other? Adapters can help.

Conclusion

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them – if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.

May the patterns be with you!