The Web Database Anti-Pattern

I’m just naming what I’ve seen over and over again.  It’s the extreme polar opposite of the Smart UI Anti-Pattern (in terms of layering) and a play on words of the popular term “Web Application”.

This anti-pattern most often exposes itself as an asp.net website (or a webservice/remoting tier) which is merely a thin veneer on top of a relational database.  Logic may be deeply embedded in the database or even very lightly embedded.  The key distinguishing feature is the amount of reliance on the database.  This may come in the form of direct database access in the asp.net code-behind or in a very thin implementation of Transaction Script.  All forms of searching and sorting occur inside the database engine.  Application logic rarely goes beyond property-setting and data validation.

While you can successfully build small websites using this anti-pattern, the architectural qualities of an application built with this anti-pattern force it to scale at the database level.  At it’s worst, the database server will max out before the first webserver in load testing.  In milder forms, you may get a web server or two in front of the database (but just barely).

From a conceptual standpoint, the data model is seen as “the one true model”.  Thus any attempts to manipulate or access the model require database roundtrips.  In the worst offenders, data validation only occurs through database constraints.

Refactoring an application using this antipattern is very hard to do.  The bidirectional relationships available and used in the data model tend to break all attempts at using proper encapsulation when building a corresponding object model.

A team working on such an application should do a skills evaluation first and foremost.  I think these types of applications are mostly built in ignorance.  The team may have an expert command of css, html, javascript, and t-sql, but lack real exposure to things such as OOA/D and the basic patterns of application architecture.  This results in a high number of tactical solutions with very few strategic decisions.

An application with an anemic domain model has a high probability to exhibit this anti-pattern.

If your application returns datasets from webservices, there is also a very strong probability that it falls prey to this anti-pattern.

If this does describe your application, don’t feel too bad.  I’ve built plenty of these in my past (which is why I can recognize them pretty easily).  It just takes a bit of reading and some practice to grow beyond this style of development.  But I would recommend starting down the road to growth ASAP. 🙂