I’ve had time lately to think about the nature of data in development lately.  I’ve been talking with Rocky Lhotka and Michael Earls about it (as well as number of others) about the issues with dealing with data in applications.

The first camp is all about writing Business Objects.  In this camp, you write classes that encapsulate the data, the data access and business rules about that data.  This camp was the way to do it for years now.  It proliferated in the Client-Server and n-Tier architecture camps.

Rocky Lhotka espouses his excellent CSLA.NET framework.  If you are going the business object road, I wholeheartedly recommend it.  It is designed around allowing object to exist locally or on separate servers through remoting.

The second camp is that data is all about data, so data is just a message to some system.  With the excitement around Service Oriented Architectures (SOA), this view is starting to prevail.

Somewhere in the middle is where I sit.  I think that data and business rules belong together, but the data access can be disconnected from it.  So this is the interesting fact in my opinion…there are reasons to have the data access separated from the end users’ machines (so perhaps remote data access), but once in the client, you want to have the business logic (and schema) as close to the client as possible.  The closer it is to the client, the better it should scale.  I don’t like to see finely grained data access happening.  Even in client-server apps, the more coarsely grained the data access, the better it should scale IMHO.

There is more I want to say on this, so stay tuned.  I will be posting every day about this.

Tomorrow:  “n-Tier, gone tomorrow”