My Favorite Style
One important part of my favorite
default design is the layer I call the Application layer, which you can see
in context of a complete package diagram shown in Figure 1.
Figure 1 The layer model
The idea of the Application layer is that it is the one and only gateway
to the Business tier (and therefore also to the Data tier) from the consumers.
I find this layer a great help in writing stateless server-side applications.
It’s not essential, but is helpful. Other advantages are:
You will typically get a chunky interface instead of a chatty interface.
This is especially important if there is an AppDomain (often called a logic
process) boundary between the Consumer tier and the Business tier.
A placeholder for service-related functionality.
This layer is very much about service-orientation and this is where I think
you should deal with such things as starting and ending database transactions
(logically not physically), checking privileges, high level auditing, and
In my opinion, analyzing and designing systems by starting with the use
cases is a very efficient methodology. For example, the clients understand
it and participate efficiently right away. In addition, if you have the very
use cases in the code, then you have very good traceability from requirements
to solution. I believe that helps maintainability a lot.
What happens behind the Application layer is completely encapsulated for
the consumer tier, which means you can change it when you need to without
having to change the consumer code. You have the chance of exposing a minimal
and controlled interface to the consumers.+
A general interface.
You have a pretty good chance of being able to reuse the same Application
layer from different types of consumer tier applications. You might have to
add a thin wrapper in some cases, but it usually won’t be any worse than that.
A placeholder for Transaction Scripts .
This is the natural place to have your Transaction Scripts, if you use
them. For example, this is how to coordinate actions on several domain objects,
interactions with the database, and so on. To a certain degree, I think Transaction
Scripts are nice, just watch out so you don’t overuse them. As always the
same rule applies: namely, everything in moderation.
Transaction Script pattern means that a couple of statements are bunched
together in a method and executed one after the other.
I know you won’t believe me if
I don’t give any disadvantages, so here are some:
Over design of simple applications.
For some simple applications, having this layer might feel like over design
Risk of a less rich user interface experience.
You will move some behavior pretty far away from the consumer. This means
the consumer might not get instant feedback from actions, but get feedback
only after several actions have been made and submitted. On the other hand,
since by default I let the domain model objects travel from application server
to consumer, this risk is reduced quite a lot.
is not the objects themselves but the state of the objects that is traveling.
The illusion of traveling objects is created for us through .NET serialization.
Is it necessary to have an Application
layer with web applications, or is it only beneficial when you have an AppDomain
boundary between the Consumer tier and the Business tier (which you generally
don’t have in the case of web apps)? Well, first of all the word generally
is a clue here. You might have an AppDomain boundary in the future,
and even if you don’t, the other advantages apply.
is the best architecture?
course, I’m not even trying to persuade you to believe that the architecture
I’m discussing today is the best whatsoever. There is of course no such
architecture around today nor will there ever be. It’s like asking what
the best meal/house/car etc is.
I’m discussing here is what I personally think is the best default
architecture for me and the kind of systems I usually develop.
Hmmm What’s the best default meal/house/car for me and the typical situations
I’m in? I’m still trying to oversimplify I guess.