Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Pure Object-oriented Domain Model by a DB Guy, Part 4 : Page 2

This is the fourth in a series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is purely object-oriented, while still focusing on roundtrips and the data access code to get good performance.


advertisement
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 so on.

+        Design-friendly.
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.

+        Encapsulation.
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 [2].
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.

The 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.

It 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.

Which is the best architecture?

Of 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.

What 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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date