This post originated from an RSS feed registered with .NET Buzz
by Tim Sneath.
Original Post: Is the Business Tier Dead?
Feed Title: Tim Sneath's Blog
Feed URL: /msdnerror.htm?aspxerrorpath=/tims/Rss.aspx
Feed Description: Random mumblings on Microsoft, .NET, and other topics.
With the PDC in mind, I was experimenting with two of the most broadly advertised
features of Yukon earlier this week: CLR hosting in the database engine, and ObjectSpaces.
If you missed the TechEd announcements and haven't seen these features at VSLive!
or elsewhere, there's some detail in
this chat transcript. To summarise briefly, with the Yukon release, the plan is
to integrate the CLR directly into the database engine, allowing .NET assemblies to
be catalogued in a database. This will allow stored procedures, functions and triggers
to be built using a language such as C# in addition to, or instead of Transact-SQL.
ObjectSpaces is a technology that was demonstrated at the last PDC two years ago that
will provide an object persistence framework; with the right code, you'll be able
to use ObjectSpaces to simply serialise objects into one or more tables in the underlying
database.
A long discussion with Eric Nelson, one of my colleagues, and a shorter discussion
with Niels Berglund from DevelopMentor
led to a few initial musings. As ever with a blog, these are my personal opinions
rather than the considered corporate view of Microsoft, and there's a lot of water
to go under the bridge before the release.
At a superficial level, it seems that ObjectSpaces does away with the need for a complex
data access layer (DAL) to a greater or lesser extent. If you can tell an object to
go persist itself into the database, and by providing some extra metadata ensure that
it knows how to go about achieving that, the work of a database tier is generally
complete. Of course, there are plenty of questions that a developer needs to consider,
such as security, the database schema itself, and performance and scalability issues;
but none of these are insurmountable given a good enough supporting infrastructure.
Let's park that thought for a moment, and consider the other big new feature: SQLCLR.
We've been running a number of labs over the last eighteen months that I've been involved
with, where ISVs have brought their .NET development projects in to the UK office
and we've worked with them on any issues they are experiencing with moving to .NET.
I've observed that many of them have quite lightweight business logic layers (BLLs)
- because their applications are fundamentally pretty data-centric and they've been
able to create a design that has a pretty close mapping between business objects and
data entities. For a while I've wondered how much of that layer exists primarily to
avoid the need to write large quantities of T-SQL.
Indeed, many business layers have two major functions. Firstly, they support a workflow
that matches the underlying business process; secondly, they provide some business-level
consistency checking for data input via the UI. I've always been uncomfortable with
the latter function as a database bigot: as far as I'm concerned anything that relates
to the consistency of the data should be done as close to the data itself as possible.
Sometimes I have conversations with developers that leave me worried that a user bypassing
the business application could insert data that might break the application itself.
Now we've got SQLCLR, it's possible to move that business-level consistency checking
directly into the database as triggers or stored procs written in C#. The devs are
happy because they don't have to use T-SQL - and the DBAs are happy that the ACID
principle hasn't been violated (once they've got their heads around compiled code
being stored on their server). So where does that leave the business tier? Greatly
diminished, I'd argue, particularly when other factors that will no doubt be revealed
at the PDC are taken into account.
So, are we going to be able to eradicate one of the three logical application layers
within the next few years? I wonder...
Previous Topic
