Application As Db Veneer

(contrast to ApplicationAsCollaboratingObjects)

Considers an application to be a veneer atop a usually relational database. The application exists as a mechanism to filter information from the database to the user, and send it back again. The goal is to have as thin a veneer as possible on top of the Db, leavening the risk that information might somehow "leak", or "spoil" once outside the cozy embrace of the Db.

Central to this concept is the idea that the database is the real thing, that it is wholly and uniquely valuable, and that anything that interacts with it must do so as politely and innocuously as possible.

In this world, claiming that useful applications can exist without having information reside in the application, without it being in the database, is cause for apoplexy.

I've actually worked on projects where technical leaders have held very strongly to the opinion that everything possible, and this includes all domain logic, should reside in the database, exposed as stored procedures. Then the application could be reduced to collections of components which are simple getters and setters of information from the Db.

Sayyyyy, isn't that the model for Entity Beans? -- ChrisGerrard

This seems to be the world-view that ChrisDate and his collaborators are pushing at present, but with a stronger model of what a "database" is than the usual. TheThirdManifesto lays this out, and Versata (www.versata.org) are seeking to make it a reality, at least for e-stuff

I've looked at TheThirdManifesto, and it's attractive on the surface. I'm struck by RonJeffries quote:"I suspect that there really is a conceptual barrier between object thinking and database thinking. I feel strongly that - at least - we've not found the smooth connection yet. I've been wondering about this for some time. Particularly, what was so attractive about OO when I first encountered it, and what seems odd about relational Dbs.

The main difference is that OO allows greater flexibility in describing systems of "organic" things, where things are often like this or like that depending upon context, and the relationships between things can be fluid in multiple dimensions. Whereas with relational systems, at least as widely implemented, everything needs to be fixed in place, the more absolutely the better. Who among us isn't familiar with the sincere DBA forbidding the very concept of a schema change? I strongly believe that relational representation of information is contrary to how humans' minds work.

There's a reference to the distinction between the Object-Oriented view of applications, and the relationship between Object state and persistence in "Object-Oriented System Development" (ISBN 0-201-56355-X ) by Dennis de Champeaux, Douglas Lea, and Penelope Faure, copyright © 1993 by Hewlett-Packard Company. There's an online version, the persistent section is @ http://g.oswego.edu/dl/oosdw3/ch23.html#SECTION00040000000000000000

The statement: "Our design attitude about persistence is a little backward from some others. We consider the real objects to be active. Persistent media merely hold snapshots of state information needed to reinitialize or reconstruct functionally identical objects in case the current ones somehow fail or must be made dormant. This is in opposition to the database-centric view that the real data live in a database, and are transiently operated on by a database manager and other programs."