I absolutely agree that changes in the schema and/or the architecture should be transparent to the application — the data access API doesn’t change. By the same token, though, if the schema changes, the architecture does not, and vice versa. So whatever makes up what you call the “data access” layer needs to encompass both, and an architecture change should only change the “here’s how to find out what machine to connect to” parts, whereas a schema should only change the “here’s which db(s), table(s) and column(s) to query” parts.

Dominic — good point. I guess it’s similar to a smart load balancer for http. When you go to http://www.google.com, DNS and Google’s webserver configuration point you to a particular webserver. Similarly, when an application “goes to” a database, it should be directed where to go by external logic — that logic is the architecture layer.

For me, coding the architecture layer into the functional layer (app/business logic) is like never using DNS and hand-configuring your /etc/hosts file for every single website you go to. It works, but any architecture change requires you to change your /etc/hosts.

Tony — I’m not sure if you read the whole post, but the whole point of the article that I quoted was that the business and application layer don’t need to be separate, for exactly the reason you stated.

I explicitly stated that I agreed with the article and would, for the course of this article, refer to the merged “business/application” layer as the “functional” layer. Hope that clears things up.

Your example of the ACCOUNT_NUMBER logic having to appear in multiple places shows a flawed implementation. You should have a single ACCOUNT object which contains the necessary logic to insert, update or delete any ACCOUNT instance, and whenever an instance has to be manipulated it should be done so via the ACCOUNT object. There may be many calls to the ACCOUNT object from many places, but the logic inside that object is defined once and need never be duplicated.

Is it a layer or a cloud or just a virtualisation of resources?

A functional layer certainly should not care whether there is one or ten databases nor which particular database Sheeri with the blonde hair colour is in; you can make a good case for saying that a persistance layer not either.

But sometimes it’s not just about databases is it? You want requests about blondes to go down an entire architectural leg including app server, etc.

I’ve thought of it and I believe I call mine the “Data Access Layer” (for lack of a better term so far) – it is the go-between from the applications and the datastore. “Datastore” could be a hybrid memcache/MySQL solution, sharding, clustering, flatfiles – it doesn’t matter.

As long as there is a proper user_set() call and a user_get() call – the only two ways to modify and access that data, then it will be transparent to the layers above it where exactly the data came from.

Some day I will actually try to make some graphical explanation of this and some example code to sanity check myself and have people pick it apart, but so far on any of the projects I have approached it seems to be a good approach.