Why Do We Use MVC Frameworks?
Posted: Fri Jun 06, 2008 12:32 pm
Why do we use MVC-type PHP frameworks like Zend Frameworks and other frameworks?
I mean, MVC gives you model, view, and controller. The view is where you put your XHTML for display on the screen. The model is where you put the meat of your logic. The controller is meant to be the glue between meat and display, or, rather, model and view. Sounds great, huh? Might eliminate some spaghetti code, huh?
Okay, the main point is that you want to separate your PHP from your XHTML from your SQL. Of course, if you did that completely, you'd never have a functioning program, so of course you have to mix this slightly. Several people got along just fine by putting their XHTML into Smarty or in a separate PHP file that they treated like a template and included it and the end of their programming logic with minimal PHP logic going on inside the template. Next, several people got along just fine by parameterizing their SQL with ^ or ? (or using stored procedures if your DB supports it), sticking it in a central class file as a bunch of public properties, and then having your main PHP logic (your model, let's say) load that SQL, insert data in the parameter points, and run the SQL. And even if you do this, you can still achieve ORM type classes with property get and set on tables and then .save to save the record without having to resort to full-blown MVC.
Next, it's soooo easy in the controller to abuse the MVC framework and start putting too much business logic in there, not using the model section enough. Been there; caught myself doing that.
To me, MVC style frameworks add unnecessary bulk. Want to get started doing something better, faster, and easier, and which has faster-running code? Fine, the psudo-MVC steps are:
1. Create a templates folder and put all your XHTML templates in there, renamed as .php files. That's your 'View'.
2. Create a settings class, self-instantiating at the bottom of it to give you a $settings variable, which has public properties that expose parameterized SQL and other settings strings. That's sort of part of your 'Model'.
3. Create a set of toolbox classes categorized by topic, such as $web, $db, $strings, $dates, $xml, and $misc. In there, make it just have public methods that do particular tasks for you without the need to do subclassing and the complexity associated with that. That's sort of part of your 'Model'.
4. Now, create your PHP pages that are sort of like your 'Controller' and a little bit of your 'Model'. These load your toolbox classes, grab the SQL from the $settings class, insert variables into the parameter points, interact with the database, set some variables, and then load your template 'View' pages to insert those variables for display. And your best bet is to make the pages generated in step # 4 here as consistently looking as possible so that one can hop into any of these pages and skip to the appropriate section.
Gosh, it's simple, faster, and more efficient. Less hoops, less mess if you do this right.
So, if someone really wants to build a great framework for the PHP community, they could just stick with making more toolbox classes for us that do particular tasks, or give us a lightweight framework that uses Events (some of us may remember the old days of Visual Basic) so that we can intercept anything coming from form posts (and gets), anything coming from or going into the database, and anything being displayed on the screen, and which then automatically subclasses our own code -- providing an avenue for everyone to build modules for anyone's code. (BTW, on the latter, I hear that's what the new MoonPHP framework is all about, as are some others out there.)
And on that note, I'm wondering if the Zend Framework can be hooked such that you don't use its MVC model -- you just load its classes and use them like Toolbox classes in the psuedo-MVC model I've described above. Something to think about.
So there you have it. We mere mortal PHP programmers can simulate something MVC-like and get work knocked out faster. Trouble is -- we all do it our own way and a new framework needs to come forward that does this new vaguely-like MVC-style in a consistent way.
I mean, MVC gives you model, view, and controller. The view is where you put your XHTML for display on the screen. The model is where you put the meat of your logic. The controller is meant to be the glue between meat and display, or, rather, model and view. Sounds great, huh? Might eliminate some spaghetti code, huh?
Okay, the main point is that you want to separate your PHP from your XHTML from your SQL. Of course, if you did that completely, you'd never have a functioning program, so of course you have to mix this slightly. Several people got along just fine by putting their XHTML into Smarty or in a separate PHP file that they treated like a template and included it and the end of their programming logic with minimal PHP logic going on inside the template. Next, several people got along just fine by parameterizing their SQL with ^ or ? (or using stored procedures if your DB supports it), sticking it in a central class file as a bunch of public properties, and then having your main PHP logic (your model, let's say) load that SQL, insert data in the parameter points, and run the SQL. And even if you do this, you can still achieve ORM type classes with property get and set on tables and then .save to save the record without having to resort to full-blown MVC.
Next, it's soooo easy in the controller to abuse the MVC framework and start putting too much business logic in there, not using the model section enough. Been there; caught myself doing that.
To me, MVC style frameworks add unnecessary bulk. Want to get started doing something better, faster, and easier, and which has faster-running code? Fine, the psudo-MVC steps are:
1. Create a templates folder and put all your XHTML templates in there, renamed as .php files. That's your 'View'.
2. Create a settings class, self-instantiating at the bottom of it to give you a $settings variable, which has public properties that expose parameterized SQL and other settings strings. That's sort of part of your 'Model'.
3. Create a set of toolbox classes categorized by topic, such as $web, $db, $strings, $dates, $xml, and $misc. In there, make it just have public methods that do particular tasks for you without the need to do subclassing and the complexity associated with that. That's sort of part of your 'Model'.
4. Now, create your PHP pages that are sort of like your 'Controller' and a little bit of your 'Model'. These load your toolbox classes, grab the SQL from the $settings class, insert variables into the parameter points, interact with the database, set some variables, and then load your template 'View' pages to insert those variables for display. And your best bet is to make the pages generated in step # 4 here as consistently looking as possible so that one can hop into any of these pages and skip to the appropriate section.
Gosh, it's simple, faster, and more efficient. Less hoops, less mess if you do this right.
So, if someone really wants to build a great framework for the PHP community, they could just stick with making more toolbox classes for us that do particular tasks, or give us a lightweight framework that uses Events (some of us may remember the old days of Visual Basic) so that we can intercept anything coming from form posts (and gets), anything coming from or going into the database, and anything being displayed on the screen, and which then automatically subclasses our own code -- providing an avenue for everyone to build modules for anyone's code. (BTW, on the latter, I hear that's what the new MoonPHP framework is all about, as are some others out there.)
And on that note, I'm wondering if the Zend Framework can be hooked such that you don't use its MVC model -- you just load its classes and use them like Toolbox classes in the psuedo-MVC model I've described above. Something to think about.
So there you have it. We mere mortal PHP programmers can simulate something MVC-like and get work knocked out faster. Trouble is -- we all do it our own way and a new framework needs to come forward that does this new vaguely-like MVC-style in a consistent way.