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.
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?
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:
Cool, sounds nice, but…
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 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.
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…
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.
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.
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.
All Copyrights Reserved to Graphix Design 2017