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 1 : Page 3

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


advertisement
The New Architecture
In the new architecture, I have built a small framework myself for my domain classes and the persistence layer. Instead of using datasets, I inherit from my custom base classes EntityCollectionBase for collections and EntityBase for classes describing distinct entities. In Figure 5, you can see that Customer and Order inherits from EntityBase and CustomerCollection and OrderCollection inherits from EntityCollectionBase. The base classes help by providing general functionality and policies to the subclasses.
Figure 5 - Overview of part of the framework for the new architecture

The base classes implement a couple of custom interfaces too and I’m only showing public members above. That is so as not to complicate the picture more than necessary for the moment.



Before we continue, let me stress that using EntityBase and EntityCollectionBase in themselves won’t make anybody happier. It’s when we start adding custom code to the domain model that it gets exciting.

Let’s take a look at a code snippet for how to navigate customers and their orders in the new architecture. There is an example in Listing 2. This time the consumer has received a CustomerCollection and the variable is called aCustomerCollection.

Dim aCustomer As Customer Dim anOrder As Order For Each aCustomer In aCustomerCollection For Each anOrder In aCustomer.Orders Console.WriteLine(anOrder.OrderNo) Next Next

Listing 2 - Navigation code in the new architecture

As you saw, the two architectures are very simple when it comes to navigation in a part of the domain model. Where can we find some differences between the architectures? Well, let’s start by comparing the interface of a class in the Application layer. There is a typical class from the old architecture in Figure 6.


Figure 6 - A class from the Application layer from the old architecture

The same class in the new architecture could look like as shown in Figure 7.


Figure 7 - A class from the Application layer from the new architecture

As you saw in Figure 6, the old architecture mostly uses primitive types (and datasets) for the parameters. The new architecture uses custom classes. Note especially the usage of the Id-parameter in the old architecture. Once again this means that the structure of the database is used everywhere.

One problem with the old architecture that has been bugging me for years (since I’ve had the same problem with earlier tries too) is that the business rules have been set-based and evaluated kind of late in the scenarios. That is, it has been possible to add values to columns and rows that later on proved to be wrong. The validation was on all rows at once (if the scenario was one where the end-user could add several orders in a row, for example). It would be nice to be able to express and check simple rules on the row-level and column-level (or object-level and property-level if you so wish). With datasets you can set up some constraints, but they are not flexible enough for the generic case in my opinion.

One related problem is that in my old architecture, the rules were separated from the data. One solution for this is to use the pattern that Reynolds and Watson present in their book .NET Enterprise Development in VB.NET[4], which is to inherit from a dataset and then you can put the validation code in the sub-class.

So, let’s compare the checking of rules. Checking a simple rule in the old architecture could look as shown in Listing 3.

For Each aCustomer In theCustomersAndOrders.Customers If aCustomer.Name = "Volvo" Then Throw New ApplicationException _ ("The customer may not be named Volvo!") End If Next

Listing 3 - Checking a rule in the old architecture

And let’s do the same thing in the new architecture, where the data is contained together with the rules, in Listing 4.

Public Property Name() As String Get Return _name End Get Set(ByVal Value As String) If Value = "Volvo" Then Throw New ApplicationException _ ("The customer may not be named Volvo!") Else _name = Value End If End Set End Property

Listing 4 - Checking a rule in the new architecture

As you saw above, it’s very easy to put rules at the object-level instead of at the set-level (I mean on several rows at a time) which is the way to do it in the old architecture. (Please notice that the code in Listing 4 well, that goes for Listing 3 too represents a na



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