Sunday, November 30, 2008

data layer

New!!!
IT Job Bank
Find IT jobs near you.

Enter Location: (City, State or ZIP)


powered by:



It is commonly held as a truth that applications have a UI layer, a business layer and a data layer. In most of my presentations and writing I use a four-layer model: UI, business, data access and data storage. In this case the "data storage" layer is really the same as the traditional data layer in a three-layer model.

But I want to challenge this idea of a data layer. Over the past few months, in discussing service-oriented architecture (SOA) as well as distributed object-oriented architecture, I have become increasingly convinced that the idea of a data tier, data layer or data storage layer is fundamentally flawed.

Note that in this article I use the word "layer" to describe logical separation between concepts regardless of physical configuration, while "tier" means a physical separation. That said, the reality is that a typical data layer really is also a data tier, because most data layers exist in the form of SQL Server, Oracle or some other server-based database engine.

Service-orientated design leads us to the idea that any software component used by more than one other software component (used by more than one "client") should be a service. A service is a powerful unit of reuse, providing a contractual interface by which clients can interact with the service.

More importantly, a service defines a trust boundary. This means that a service protects itself against invalid usage by clients. This is one of the defining elements of service-orientation and is a key benefit. The benefit is that a service can safely service many disparate clients because it trusts none of them. The service ensures that all clients get the same behaviors, and that any data sent to the service by any client is checked for validity based on the rules of the service.

My contention is that the traditional "data layer" is the ideal candidate to be a service.

Consider all the layers in a typical application:

* User or other consumer
* Presentation technology
* UI logic
* Business logic
* Data access logic
* Data source

We tend to think of these as a stack, from user down to persistent data s

No comments: