RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


A Pure Object-oriented Domain Model by a DB Guy, Part 1

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.

ore than a year has now passed since I wrote my book (.NET Enterprise Design with Visual Basic .NET and SQL Server 2000[1]. The book discusses solutions to common design problems for large-scale applications, so several pages are spent discussing an architecture that can be used as a starting point for a new application. A year is a long time in the software industry, and it’s very long if you consider that the .NET Framework was in beta when my book was published.

I’m not saying that the architecture in the book (let’s call it the old one from now on) is bad. Not at all. But there are a few things that I’m thinking about changing for future applications. To summarize the changes, I’d like to use a domain model that is more object-oriented than in the old architecture (and thereby increase, for example, maintainability). What I’m trying to create is a highly effective hybrid between object-orientation and a relational database.

The series of articles that I’m starting now invites you to participate in my exploration. Perhaps I might end up with the conclusion that using datasets (typically typed) is the way to go after all, or I will find that my new architecture is more suitable for many situations. Kind of frightening, but also stimulating not to know myself where we will end up.

Sidebar what about db-guy?

You might be wondering what I mean by db-guy in the title? Well, I have a habit of being in the middle all the time. I’d like to give you just a few examples. When I worked part-time as a teacher at the university, I was too much of an entrepreneur, while at the same time in my business perhaps a bit too much of an academic. When I’m with a crowd of SQL Server-guys, I’m more of a .NET-guy. So, when I’m writing about .NET and object-orientation, I’m probably pretty much of a db-guy. Perhaps my next series of articles will be called A db-design by an OO-guy.

Why am I telling you all this? I strongly believe that my being a db-guy is an advantage as I write this article, so that I don’t lose the focus on the database while building a pure object-oriented domain model.

Inspiration for a New Architecture
Before we start investigating the changes I’m considering, I’d like to tell you what prompted me to start this work. First of all, for the last, say, eight years I have been testing several architectures and I’m not done yet, of course. When it’s time for a new project (with at least some similarities to the old project), I think it’s wise to start with the current favorite architecture, but also to think about what could be improved. That’s definitely one reason why I started this work, but there are other reasons too.

A few months ago I read the manuscript of Martin Fowler’s forthcoming book, Patterns of Enterprise Application Architecture[2]. Fowler’s book discusses enterprise patterns and I think it will be a must-read almost on a par with Gamma et al’s Design Patterns[3]. At last we will have a common vocabulary for enterprise patterns too. Fowler’s book also prompted me to try the domain model pattern again and not just work with the Table Module pattern, which is the name Fowler uses for the pattern of using datasets. (The careful reader will notice my usage of the word again above. I have tried a pure object-oriented domain model several times in the past when working with VB6 and COM+ and time after time I found it to be problematic because of performance reasons.)

I also like not to be too dependent on ADO.NET in my bulk code and as a consequence I ensure that I use a data access helper to encapsulate most of the ADO.NET operations. The new architecture goes a step further by also letting go of the datasets in the bulk code. The only layer that will know about ADO.NET at all will be the persistence layer and even that one will see very little from ADO.NET because of a data access helper. I also like not to put more knowledge about the database schema than is absolutely necessary in my middle tier, which is yet one more reason for the new architecture.

Sidebar Is there a single answer regarding architectures?

No, it all depends. What I mean is that you need different architectures for different applications. I think the new architecture which I’m starting to discuss in this article is a little more suited to more advanced applications than the old one. I also think the new architecture gives more maintainable applications, but there are drawbacks too, of course. For example the old architecture was a little bit more oriented to RAD (Rapid Application Development). We will return to this subject in more depth later .

It’s time to tell you a little about the new architecture proposal, but first I think I have to do one more thing. For those that haven’t read the book and for those that have read it, but have forgotten about the old architecture, let’s take a quick look.

Overview of My Old Architecture
For those of you familiar with Windows DNA, you will find the old architecture to be pretty similar to it. Figure 1 shows the diagram.

Figure 1 - Tiers and layers in the old architecture

The different layers have different responsibilities and to get an idea of what each layer does, I’d like to tell you a bit about them.

  • The consumer layer: The consumer layer typically deals with presentation issues, such as painting window forms or Web forms. For batch programs, the consumer layer is radically different, of course.
  • The consumer helper layer: This layer hides all the complexity of the application layer and it is adapted to the specific consumer layer implementation. That is, if you use Web forms for the consumer layer, the consumer helper layer will provide the functionality adapted to Web forms. This is also the place for generic consumer code, hiding factories, consumer-side caching and so on.
  • The application layer: The application layer has one class for each use case in the application and each method is usually very bulky. That is, each method does a lot of work at the server-side in just one call to make transactions as short as possible and to reduce roundtrips. This is also the layer to use enterprise services if you need distributed transactions, for example.
  • The domain layer: This layer is responsible for business rules best implemented in the business tier and not in the data tier. This layer focuses on concepts or entities rather than use cases. Note that this layer is often skipped when data is only fetched.
  • The persistence layer: The persistence layer encapsulates the data tier, and the more knowledge about the database that is only kept here (and not in the domain layer for example) the better.
  • The public stored procedures layer: The only way to access the database is through the public stored procedures. The public stored procedures are somewhat use case centric.
  • The private stored procedures layer: And finally, the private stored procedures are again entity oriented to generalize code and also to be a good placeholder for business rules that should be implemented in the data tier but can’t be declared such as constraints.

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