tags:

views:

299

answers:

6

I am reading a lot of PHP MVC material. There's a lot to take in at once. I am trying to create one from scratch, but it seems very difficult especially with OOP involved. Is this out of my level? If so, what steps should I take? Maybe I am trying to hard by trying to create everything perfectly right off the bat. I appreciate any reading suggestions.

+4  A: 

You should better understand the OOP in the first place to be able to create your own MVC-based framework.

I would strongly recommend you going though this amazing tutorial at phpro.org:

Object Oriented Programming with PHP

Here are topics covered in the tutorial:

  • What is OOP
  • What is an Object
  • What is a class
  • Commenting code
  • Inheritance (Extending a class)
  • Visibility (public, private, protected)
  • Final
  • Abstract Classes
  • Static Methods and properities
  • Interfaces
  • PHP Class Functions

    • get_declared_interaces()
    • get_class()
    • class_exists()
    • get_declared_classes()
  • Autoload

  • Serializing Objects
  • Overloading
  • Class Constants

Once you find yourself good at OOP, you would find that it is actually not that difficult to create your own framework from scratch. Here is a good tutorial at the same amazing site for PHP tutorials and great articles:

Model View Controller MVC

Sarfraz
It is not true that the MVC pattern is exclusive to OOP. It's often more easily implemented in an OOP, but it can be successfully implemented in a procedural paradigm. At it's core, it's about separating the back end, data, logic (model) from the presentation (view) and then gluing it together (controller logic).
labratmatt
@labratmatt: Good point, it is actually as it has turned out to be in php. Anyways, I have updated the answer. Thanks
Sarfraz
+1  A: 

I recommend getting familiar with an existing MVC framework before you try to create your own.

The Zend Framework is free.

Marcus Adams
+2  A: 
Lèse majesté
I totally agree, CakePHP is a great introduction to the MVC pattern especially for those with little experience in OOP. Whether you stick with Cake, move on to Zend Framework, or go back to plain PHP scripting, you'll certainly learn alot of things to help you write better code.
Colin O'Dell
+2  A: 

You could be overestimating MVC and thinking it actually solves problems, (as it is frequently advertised as the final solution to web programming problems) instead it's only a tiny step in the right direction.

It's ill defined too, there's:

  • the model... those are the classes accessing the database,
  • the view... those write the interface and sometimes are themeable.
  • And the controller, literally: anything else

There really isn't much more to that than this, the real point is not to write classes and functions that take data from the db, and print html directly... Which is pretty much what everyone did in the 90s and for most of the 2000s.

ZJR
Putting everything else in the controller is not the right way to implement an MVC website. You can still have an n-tier architecture below the the controller. The MVC part is just an UI layer.
Adrian Grigore
@Adrian here you're describing a solution that obviously makes sense, but goes *beyond* the MVC definition. MVC *per se*, is not enough, in real life it is always integrated with hierarchies of classes following the patterns required by the problem at hand and it always gets too much merit for its own good. Executives compare systems that have nothing in common based on the fact they both claim *MVC separation* and make a big deal out a simple practice.
ZJR
A: 

The Symfony documentation has a good explanation of MVC in PHP. It works an example from procedural code up to using the framework, one layer at a time.

Colonel Sponsz
I was actually reading this. It is good, but I still had a lot of Whys and Ifs.
Doug
+1  A: 

ZJR is right, it's simply about separating your logic (and not necessarily using the OOP paradigm). You want to decouple the logic that accesses your database (or CSV files, or whatever data source you have), from your presentation logic (the thing actually parsed by a web browser: dynamically generated HTML through PHP), from your glue that ties these two pieces together (most commonly, your form processing logic). That's it at its core.

Essentially: Don't mix your database access, your HTML generation, and your form processing in the same files. Separate this logic, put it in separate files, group those files together into three groups: MVC.

If I were you, I'd start grouping my logic (as I've outlined above). Once you've separated out your logic, start turning your model logic into OOP objects (google/stackoverflow search for things like 'object oriented php database').

labratmatt