Browse DevX
Sign up for e-mail newsletters from DevX


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

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

Save() in Persistence Access Layer

As I said, the Service layer method in Listing 1 is talking to a Unit of Work, but it’s also talking to at least one Data Mapper class. In Listing 1, the Data Mapper class is called POrder. Figure 3 shows an example of classes in the Persistence Access Layer.

Figure 3 Some of the classes in the Persistence Access Layer

As you saw in Figure 3, all the Data Mapper classes inherit from the Layer Supertype [5] class DataMapperBase. In this case, the Layer Supertype is exposing a lot of protected functionality to the sub classes.

The purpose of the Layer Supertype [5] pattern is to gather similar classes under a superclass, for example, to generalize code.

What the Data Mapper class POrder does in this particular example is actually only add information to the Unit of Work. However, the information that is typically database related is encapsulated, so that only the Data Mapper knows about it and, for example, the Domain Model classes don’t have to know about it at all. There is an example of a method in a Data Mapper in Listing 2.

Public Shared Sub SaveOrder(ByVal order As Order, _
ByVal unitOfWork As UnitOfWork)

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