Is there a (simple) way to separate models in pure PHP, and what is a good way of doing it?

Question

What I'm looking for is a way to remove the model from a set of PHP files that make up a website. It's difficult (for me) to explain.

By models I mean models in an MVC sense.

As an example say I have this website:

• index.php
• about.php
• shop.php
• checkout.php

All of the above PHP files use the same database. I have separated the views by adding templates using a view.php file that renders the correct template with values passed to it.

I am not looking to use a framework that's already out there. I'm looking at writing my own in some senses, with only the bits I need to use in it.

If anyone would like to explain why this is not necessary, or a better way of doing things, then I'm open to that too.

Thanks in advance.

Answer 1

Writing you own MVC framework will take time, but you will learn a lot in the process. So, if you have the time/resources to do it I definitely encourage you to do so. In this context here are some small pieces of advise that may help you:

• Create your domain model first. I'm assuming that you are going in the OO way, so think about your domain problem and create the abstractions that best represent your problem. Try to keep it decoupled from cross-cutting concerns, like persistence.
• Test a lot, test often. Try to test (and run your tests) as you create your domain model. This will be specially valuable when in 6 months you add a new feature and want to make sure that you haven't break anything. If you can separate your domain model from anything external (like the persistence layer or third party web services) the testing it is going to be a lot simpler. Today PHPUnit is pretty much the de-facto standard for unit testing in PHP.
• You don't have to write everything from scratch. There are a lot of libraries that can help you to ease the development of an MVC framework, so that you can concentrate on what you really want to develop. For example, you could use Slim to handle the page routing or you could delegate the persistence stuff to Doctrine 2.
• It is always nice to analyze how other frameworks solve things. You may want to look at products like Symfony or Kohana or even check how Elgg handles its views system. Also, if you want to check out something radically different you can take a look at Seaside's architecture.

Coming back to your original question, for me the key is to keep things from different layers as decoupled as possible. While I have only used the version 1, Doctrine 2 seems like a good candidate for persistence, since it allows you to create a domain model that is quite independent from the DB. This is a huge step. The second thing is how handle the view system. This is quite developer-taste dependent. For example, I like to model everything with objects, so I like Seaside's approach. On the other hand, Elgg's way of handling views is quite nice and maybe fits better with the way things are handled in PHP. Here is when you may benefit on doing some research before deciding on a route to go.

HTH

Answer 2

As someone who has written his own PHP framework, and with the same sensibility as yours, I can tell you that using a framework is a fine thing to do. That said, start by writing your own - you'll gain greater appreciation for the true structure and utility of a framework.

You'll want to learn about the Singleton object pattern. It is a major differentiator in the kinds of objects you can develop in your framework.

When you have written a few models that your files/controllers (presuming MVC) include, you will begin to see where to abstract a 'base mode' from which others extend (hint: the DB singleton).

When you start pulling in configs and the like, then you'll have your first framework object from which all other bases do their extension.