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 2

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
A Few More Comments on the Old Architecture
Worth mentioning is that my old architecture is more database centric than Windows DNA since I think that all database access should pass by stored procedures. I also tend to let the classes in the domain and the persistence layer only have shared (static) methods since they don’t need any instance data. What is not different from Windows DNA is that I use datasets for holding data and for letting data travel between tiers, and then the other classes are operating on the data in the datasets. (OK, Windows DNA was before .NET and used ADO Recordsets instead.)

That was a really quick glimpse at the old architecture. What I really wanted to point out is that datasets are used for holding data while classes in different layers are used for acting on the data in the datasets.

Overview of the New Architecture
Is this like starting all over again and forgetting everything in my book? Definitely not. Everything in the book is still valid but I’m just building on it. For instance, the BatchCommand pattern (or Unit of Work as Fowler[2] calls it) is very important, but let’s not move too fast right now. Instead, I’d like to give an overview of the new architecture, shown in Figure 2.


Figure 2 - Tiers and layers in the new architecture



I’m aware that it might be a mistake to allow the Consumer tier to see the Domain model after serialization, instead of just receiving DTOs (Data Transfer Objects[2], but for the moment I’d like to try this out as a starting point, especially for less advanced applications. For advanced applications it’s probably better to save this refactoring and go for DTOs directly. So please hold back the flaming mails about this<g>.

As you see, on the surface the new architecture is very similar to the old one. The only real difference is that the Domain layer (or rather model) is known by Consumer layer, Consumer helper layer, Application layer and Persistence layer. Instead of using system provided containers (such as datasets) for holding the data, I am now using custom domain classes to do this. To be honest, the old architecture would also have an assembly known by all the other layers if you are using typed datasets, so the old architecture with typed datasets would look more like as shown in Figure 3.


Figure 3 - Tiers and layers (with strongly typed datasets) in the old architecture

First I thought that I would change the name of the Application layer to Service layer[2], but I haven’t decided on that yet. OK, Fowler uses the name Service layer, but on the other hand Microsoft is currently talking about Process layer, so I think I’ll stay with Application layer for the time being. I have also learned that service layer means completely different things to different developers.

So, the purposes of all the layers are the same as they are in the old architecture. It’s just that the Domain layer (or model) is slightly changed and takes on a much greater responsibility. Its classes become the main part of the programming model, which are greatly interacted with in both the Consumer tier and the Business tier.

Some Details
That was a quick look at the new architecture proposal. I think we should already take a look at some details here in the introduction of the article series to see the old and the new architecture side by side.

One of the best things about writing a book is that I have received a lot of interesting emails containing feedback. Some have asked what I think about solving relationships in the middle tier. That is, how to build the navigation from a customer to all his orders and from a specific order to all the items of that order and so on. My immediate answer was that typed datasets help with just that. That’s true of course, but you normally navigate via foreign keys then in the middle tier too. Unfortunately, knowledge about the database schema is spread all over the place. Another problem is that you will often have two separate typed datasets between which you want to navigate. I mean, you don’t have one single model that is completely navigable, but you have several small models, which will probably overlap each other.

Let’s take quick example on how to navigate in the domain models. In the old architecture I would normally use datasets. For the example here I will discuss customers and orders which I’m sure all of you can identify with. So, in Figure 4 there is a typed dataset with two datatables called Customers and Orders. I have set up a relationship (which is called CustomersOrders) via the foreign key in the Orders datatable (which is called Customer_Id).


Figure 4 - A dataset with two datatables

(Figure 4 shows one way of building the dataset. There are others of course, but let’s stay with this for now.)

Assume that the consumer has received the typed dataset CustomersAndOrdersDS in the variable called theCustomersAndOrders. The navigation code then looks like in Listing 1.

Dim aCustomer As CustomersAndOrdersDS.CustomersRow Dim anOrder As CustomersAndOrdersDS.OrdersRow For Each aCustomer In theCustomersAndOrders.Customers For Each anOrder In aCustomer.GetChildRows("CustomersOrders") Console.WriteLine(anOrder.OrderNo) Next Next

Listing 1 - Navigation in the old architecture


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