Hi…
That’s quite a lot of stuff :).
As this type of operation is often repeated for most web sites, what you are asking me for is the design of a web framework. There are lot’s of ways of doing this:
-
Use a full stack MVC framework such as Symphony or Cake. There are plenty to choose from.
-
Roll your own from pieces, such as Zend controllers, ezComponents, Doctrine ORM, etc, etc.
-
Write some parts of this yourself, using a few libraries.
The essential division is the separation of the DB stuff from the page oriented stuff. What’s left should be the minimum of glue code. It’s the glue code that gets messy and is difficult to test. It’s also the glue code that captures the design of the app, so you want it uncluttered.
For the data we choose an ORM. You want to be able to write code like this…
foreach ($products->promotions() as $promotion) {
$layout_class = $promotion->layout == 'wide' ? 'FullWidth' : 'TwoColumn';
foreach ($promotion->items as $item) {
$layout = new $layout_class($item);
...
}
}
Probably not quite like this as this code would be spread over the pieces that paint the HTML, but this shows the interface to the data.
$products is a “Repository” of data stuff. It holds the database connection and a single instance is created by the glue code. That should be the only database object that the glue code creates directly.
$products->promotions() is probably something like a result set iterator, but one that wraps the row in a Promotion class as it returns each one.
$promotion->layout is just a field in the $promotion.
$promotion->items will trigger a method call to fetch the items from the database. Again, each row will be wrapped in a PromotionItem class.
ORM (object relational mappers) do all of this for you. Checkout Doctrine and Propel, and most frameworks use these or have their own. The pattern is called “Active Record”. There are simpler solutions for purely tabular data, but when you want lots of little UI objects it’s a great pattern.
I wouldn’t write this stuff yourself unless you have a masochistic streak. It will take weeks to get both transactions and performance working together. Also most ORM tools include many optimisations. For example, instead of sending one query for the promotions and then a query for each item, most ORMs will send just one query for all of the subparts. That is two queries overall.
On the front end you can write code like this…
<?php
...
$page = new MyPageController();
?>
<html>
<head><title><?= $page->title ?></title></head>
...
That is, page oriented code. Dead easy and a natural choice if you are rolling your own.
Or you can route everything through index.php and have one controller, called the “Front Controller” do all the routing. Most frameworks are FrontController based, but there is a learning curve associated with this and you can’t mix and match different systems.
Once all that mechanical stuff is separated out, it’s easier to write your application. That goes into the controller for now. I’m simplifying here, as often you have an additional layer between the controller and the ORM. Sometimes this is explicitly called the “Model” or “Business Logic”. Worry about that later.
The best way to study front end patterns is to use a framework for a bit. The ORM stuff is best learned by trying to write a simple one in your spare time.
I’m not sure this is the answer you want, but it’s difficult to go into more detail without writing a few hundred lines of code. If you ask a follow on question, we can dig deeper.
yours, Marcus
