O/R Mapping

Object-Relational Mapping, or O/R Mapping is the general term for the concept of creating mappings between tables / views and their fields, and OO classes and their fields to be able to represent in an OO program at runtime an Entity Definition Instance in the form of a table row or view row using a class instance and vice versa.

The management logic necessary to read an Entity Definition Instance (which is the data) from the database into an instance of a class, and the other way around, storing an Entity Definition Instance back into the database using an instance of a class, is called an O/R Mapper framework.

In the LLBLGen Pro designer, these O/R mapper frameworks are called Target Frameworks. Using a target framework a developer can manipulate data in the database, using classes and their methods.

Theoretic overview

One can describe O/R mapping in theory as follows:

The source of both a code element (e.g. an entity class) and a database schema element (e.g. a table), is the Abstract Entity Definition which is part of the Abstract Entity Model. The Abstract Entity Definition is projected onto an executable form, e.g. C# and onto a database schema, e.g. a catalog in a SQL Server instance. The projection onto an executable form, will result in a class. The projection onto a database schema will result in a table or table-alike data-structures, like a view.

Because both sides, code elements and database schema elements, actually represent the same thing, namely they are both a physical representation of the Abstract Entity Definition in the Abstract Entity Model, a mapping can be defined to connect an element in the code elements (e.g. a class) with an element in the database schema elements (e.g. a table).

Over this mapping an Entity Definition Instance contained in an instance of a code element (e.g. an instance of a class) can be converted to an instance of a database schema element (e.g. a row in a table) and vice versa, as in both situations, the Entity Definition Instance represents the same thing: an instance of the same Abstract Entity Definition.

An O/R mapper framework takes care of this conversion and makes sure instances located on one side are properly converted into instances on the other side and vice versa.

Projections

In the schematic overview above, two projections are defined: from Abstract Entity Definition to Code Elements and to Database Schema Elements. These projects are described in short below

• Projection from Abstract Entity Definition to Code Element. This projection is done through code generation: an Entity Definition in the project, which is the representation of the Abstract Entity Definition, is converted into one or more classes in the form of source code by a Template or Templates.
• Projection from Abstract Entity Definition to Database Schema Element. This projection is done by the designer, using the defined mappings between an Entity Definition and the representation of a Mapping Target like a table.

The LLBLGen Pro designer and O/R mapping

In the LLBLGen Pro designer, two of the three participants in the schematic overview are visible: the Abstract Entity Definition (through Entity Definitions) and the Database schema elements, connected together by the Mappings. The third, the code elements, follow the Entity Definitions.

The main reason is that a code element (a partial class) which represents the Abstract Entity Definition in code, can have more code than what's necessary to make the class be a representation of an Abstract Entity Definition, namely also behavior and for example code and properties not related to the entity definition directly.

This means that the code elements generated follow the Entity Definitions on a 1:1 basis, however at the same time these code elements are parts of potentially larger classes (e.g. domain classes), as the generated code elements are partial classes and can be extended through other code files or through code inheritance by specifying a base class for the class to generate for an entity definition, which results in a complete class which is richer than the generated code element alone.

Having the projection of that complete class inside the designer as well would limit the freedom of a developer and as such falls outside the scope of the designer.