This week is a bit of an awkward week for me. Here in Holland we are off for the queen’s birthday, then we have Ascension and on friday the company I work for is closed. So basically I have had a 2 day workweek. (Worse things have happened to me in the past 😉 )
So, you have practically 5 days of no work what are you going to do? Right… program your own MVC framework.
In case you don’t know what that is, you might want to skip to the next article. 😉
A good programmer would probably wonder why the hell I would want to make my own framework. After all, there are a million and a dozen good frameworks out there, which you can use off the shelf. php.MVC, Code-igniter and so on are good working and widely supported frameworks.
The answer to that question is that I seek not to simply use a framework but to understand its inner workings. Aside from that I am a bit of a hard-ass control freak and tend to want to do things my own way. But most importantly I believe that simply using something does not make you understand it.
I am not building it from scratch, though. A lazy coder is a good coder, because lazy coders do not tend to reinvent the wheel entirely. (We might dispute what materials to use and experiment with that, but we don’t dispute the round shape)
Working on this MVC has also been an excuse to immerse myself into the more php 5.x specific features. Since last time I really dug into the features of PHP5 (and that was when it first came out) there has been much added to it and a lot of it will make your life easier.
Back to the MVC framework.
One of the major downsides I have encountered when using an existing framework like Code-igniter is the parts they are fairly rigid. For Code-igniter it is their way of URL-parsing or the highway; the highway being you write your own router/parser. There are ways around it, but by my reckoning that is simply hacking a system to exhibit modified behavior. Some of these things are so core in how that system works, that I would rather write my own, or at least know how I write a router.
Another thing most MVC frameworks fail to implement is a structured way to be RESTfull. Most frameworks basically let you sort out the methods, basically leaving you to create your own (inefficient) structures within the controller.
The final reason why I am writing my own MVC is that me and some other MVC frameworks have a different understanding what we consider the Model-part of MVC. For a system like Code-igniter the ‘Model’ is optional and if used it is basically the extend of a database result object, which is something I strongly disagree with.
A while back I had a discussion with one of my co-worker (an architect) about the use and the uselessness of the object model. He argued that the model should be as flat as possible for purpose of efficiency. Object modeling is a concept of the ’90s that was created in utopic attempt to make the code reflect the real world. His final argument: “Code was not there to serve the coders but to perform a task.”
Although I do agree with my co-workers arguments, that code is to perform a task and not to look pretty for the coders I still hold firm the believe that modeling after objects is a good principle. The biggest point he addressed was the efficiency part I do recognize: the fact we store object data in the relational context of a database. It is the Achilles heel of ORM. However I do not think this is any reason to abandon the ORM; I simply believe it requires an unconventional approach to this classic problem.
So there you have it. I spend my time writing code, learning new stuff and facing new challenges trying to find a way around the ORM paradox. What better way to spend my free time. 😉
Structure is good, over-structure is bad… Code, indeed is there to serve a purpose, however, sometimes the coder is not completely aware of what the purpose really is. In that case the coder should not have to spend too much time re-reading his code because his code looks like a bowl of spaghetti.
Implying that any form of structure is better than no form of structure at all.
MVC is a good choice but ICO (init, compute, output) is a good start for the fact that you can use that on a per-file base and applying object orriented programming is no must. (restructuring existing code will show you why)
By the way: MVC is overrated; there is a huge number of alternative design patterns, just pick the one you think is best for the purpose you want your code to forfill.
Cheers.
There’s enough design patterns for sure; I just think MVC is one of the cleaner, neater ones. 😉