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

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
’d like to start today by getting rid of a myth. Just because we have decided to work with custom classes doesn’t mean that we also have to decide to use a stateful model on the application server. We can work in a similar way as with DataSets so that everything is torn down at the application server after a request has been fulfilled. This is commonly known as a stateless model. The only real difference is that when using custom classes the data structure is typically smarter and more encapsulated than when using DataSets, since custom classes have custom behavior as well as the data, and won’t allow completely open access to data.

You can inherit from a DataSet and add your custom behavior to the subclass, but the encapsulation is still weak. A better solution then is to wrap a DataSet in a custom class of your own. You can find more about that here [1].

The next question then might be: But isn’t this wasteful? Creating a lot of objects only to return them to the client and then tear them down? Well, sure, it is. But it’s no more wasteful than creating a lot of DataRows in a DataSet, returning the DataSet to the client and tearing down the DataSet at the application server. That is just as wasteful.



OK, what’s the alternative then? We can be stateful on the server, letting the object stay and live between requests. We can even share objects between users, but this can be done both when DataSets are used and when custom classes are used for the domain data. The downside this time is that it very quickly gets much more complicated! To give a simple example, think about what happens when you find out that you need to add another application server to handle massive load. You then have a difficult problem to solve, with the shared and stateful objects being up-to-date on two separate application servers, then on three, and so on. This is a hard problem, at least if you want a good solution. Another really tricky problem in real world applications is the threading synchronization needed for shared objects. There are simple solutions to the problem, but those also pay a high price as far as efficiency is concerned.

So, we can write stateless applications with server-side objects per request just as many of us are used to doing, even if we decide to go for a domain model based on custom classes. We don’t have to, but it’s a simple and highly efficient solution. That’s the path I’m taking in this series of articles.

OK, things aren’t as black and white as I’m making them sound here. For instance, I like read only data to be both stateful and shared between requests. Since it doesn’t change, we don’t have the usual risk of caches getting out of synch.

Also, I often keep instances in the Application layer alive during the execution of a complete use case. That is, I often call several methods on an Application layer instance without re-instantiating it between calls. But the objects that are returned from the methods are most often not kept stateful at the application server and the objects are almost never shared between users or even requests.



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