2.4. Getting from A to B

While it's important to build large applications on good foundations, and equally important to avoid building small applications on skyscraper-scale foundations, we need some way to transition from one scale to another. We may already have an existing application of the "one giant function" variety, or we might be building a prototype to later scale into a large application. When building prototypes, we might skip the disciplined architectural design to get the product working as soon as we can. Once we start to scale these small applications and prototypes out, we need to transition from small to large foundations and impose some structure.

The first step in this process is usually to separate the presentation layer out, moving inline markup into separate template files. This process in itself can be further split down into three distinct tasks, which can be performed independently, avoiding a single large change. This approach allows you to continue main development as you split templates into their own layers, avoiding a developmental halt. The three steps are fairly straightforward:

Separate logic code from markup code

The first step is just a case of splitting the code that generates HTML markup into some new files and having the page-driving files include them at runtime. By the end of this step, logic and markup generation will live in different sets of files, although markup for multiple pages may be generated by a single file.

Split markup code into one file per page

In anticipation of switching to a templating system, we'll want to split out each page or reusable page component into its own file. At this point, we're still using regular old source code to generate the markup, but each logical markup segment (page or block) has a file of its own.

Switch to a templating system

With a page per file, we can start to translate these pages into a templating system, one by one. This may be a slow process, especially if you have a lot of logic mixed in with your markup generation. Because we've already split out the pages, we can take as long as we want for each page, not affecting the others.

Once our templates are nicely separated out, you may also want to split out the styling into CSS files (if you haven't already). The approach to managing a migration to CSS is beyond the scope of this book, but there are many good resources available both in web and dead-tree formats.

With our markup and presentation layers separated from our code base, we have only one task leftto separate page logic from business logic. There are several approaches you can take toward this goal, but one of the simplest to achieve in parts is function grouping.

By looking at the data manipulation areas of your application and splitting them into discrete functional groups, you can quickly design a modular structure for your business logic. A very simple approach is to group together code that accesses a particular database table (or set of related tables). You can then look at every piece of code that accesses those tables, either to read or write, to form business logic layer functions. Within Flickr, all reading and writing to the table that stores photo notes (annotated regions of photos) is contained in a single module. This approach also makes later editing of business logic very simple: if we need to change anything about the database table or what we store in it, we know instantly where to find all of the code that deals with that table.

As with the templating layer split, separating business logic from page logic can be done as a stepped process over a very long time. As each functional area is separated, the layers become more and more distinct until finally all data access is pushed into the business logic libraries and all interaction logic remains in the page driver logic files.