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 3

This is the third 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. In this article, Jimmy will discuss the new architecture from the consumer perspective and show how it can be used for solving a simple, yet typical, use case.


advertisement

elcome back to my process of creating a new architecture. As you know, as I write this the creation process is not over, but is still ongoing. I’m changing things all the time which means the architecture is slightly different in every article. The good news is that nothing has been changed since the second part[2] was written, but don’t expect it to stay this way.

In the second part[2] (see the end of this article for endnotes) in this series I described the new architecture pretty much from a framework building blocks perspective, that is, I talked about some of the building blocks. (I said nothing about internal functionality, concentrating instead on external interfaces.) In this article I will change the approach and show how the architecture looks from a consumer perspective when solving a certain use case.

I believe that you will very quickly be able to tell from this article if you like the programming model or not. As I see it (and as I’ve said before), it’s very important that the programming model is simple for the client programmer, but it’s okay if the programming model is slightly tricky for the business tier and the database programmer. Why do I think this? Well, in my opinion the client programmer ought normally to focus on the user interface and the user interaction. If he gets a very complex API to use, it will of course require a lot of attention. There will also often be a great many views (forms etc) for one and the same part of the domain model. Duplication is automatically reduced if the code is written in the domain model instead.



This article could be read in isolation, but I do think it’s a good idea if you read part 1[1] and part 2[2] first.

The use case

The use case I’d like to use for my description is a registration of an order. The user of the application first gets the name of the customer. If the customer is found, everything is fine. If not, the customer is created. (Well, everything is still fine<g>.) Next, the user gets the name of the product they want to order and an order is created with just that single product. That’s it.

We could say that the use case has three parts:

  1. Finding (or perhaps creating) the customer
  2. Finding the product
  3. Creating the order

The Application Layer Class

The class in the application layer (or business fa



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