Browse DevX
Sign up for e-mail newsletters from DevX


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

This is the fifth part in a series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is purely object-oriented with maintainability as the number one goal, while still focusing on roundtrips and the data access code to get good performance. In this article, Jimmy will discuss the new architecture from a persistence access layer perspective.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

s I write this, four parts have been published in this series (see the left column). Now is the time to focus on how to access the database.

As I said, what we are going to talk about today is the Persistence Access layer, found slightly to the right in Figure 1.

Those of you who are familiar with parts 1-4 will probably notice that I’ve changed the name of one of the layers in Figure 1. My old Application layer is now called Service layer instead so as to more closely follow Martin Fowler’s names in his PoEAA book [5]. By this I mean that the classes in my old Application layer were following the Service Layer pattern and so I found that Service layer would be a better layer name.

Figure 1 The layer model

The purpose of the Service layer [5] pattern is to provide a service-based view on a Domain Model [5]. It’s also the case that the Service layer classes will often contain some functionality of their own, and not only be a pass-through to the Domain Model.

I have to admit that changing the name of that layer after so many years was a painful decision to take, but I think it is important to adjust to what I think is, or at least will become, the de facto name standard.

The Persistence Access layer itself is pretty similar to what I had in my book [7] two years ago. The most important change is that I’m now working with a rich domain model.

Talking of changes, I’m also considering getting rid of the Shared methods in the Persistence Access layer. (The reason for doing this is that using Shared methods takes away the possibility of using interfaces and the power of inheritance. I think interfaces and inheritance come in handy here as a solution not only for extending the functionality but also for extending testability.) But I'll leave this for now, and will come back to it next time.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



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