Today I read an absolutely horrible article in the CodeProject.  I don’t link to the article because, well, it’s really that bad, but the site itself seems pretty good.  Anyways, that all happened as I was reading more about what MVC technically is, as I’ve never had a use to look more into it in my programming.  Well, MVC stands for “Model, View, Controller”, meaning that each is kept separate from each other while programming.  Specifically, I looked in to Codeigniter, as that has been listed in a lot of web development job postings as a requirement to know.  While I read its documentation, I realized that it is essentially a collection of classes that preform various common actions that are used within PHP programming (The Controller aspect), with a few that would fit the View architecture of the design.

So, as this is basically How I have programmed in PHP since 2002, I decided to tab over to my Google search and clicked another link, one that took me to The MVC Paradox, by a published author on Software Development.  While reading his post, I felt like he missed the meaning of what ‘Views’ are in the design.  He said in his opening paragraph that Views are essentially supporting multiple clients, which he broke down with “Web Browsers” being first on the list.  Now, since I clicked all those Wikipedia links on the subject (and all the google ones that seamed reputable), and read quite about about what MVC really is suppose to mean, I found that most sources seem to agree that the view is what happens within the user’s web-browser.  He also said that Modern MVC Frameworks couple domain logic and user interface.  Since he didn’t define what domain logic was, I looked around and the most relevant definition I found was involving SQL statements, which is in the Model portion of the MVC. Now, I’ve known quite a few programmers, being as that’s what I studied in college; and absolutely none of them, or myself, couple the SQL statements directly to the output.  It always goes through some other process to modify it for output while in an OOP environment.  The blog continues to completely disregard every concept about MVC, calling all server-side classes ‘boilerplate code’ that bloat a project.

From what MVC frameworks that I found in PHP, most classes are separated quite nicely into modules that fit the design concept.  The code that I had used and reused in all my projects for display/SQL access/and authentication needs, included as classes as needed, with new code being written around it to complete those web-applications, fit the MVC design as well.  The blog author then links to and gives a code sample from the PHP 5 Micro Framework known as Slim, and Slim never claims to be MVC.  The blog author simply assumed that his own analysis of modern web systems was correct, and that all MVC Frameworks are simply “bloated boilerplate code”, and then passed us off to a small framework that does not follow the MVC design (read: it couples the model and view aspects into unintelligibly with its “Hello world” code.

So that author convoluted what MVC design is, and encourages you to use a RESTful approach instead.

In all of that, I learned one main thing, I never looked in to what MVC was because I had always insisted on recreating the wheel to begin with.  If I saw a class that did something useful, I’d program my own so as I know its exact features, and if it somehow managed not to be secure, I knew what I created and could troubleshoot it effectively.  Knowing that, I now get to start using CodeIgniter for my current project, just to check that box for the future.  I am glad that this project can take about 9-10 months, just to fully learn the framework as I make it (make it my own, in the way I learn their code).  At the same time, it’s a project I want to finish and have months to test before the intended opening next tournament season in 9 months.  So, here goes everything!

No Comments Yet

There are no comments yet. You could be the first!

Leave a Comment

    Search the Blog