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:
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.