Overview
The following section describes the internal structures and components of the Data Access Layer. Against this background, the three core concepts of the O/R-Mapping, Data Mapping and the Repositories will be explained.
Basics
In the following sections, there will be a number of terms used very often, which should be clearly defined. This section deals with the explanation of the important terms and connects the dots between them in order to understand how they relate on each other.
In this context, two important terms are the Domain Model and the Persistence Model:
The Domain Model serves as a conceptual model of the domain that should be represented. The special thing of a Domain Model is, that it unifies behavior with data. That is, one entity does not only contain properties and data structures, but also the behavior of the entity in the form of logic.
The Persistence Model is a set of entities where each of the entities defines only the data, but not behavior of the entity. This is also known as the so-called POCOs. The idea by doing so is to prevent the entities from any dependencies on external frameworks like for example O/R-Mappers.
The differentiation between Domain Model and Persistence Model pays for itself when designing a so-called persistence-ignorant system, which prevents the Buiness Logic from being polluted by persistence concerns. This is an advantage because of the better readability of the business logic, which can comprehensively focus on the business process and don't need to be aware of the persistence functionality. WMS is designed as such a persistence-ignorant system to the effect that it was built without any Data Access Layer implementations except for the repository contracts. The V4 database Access Layer was implemented at a later date.
In short, the Domain Model focuses on the representation of the domain, whereas the Persistence Model concentrates on the technical and infrastructural aspects to provide the Data Access.
Another term, which has to be introduced in order to understand the following statements, is the Data Mapping. A Data Mapping represents the connector between the Domain Model and the Persistence Model. That is, it defines the logic required to map from persistence entity to domain entity and vice versa, as well as it bridges the mismatch of the two models. With this approach, it is not only possible to convert data, but also to transform complete data structures that are fundamentally different.
Another concept, which realizes the same idea is given by the O/R-Mapping. In contrast to the general Data Mapping, which was introduced above, the O/R-Mapping serves as a mapping instance to map between the relational paradigm and the object-oriented paradigm. In this context, the object-relational mapping is used to bridge the object-relational mismatch.
The subsequent section illustrates the interaction between the explained terms and brings them into a context. The single terms will be explained more detailed in the following sections:
Conceptual Design
After introducing the basic terms, the underlying concept for the Data Access will be introduced. Figure 1 illustrates the concept in form of a schematic diagram.
Figure 1: The Conceptual Design of the Data Access in the Warehouse Management System.
The figure shows a schematic diagram with five boxes, where a gray box represents a mapping component, a green box represents an object-oriented model and the blue box a relational model.
At the bottom of the diagram, the database level is illustrated in the blue box. On this level, the data are represented in the relational paradigm, which means that entities are stored in tables and have relationships by using Primary and Foreign Key Constraints. Examples of the V4 database are the tables TMS_COSTUNITSTOCKPLACE or TMS_COSTUNIT.
One level higher, the O/R-Mapping is represented. This means, in this box the database relations get mapped to their corresponding persistence entities. This is done with the help of configuration classes, which specify the mapping properties. A detailed view on this classes is given in the Object-relational Mapping section. Examples for such configuration classes are CostunitStockplaceEntityMap or CostunitEntityMap, which define the mapping from the database tables TMS_COSTUNITSTOCKPLACE respectively TMS_COSTUNIT to CostunitStockplaceEntity respectively CostunitEntity.
In the next higher level, the persistence model is represented. This is where all the persistence entities are stored in the object-oriented paradigm. On this level, the relational database structures are already abstracted, which means we are able to work with object-oriented entities and don't care about their relational representation in the persistence layer. Examples for such persistence entities are CostunitStockplaceEntity and CostunitEntity.
In the overlying gray layer, the next mapping is represented in the form of the Data Mapping. This is the place, where the persistence entities are mapped to their corresponding domain entity representation. This task is done for example in the LocationMapper or the CostunitMapper. For more details, it is to reference on the Data Mapping section.
On the highest level, the domain model is illustrated. This is the place, where the domain entities are located and can be provided to the overlying business logic layer.