Patterns for Database Eschers
By Brian Jepson
If you've built a lot of Web applications, you've probably dealt with a number of recurring problems. Try as you might, you can't always reuse code from earlier projects: Too often, old code was written in a hurry, and reuse was far from your mind at the time (try explaining to a client that the project will take a few hours longer so that someone else can benefit from your experience in the future). So, although you've amassed a pile of code from previous jobs, it usually seems too difficult to adapt it for a new project. Instead, you start each new project with a blank page.
Perhaps you look at old source code and borrow a few ideas. But you inevitably come across some of the more cryptic passages in your original code, get frustrated, and abandon the attempt. When you write a routine from scratch, do you remember the lessons learned in your previous implementations? Unfortunately, many of us teach ourselves the same lessons over and over. On occasion, if our memory is sharp (coffee helps), we might write the code better the second or third time around. But if not, we're doomed to repeat the same cycles.
A lot of current software literature is based on experiences with traditional applications like control systems, client-server applications, and so on. While Web applications differ from thesefor example, most traditional applications maintain state while many Web applications do notthe lessons we can learn from the literature are still powerful. One of the most interesting approaches pointed out by many recent papers is the notion of patterns.
Patterns
Christopher Alexander's A Pattern Language (Oxford University Press, 1977) first defined patterns as solutions to recurring architectural problems.
