2.2. Layered Technologies

Let's start at the top, since it's the simplest there. If we're talking about web pages, our presentation layer is going to consist of CSS. We could also go for <font> tags with color attributes, but favor is definitely turning from that sort of thing. Besides, to keep our layers nicely separated, we'll want to use something that allows us to keep the presentation separate from the markup. CSS fits this role perfectly.

Under the presentation lies the markup. For web-based markup we have a pair of main choices and some options under each of those. We'll either be serving HTML or XHTML, with the various versions available of each. While the in-crowd might make a big thing of XHTML and standards-compliance, it's worth remembering that you can be standards-compliant while using HTML 4. It's just a different standard. As far as separating our markup from the logic layer below it, we have a couple of workable routes: templating and plain old code segregation. Keeping your code separate is a good first step if you're coming from a background of mixed code and markup. By putting all display logic into separate files and include( )ing those into your logic, you can keep the two separate while still allowing the use of a powerful language in your markup sections. While following down this route, it can be all too easy to start merging the two unless you stay fairly rigorous and aware of the dangers. All too often, developers stay aware of keeping display logic in separate files, but application logic starts to sneak. For effective separation, the divide has to be maintained in both directions.

There are a number of downsides to code separation: as described, it's easy to fall prey to crossing the line in both directionsbut a little rigor can help that. The real issue comes when a team has different developers working on the logic and markup. By using a templating system, you enforce the separation of logic and markup, require the needed data to be explicitly exported into the template's scope, and remove complex syntax from the markup. The explicit importing of data into templates forces application designers to consider what data needs to be presented to the markup layer, but also protects the logic layer from breaking the markup layer accidentally. If the logic layer has to explicitly name the data it's exporting to the templates, then template developers can't use data that the logic developer didn't intend to expose. This means that the logic developer can rewrite her layer in any way she sees fit, as long as she maintains the exported interface, without worry of breaking other layers. This is a key principle in the layered separation of software, and we'll be considering it further in the next section.

As far as templating choices go, there are a few good options in every language. For PHP developers, Smarty (http://smarty.php.net/) offers an abstracted templating engine, with templates that compile to PHP for fast execution. Smarty's syntax is small and neat, and enforces a clear separation between data inside and outside of the templates. If you're looking for more speed and power, Savant (http://phpsavant.com/) offers a templating system in which the templates are written in PHP, but with an enforced separation of data scope and helpful data formatting functions (in fact, the code-side interface looks exactly like Smarty's). For the Perl crowd, the usual suspects are Template Toolkit (http://www.template-toolkit.org/) and Mason (http://www.masonhq.com/), both of which offer extensible template syntax with explicit data scoping. Choosing one is largely a matter of style and both are worth a look.

Underneath the markup layer lives the two logic layerspresentation/page logic, and business/application logic. It's very important that these layers are kept separatethe rules that govern the storage and manipulation of data are logically different from the rules that govern how users interact with the data. The method of separation can depend a lot on the general architecture of your application and what languages the two layers will be built on.

With both layers built in PHP, the two layers are usually kept in separate groups of files. The page logic resides in .php files under the web root, while the business logic lives, by convention, in .inc files outside of the web root (although the naming convention is one I dislike and would recommend againstnaming the files differently suggests you might put them in the same location at some point).

With both layers built in Perl, the convention is to use module namespaces to separate the layer, which also has the side effect of keeping the files physically separate. For instance, the page logic might reside within the MyApp::WWW::* modules, while the business logic resides with the MyApp::Core::* modules. This structure makes iteasy to add additional interaction logic layers into different namespaces such as MyApp::Mobile::* or MyApp::WebServices::*.

With layers written using different technologies, such as the enterprise-scale staple of business logic in C++/Java with interaction logic in PHP/Perl, the separation is forced on you. The difficulty then becomes allowing the layers to talk to each other effectively. The way the interface and methods exchange data becomes very important (since your application can't do anything without this exchange) and so needs to be carefully planned. In Chapter 7, we'll look into how heterogeneous layers can communicate.

At the very bottom of our tasty application stack lives our persistent store. Separating this from our business logic is trivial, although database stored procedures can cloud the picture a little. We won't be covering stored procedures for business logic in this book, mostly because our core technologies don't support them, but it's worth mentioning what an important role they can play in the business logic architecture of a web application. If you're using PostgreSQL or Oracle, then you'll want to get a good book about stored procedures as the logical core of a web application.

The actual technology used as the data store isn't too important, as it does the same job regardless. Depending on your application's behavior, the data store will probably consist of a database and/or a filesystem. In this book, we'll cover MySQL as a database technology and POSIX-like filesystems for file storage (although we won't usually mention the fact). The specifics of designing and scaling the data store element of your application come later, in Chapter 9.