ore than a year has now passed
since I wrote
my book (.NET Enterprise Design with Visual Basic .NET and
SQL Server 2000[1].
The book discusses solutions to common design problems for
large-scale
applications, so several pages are spent discussing an
architecture that can be
used as a starting point for a new application. A year is
a long time in the
software industry, and it’s
very long if you
consider that the .NET
Framework was in beta when my book was published.
I’m not saying that the
architecture in the
book (let’s call it the old one from now on) is bad. Not
at all. But there are
a few things that I’m thinking about changing for future
applications. To
summarize the changes, I’d like to use a domain model that
is more
object-oriented than in the old architecture (and thereby
increase, for
example, maintainability). What I’m trying to create is a
highly effective
hybrid between object-orientation and a relational
database.
The series of articles that I’m
starting now
invites you to participate in my exploration. Perhaps I
might end up with the
conclusion that using datasets (typically typed) is the
way to go after all, or
I will find that my new architecture is more suitable for
many situations. Kind
of frightening, but also stimulating not to know myself
where we will end up.
:-)
Sidebar
what about
db-guy?
You
might be wondering what I mean by db-guy in the
title? Well, I have a habit
of being in the middle all the time. I’d like to
give you just a few examples.
When I worked part-time as a teacher at the
university, I was too much of an
entrepreneur, while at the same time in my
business perhaps a bit too much of
an academic. When I’m with a crowd of SQL
Server-guys, I’m more of a .NET-guy.
So, when I’m writing about .NET and
object-orientation, I’m probably pretty
much of a db-guy. Perhaps my next series of
articles will be called A
db-design by an OO-guy.
Why
am I telling you all this? I strongly believe that
my being a db-guy is an
advantage as I write this article, so that I don’t
lose the focus on the
database while building a pure object-oriented
domain model.
Inspiration for a New
Architecture
Before we start investigating the
changes I’m
considering, I’d like to tell you what prompted me to
start this work. First of
all, for the last, say, eight years I have been testing
several architectures
and I’m not done yet, of course. When it’s time for a new
project (with at
least some similarities to the old project), I think it’s
wise to start with
the current favorite architecture, but also to think about
what could be
improved. That’s definitely one reason why I started this
work, but there are
other reasons too.
A few months ago I read the
manuscript of
Martin Fowler’s forthcoming book, Patterns of Enterprise
Application
Architecture[2]. Fowler’s book discusses enterprise
patterns and I think it
will be a must-read almost on a par with Gamma et al’s
Design Patterns[3]. At
last we will have a common vocabulary for enterprise
patterns too. Fowler’s
book also prompted me to try the domain model pattern
again and not just work
with the Table Module pattern, which is the name Fowler
uses for the pattern of
using datasets. (The careful reader will notice my usage
of the word again
above. I have tried a pure object-oriented domain model
several times in the
past when working with VB6 and COM+ and time after time I
found it to be
problematic because of performance reasons.)
I also like not to be too
dependent on ADO.NET
in my bulk code and as a consequence I ensure that I use a
data access helper
to encapsulate most of the ADO.NET operations. The new
architecture goes a step
further by also letting go of the datasets in the bulk
code. The only layer
that will know about ADO.NET at all will be the
persistence layer and even that
one will see very little from ADO.NET because of a data
access helper. I also
like not to put more knowledge about the database schema
than is absolutely
necessary in my middle tier, which is yet one more reason
for the new
architecture.
Sidebar
Is there a single answer
regarding architectures?
No,
it all depends. What I mean is that you need
different architectures for
different applications. I think the new
architecture which I’m starting to
discuss in this article is a little more suited to
more advanced applications
than the old one. I also think the new
architecture gives more maintainable
applications, but there are drawbacks too, of
course. For example the old
architecture was a little bit more oriented to RAD
(Rapid Application
Development). We will return to this subject in
more depth later .
It’s time to tell you a little
about the new
architecture proposal, but first I think I have to do one
more thing. For those
that haven’t read the book and for those that have read
it, but have forgotten
about the old architecture, let’s take a quick
look.
Overview of
My Old
Architecture
For those of you familiar with
Windows DNA, you
will find the old architecture to be pretty similar to it.
Figure 1 shows the
diagram.
Figure 1 - Tiers and layers in the old
architecture
The different layers have
different
responsibilities and to get an idea of what each layer
does, I’d like to tell
you a bit about them.
- The consumer
layer: The consumer layer typically deals
with presentation issues, such as painting window forms or Web forms. For batch programs, the consumer layer is radically different, of course.
- The consumer helper layer: This layer hides all the
complexity of the application layer and it is adapted to the specific consumer layer implementation. That is, if you use Web forms for the consumer layer, the consumer helper layer will provide the functionality adapted to Web forms. This is also the place for generic consumer code, hiding factories, consumer-side caching and so on.
- The application layer: The application layer has one class for each use case in the application and each method is usually very bulky. That is, each method does a lot of work at the server-side in just one call to make transactions as short as possible and to reduce roundtrips. This is also the layer to use enterprise services if you need distributed transactions, for example.
- The domain layer: This layer is responsible for business rules best implemented in the business tier and not in the data tier. This layer focuses on concepts or entities rather than use cases. Note that this layer is often skipped when data is only fetched.
- The persistence layer: The persistence layer encapsulates the data tier, and the more knowledge about the database that is only kept here (and not in the domain layer for example) the better.
- The public stored procedures layer: The only way to access the database is through the public stored procedures. The public stored procedures are somewhat use case centric.
- The private stored procedures layer: And finally, the private stored procedures are again entity oriented to generalize code and also to be a good placeholder for business rules that should be implemented in the data tier but can’t be declared such as constraints.
