Add Power to Your PHP With Multi-Tiered Applications

As PHP applications become more and more complex, it can be easy to end up with a tangled mess of code that makes maintenance nearly impossible. Applying the concept of tiered applications can help to alleviate some of the difficulty in maintaining complex applications.

What Do You Mean by Tiered Applications?

Tiered programming is the practice of keeping different components, ideas, or languages separate from each other.
In front-end development, tiered markup would be using external stylesheets and JavaScript.

Example of tiered markup using external JavaScript and CSS

By linking to a CSS file rather than embedding styles in your HTML markup, it becomes easier to change the
formatting of your websites because now all styling information is conveniently stored in one place, separated
from the markup of the document. And multiple HTML pages can pull in the exact same CSS file, your whole site
can be updated style-wise by simply changing one line of CSS.

In back-end development, the same rules apply, but we're dealing with different components. In broad terms, we're
looking at three tiers: the Database (storing and retrieving data), Business
(processing and handling of data), and Presentation (how data is displayed) tiers.

Why Should I Care?

Make your functions plug and play by using tiered applications.

It might not be immediately obvious, but separating your applications into a tiered structure will have a huge
impact on your code's ability to change in the future. For example, if you have a blogging system set up, and
it becomes necessary to create an RSS feed for the blog, a properly tiered application would allow you to simply
set up an RSS template, then call the database and business functions that you've already written.

On the opposite end, if your client suddenly decided that PostgreSQL was a better choice for their organization
than MySQL, you would only have to rewrite your database functions, all without touching the business or
presentation logic of the application.

In terms of reusability, you could have multiple database functionalities (supporting MySQL, PostgreSQL, and
Oracle, for example), that could be easily dropped into new rollouts of your application using just a few
lines of code in one place, rather than editing several lines of your code across multiple functions.

The Wrong Way

To start, let's take a fairly simple task—pulling the title and body text of an entry out of a database,
creating a shortened version of the entry, and placing the data into HTML markup—and go about it in
entirely the wrong way. In the following code, we'll write one function to perform all of our
tasks:


function displayEntry()
{
	$entryDisp = NULL;

	// Get the information from the database
	$sql = "SELECT title, entry FROM entries WHERE page='blog'";
	$r = mysql_query($sql) or die(mysql_error());
	while($entry = mysql_fetch_assoc($r)) {
		$title = $entry['title'];
		$text = $entry['entry'];

		// Create the text preview
		$textArray = explode(' ',$text);
		$preview = NULL;
		for($i=0; $i<24; $i++) {
			$preview .= $textArray[$i] . ' ';
		}
		$preview .= $textArray[24] . '...';

		// Format the entries
		$entryDisp .= <<<ENTRY_DISPLAY

<h2> $title </h2>
<p>
$preview
</p>
ENTRY_DISPLAY;
	}

	return $entryDisp;
}

This code outputs HTML markup along these lines:


<h2> Entry One </h2>
<p>
This is the shortened description of entry number one. It 
displays the first 25 words of the entry and then trails 
off with an ellipsis...
</p>
<h2> Entry Two </h2>
<p>
This is the shortened description of entry number two. It 
displays the first 25 words of the entry and then trails 
off with an ellipsis...
</p>

Though this might appear logical, it's actually really undesirable. Let's go over what makes this
code a less-than-optimal approach.

The Problem with This Approach

Lumping functions causes redundant code and difficult maintenance.

Poor Legibility—This code is diluted. Its purpose, though documented in the comments
(sort of), is tough to discern. If you wrote this, then came back to it in six months, it wouldn't be instantly
clear what was going on, which means a few seconds/minutes wasted trying to interpret your own code.

Too Narrow in Focus—This function is crippled by its specificity: the database query only works for one type of entry;
the text preview creation is hard-coded into the function; the formatting is specific to the type of entry
being displayed. In order to create a slightly different implementation of this functionality, we'd be forced to
create a second function that looked almost exactly the same, even if all we needed to change was the number of
words in the text preview.

Lack of Scalability—This is pretty closely related to the idea of being too narrow in focus; if we want to add more functionality (such
as a link or an image), our function will get larger and more difficult to manage. And what if we want to add
conditions that affect how an entry is displayed? It's easy to see how programming like this allows for code to
quickly become sprawling and unmanageable.

The Big Problem: Lumping Database, Business, and Display Logic

This is the sweeping issue that is causing all of the aforementioned problems.

By combining all three of our logic
types, we end up with a narrow, messy, hard-to-manage, nearly-impossible-to-reuse tangle of code.

Imagine an application where each type of display (RSS feed, entry preview, full entry display, etc.) was built with
a function like the one above, with the database access, business logic, and presentation logic all written together.
Now imagine that there are nine pages on the site, all of which have their own entry display and preview functions.

Even if we assume the application is really simple and that there are only two functions per site page, we're still
looking at almost twenty functions that will need to be updated if changes become necessary.

Improving the Code

To improve the code above, we'll spread our different types of logic across several functions. If done properly, we
should end up with a set of highly reusable, easily understood functions that stack to perform a variety of tasks.

Smaller, interchangeable functions allow for easy maintenance.

To get started, we'll plan out the necessary functionality to get a better idea of
how it should be constructed:

Retrieve the entry and title columns for a given page from the "entries" table in the database
Shorten the body of the entry to a 25-word preview and append an ellipsis
Insert the data into HTML tags to display on the user's browser

As you can see, our plan clearly identifies a database, business, and presentational tier. We can now
write functions to fulfill each of these steps with relative ease.

Step 1—The Database Tier

To get information from the database, we're going to write a very simple function. To encourage good coding
practice, I'm going to use the mysqli extension, but
I'm not going to focus on how it works. If you're not using it already, I'd encourage you to explore mysqli or a
similar extension (i.e. PDO) to secure your MySQL queries against
injection attacks.

So let's jump right into the code:


function getDataFromDB($page)
{
	/*
	 * Connect to a MySQL server
	 */
	$mysqli = new mysqli('localhost', 'user', 'password', 'world');
	if (mysqli_connect_errno()) {
		printf("Connect failed: %s\n", mysqli_connect_error());
		exit;
	}

	/*
	 * Create a prepared statement for pulling all entries from a page
	 */
	if ($stmt = $mysqli->prepare('SELECT title, entry FROM entries WHERE page=?')) {
		/*
		 * Create a multi-dimensional array to store
		 * the information from each entry
		 */
		$entries = array();

		/*
		 * Bind the passed parameter to the query, retrieve the data, and place
		 * it into the array $entries for later use
		 */
		$stmt->bind_param("s", $page);
		$stmt->execute();
		$stmt->bind_result($title, $entry);
		while($stmt->fetch()) {
	        $entries[] = array(
				'title' => $title, 
				'entry' => $entry
			);
	    }

	    /*
	     * Destroy the result set and free the memory used for it
	     */
	    $stmt->close();
	}

	/*
	 * Close the connection
	 */
	$mysqli->close();

	/*
	 * Return the array
	 */
	return $entries;
}

If you break down what this function is doing, we are literally just requesting
two columns (title and entry) from our table (entries), then storing each entry
in a multi-dimensional associative array, which is the return value of the
function. We pass one parameter, $page, so that we can determine which page we're
grabbing information for. In doing so, we've now created a function that will work
for every page of our site (provided they all have a 'title' and 'entry' field).

Notice that our function does nothing to handle the data; it simply acts
as a courier, grabbing the information we request and passing it on to whatever
comes next. This is important, because if it did anything more, we'd be in the
realm of business logic.

Why is it important to separate the business logic from the
database logic?

The short answer is that it allows for database
abstraction, which essentially means that the data could be migrated from MySQL
into another database format, such as PostgreSQL or Oracle, all without
changing the data-handling functions (business tier), since the output would
still simply be a multi-dimensional associative array containing entries with a
title and entry column, no matter what kind of database we're using.

Step 2—The Business Tier

With the data loaded into our array, we can start processing the information to
suit our purposes. In this example, we're trying to create an entry preview. In
the first example, the length of the preview was hard-coded into the function,
which we decided is a bad practice. In this function, we'll pass two parameters
to our code: the text to process, and the number of words we want to display as
our preview.

Let's start by looking at the function:


function createTextPreview($text, $length=25)
{
	/*
	 * Break the text apart at the spaces and create the preview variable
	 */
	$words = explode(' ', $text);
	$preview = NULL;

	/*
	 * Run a loop to add words to the preview variable
	 */
	if($length < count($words)) {
		for($i=0; $i<$length; $i++) {
			$preview .= $words[$i] . ' '; // Add the space back in between words
		}
		$preview .= $words[$length] . '...'; // Ellipsis to indicate preview
	} else {
		/*
		 * If the entry isn't as long as the specified preview length, simply
		 * return the whole entry.
		 */
		$preview = $text;
	}

	/*
	 * Return the preview
	 */
	return $preview;
}

In the function above, we simply check that the number of words in the supplied
entry is greater than the number of words we want to show in our preview, then
add words to the newly-created $preview variable one at a time until we hit our
target length, at which point we append an ellipsis and return $preview.

Just like in our database tier, we're keeping the code within the bounds of the
business tier. All we're doing is creating a text preview; there is no
interaction with the database, and no presentational elements such as HTML
markup.

Step 3—The Presentation Tier

Finally, we need to display the data we've retrieved and processed. For our
purposes, we'll be displaying it with extremely simple HTML markup:


<?php
	$entries = getDataFromDB(); // Load entries into an array
	foreach($entries as $entry) {
		/*
		 * Place the title and shortened entry text into two appropriately
		 * named variables to further simplify formatting. Also note that
		 * we're using the optional $length parameter to create a 30-word 
		 * text preview with createTextPreview()
		 */
		$title = $entry['title'];
		$preview = createTextPreview($entry['entry'], 30);
?>

	<h2> <?php echo $title; ?> </h2>
	<p> <?php echo $preview; ?> </p>

<?php
	} // End foreach loop
?>

The idea behind this code is simple: first, load the entries using our
database function, then loop through the entries, shortening the entry text
using our preview function and then placing the title and entry preview into
presentational markup.

Now, in order to change the layout of the entry previews, only two lines of
HTML need to be adjusted. This is a far cry less confusing than the original
function that handled all three tiers.

Closing Thoughts on Tiered Programming

I'd like to point out that the above example is very basic, and is meant only to
demonstrate the concept of tiered programming. The idea is that by keeping the
different types of programming logic separated, you can vastly increase the
readability and maintainability of your code.

NOTE: There's a great article
on TheDailyWTF.com discussing the use and misuse of tiered software design, and
wonderful commentary on the
article that presents differing opinions. Multi-tiered applications are extremely useful, but also easy to
misunderstand and over-complicate, so remember to thoroughly plan your software before building to avoid causing
more problems than you're solving.

Do you have any thoughts on tiered applications? What steps are you taking to
maximize ease of maintenance and future changes in the code you write? Let us
know in the comments!

Subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.