LLBLGen Pro consists of two parts: the LLBLGen Pro designer and the LLBLGen Pro runtime framework (our own O/R mapping framework). You use the designer to create the entity/domain model, define the mappings and generate source-code for one of the four supported O/R mapping frameworks. You use the generated source-code combined with the O/R mapping framework of your choice to access your database and consume the data in that database.
Below is a schematic overview of the involved elements and how they relate to each other.
The source-code generated for an O/R mapper framework is designed for that O/R mapper framework specifically, allowing you to get started with writing domain centric code right-away and utilize the power of the chosen O/R mapping framework at its fullest.
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 at runtime an Entity Definition Instance in the form of a table row or view row in an OO program via 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 an instance of a class and storing it back into the database, together with the entity definitions, is called an O/R Mapper framework. In the LLBLGen Pro designer, these are called Target Frameworks. Via this 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 or mapping definition file in XML) 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. SQL Server. 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:
- 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.
Database First vs. Model First
There are two distinctive methods to work with an Abstract Entity Model: Database First and Model First. Both are described more in detail below. The LLBLGen Pro designer doesn't force you to work in one method or the the other, you can mix them at any time, yet you should try to stick with one method and only sparsely use the functionality meant for the other method.
Database First
Database First or Database-driven is the method LLBLGen Pro v2.x worked: it reverse engineered an Abstract Entity Model from a set of database schema elements. Schematically it looks like the following:
The idea behind Database First is that the Database Schema Elements, e.g. tables, views, foreign key constraints and the like, were once created using an Abstract Entity Model and to look at the Database Schema Elements, one can reverse engineer them to an Abstract Entity Model which is roughly the same, or represents the same, as the database schema elements are projection results of the Abstract Entity Model.
If a project needs to target an existing database, this way of working with an Abstract Entity Model can be preferable over Model-first, as the Database Schema Elements can't be created through projecting an Abstract Entity Model onto a schema element as it's already there.
Model First
Model First or Model-driven is the method where the Abstract Entity Model is created first and the mappings as well as the database schema elements follow from that model. Schematically it looks like the following:
The idea behind Model First is that there's nothing defined yet, and the theoretical path of what's been discussed in O/R Mapping should be followed: build an Abstract Entity Model and use that to produce the code elements and database schema elements as both are projections from the Abstract Entity Model.
In the LLBLGen Pro designer, when working Model First, you're working directly on the Abstract Entity Model by manipulating the Entity Definitions which represent the Abstract Entity Definitions in the domain. Model First is ideal when there's no database schema yet.
