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.

Model your domain the way you want it

Entity definitions, Value Type definitions, Typed View definitions, Typed List definitions, calls to Table-Valued Functions and Stored procedures, they're all available to you. Additionally there are fine-grained options available like marking entities as read-only or specify validation attributes based on rules. Define derived models on top of the entity model to expose entity data through services or denormalized NoSQL databases.

How to switch the target framework for a model

The Entity Model and each Derived Model require a target framework: an Entity Model requires one of the supported ORM Frameworks, a Derived Model requires one of the supported Derived Model frameworks. It might be at some point you want to switch a target framework for a model. Below is explained how you can do that.

If you decide to switch the target framework for your entity model or for a Derived Model, you can do so by right-clicking the target framework node in the Project Explorer right below the model you want to change the framework for. The target framework node uses the icon. The dialog which pops up contains all supported target frameworks for that model. By selecting a different target framework and clicking OK, you have effectively switched the project to a different target framework.

LLBLGen Pro will create a backup of the project prior to switching the model in question to a different target framework, so you can always go back to the previous version. Switching the target framework is an action which can't be undone in the designer by clicking Undo.

Switching the target framework changes the settings which are available to you. Settings which are shared among the frameworks will be available still, but settings which aren't available in the new framework will be discarded. Please use the Project Settings Editor and the editor of the various elements to examine whether you should set settings to a different value.

After switching a model to a different target framework it might be validation now produces errors and/or warnings, as not every target framework supports all the designer features. It's therefore key to perform a Project Validation action and to correct the errors found before continuing.

The code you previously generated using the previous target framework can't be used with the new target framework, you have to generate new code, using one of the presets available for the chosen target framework. It's recommended you generate this sourcecode in a new empty folder, so you can migrate back if necessary.

How to work model-first

LLBLGen Pro supports both Database First and Model First development. This article describes briefly which functionality of the designer is available to you when you want to work Model First as well as how the typical Model First work flow looks like.

Work flow of Model First

The schematic workflow of Model First development looks like the following:



The flow of data is from the editors for the Abstract Entity Model towards the RDBMS using the Relational Model Data storage in the project as a stop in between them. This has the advantage that you can keep working on the relational model data through the Abstract Entity Model without the necessity to be connected to the RDBMS.

A couple of processes are used to get from an Abstract Entity Model to a schema definition in an RDBMS: Syncing Relational Model Data and Generate Database Schema Create / Update Scripts. Sync Relational Model Data results in relational model data in the Relational Model Data storage, if new elements have to be created, and mappings between the elements in the Abstract Entity Model and the elements in the Relational Model Data storage.

The changes made to the relational model data are exportable as a Create script or Update script. The scripts are then usable to create a new schema or update an existing schema in an RDBMS.

Let's break this down into smaller steps, from creating an entity in the Abstract Entity Model to a Create script for a schema. The following steps use the conventional tools, not Quick Model, however if you want to create the entity using Quick Model, you're free to do so.

Create a new project in the LLBLGen Pro designer and choose a target framework. For 'Initial contents' for the project, select 'Relational Model Data container for a databases (Model First)'.
Click OK in the Create New Project dialog to create the project. The 'Relational Model Data Store Database Type Selector' dialog opens to allow you to select the database type for which the designer should create a Relational Model Data container to store the relational model data like table definitions. In the dialog, select the database you want to use in your project and click OK. Keep in mind that DDL SQL scripts aren't supported on MS Access, so choose a database other than MS Access. In an empty project you can open this dialog by right-clicking the 'Relational Model Data' node in the Project Explorer or Catalog Explorer and select Add Relational Model Data Storage for a Database from the context menu.
Examine and eventually adjust the Project Settings so creating entities and the like are created comform the settings you want.
Click the New Entity button on the toolbar, or press ctrl-shift-E or select Project -> New -> Entity, to create a new entity definition. Specify a name for the entity in the dialog, e.g. 'Customer', and click OK.
Right-click in Project Explorer the entity you just created and select Edit... from the context menu. The entity is opened in its Entity Editor.
Click the top row in the grid on the Fields tab and specify a name and a type for the first field, e.g. 'Id' and 'int', using the TAB key to move between columns and complete pre-selections in the columns. Press TAB to move the cursor to the Optional column and press cntrl-Enter to add the field.
Press ctrl-shift-F to add a new field, e.g. 'Name' and as type 'string'. Again press cntrl-Enter to add the field
Repeat step 7 a couple of times till you have enough fields in your entity.
Click the Edit... button next to the Identifying Fields text box. In the dialog popping up select the Id field you created in step 6 to mark it as the Identifying Field (the 'pk')
Select Project -> Sync Relational Model Data from the main menu or click the Sync button button in the toolbar.
The Sync Relational Model Data tab is opened. Make sure the sync sources for your schema elements are set to Model and click Perform Tasks. This will make LLBLGen Pro create a new table in the Relational Model Data storage added in step 2 and mappings between the entity you created in steps 4-8 and the newly created table. A log is shown what actions have been taken for you. To examine the mappings, click the Field Mappings tab of the editor of the entity you created. To quickly find the table created, click the Lookup button button next to the Mapping Target on the Field Mappings tab to go to the node of the table in Catalog Explorer. You should now see a table definition with primary key and fields in the Catalog Explorer.
In Catalog Explorer rename the schema and / or catalog node if you want to have a different name for these in your actual database.
Right click the 'Relational Model Data' node in the Project Explorer or Catalog Explorer and select Generate Database Schema Create Script (DDL SQL) from the context menu. This will bring up the Code Generation Task Viewer dialog to guide you through the DDL SQL script creation process of exporting a create/update script.
Run the generated script on the relational database you have chosen to work on. Keep in mind that it's likely that you have to manually create the database / schema in the RDBMS as these operations are often not scriptable or require manual input. The script contains, when applicable, code to help you with this.
With Model First you walk every time the steps 4-9 to create entities, relationships and the like, and after that the steps 10-14 to finalize your changes to be usable by generated code.

Tools and functionality available to you

The designer contains a lot of functionality, both visible and hidden beneath the surface, which help you work with an Abstract Entity Model using a Model First workflow. The following list of features are mainly used for and designed for working Model First.

Quick Model. A text based DSL system which lets you quickly specify entities, relationships and other Abstract Entity Model elements.
Entity Editor. The editor for editing entity fields, mappings and other entity related details.
Normal Relationship Editor. The editor which allows you to specify / edit 1:n/m:1/1:1 relationships between entities
Many-to-Many Relationship Editor. The editor which allows you to specify / edit a Many-to-Many relationship based on two m:1 relationships.
Syncing Relational Model Data. The process of synchronizing the relational model data in the Relational Model Data storage with a source (in this case, the Abstract Entity Model), by auto-creating relational model data elements and mappings based on the elements in the Abstract Entity Model.
Designer Preferences and Project Settings, especially the relational model data element naming construction and validation sections.
Catalog Explorer with its context menus on various nodes to for example exclude a set of elements (like a set of tables) or to rename a schema or table or mark an element (e.g. a field) for deletion.
Working with Types and Default values using Type Shortcuts
On the Field Mappings tab of the Entity Editor or other project element editors the following utilities:
Create mapping, Remove mapping, New target... and New sequence... buttons.
Sync selected... button. This button makes it easier to sync a model field's type specification with its mapped target field, e.g. if you changed the mapping
Auto-map unmapped fields to new target fields button, which makes it easier to create new target fields on the fly
Edit field..., New field... and Auto-new field buttons which allow you to make micro changes to an existing table field, or create a new table field, either from scratch or from the current selected field mapping.
Generate Database Schema Create / Update Scripts. The functionality to export changes to the relational model data in script form to apply them to the schema in the RDBMS you want to target.
Additionally, the rich editing system of the designer for the Abstract Entity Model elements is at your disposal.

Mixing Model First with Database First

It's ok to mix a Database First workflow with a Model First workflow. In the Sync Relational Model Data tab, you can specify which elements are sourced from which source, e.g. source the tables from the Abstract Entity Model and views / stored procedures from a database. You can do that by setting the sync sources in the Sync Relational Model Data tab of the involved schemas to Mixed.

World-class generated code

Powerful, template based code generation framework

The code generation system is based on a series of tasks. You can easily control which code is generated, using templates which can be edited inside the designer. Of course all generated code is using partial classes and doesn't overwrite files which are meant to be edited by you.
Read more

Source-code as if you wrote it, generated for you

The code generated by the designer is structured as you'd structure it yourself, with a file per class and class files grouped in namespaces. Every method and property is well documented using XML document tags and the code is properly formatted like a professional developer would do.

Class models designed for the target ORM

All code generated for the chosen O/R mapper is the code you'd write too for that O/R mapper: the code needed to utilize the ORM in full, no needless fluff. The class models generated use the patterns recommended for the target O/R mapper, and offer plenty of extension points.

Visual Studio ready

Generated code is properly organized in Visual Studio projects: one for domain specific classes and one for persistence oriented classes. The generated cs/vbproj files are updated when appropriate and loaded in your solution when using the designer inside Visual Studio.

Solid and reliable

Extensible and open

The Designer is fully extensible with your own plug-ins, code generator add-ons, templates, database drivers and more. All customers get full access to the sourcecode of many vital parts of the designer to adjust them to their specific needs, if required.

Designed to handle models with thousands of entities

Professional software projects often utilize large databases with large entity models. The LLBLGen Pro Designer is designed to handle these kinds of scenarios with ease. It offers various different ways to look at and work with the entity model so you're always in control over your entity model, no matter the size.

Fine-grained, real-time project validation

The designer validates the project, in real-time, on general mistakes and inconsistencies and uses plug-in based validators to validate the project specifically for the chosen target O/R mapper framework. This makes validation both flexible and extensible as the validators are available as C# sourcecode to customers.

Proven technology

LLBLGen Pro is being used by thousands of companies around the world every day, from fortune 50 companies to single-person consultancy firms. Since its first release in 2003, LLBLGen Pro has proven to them to be a reliable and trustworthy partner in their software development process.

Complete

All the tools you need under one roof

The designer offers the complete toolset to get from database schema to working source-code or from entity model to working source-code and DDL SQL create / migrate scripts.

Utilize multiple database types in one project

An LLBLGen Pro project can contain relational model data from multiple relational databases, while containing a single model mapped to the relational model data of each database type.

All major databases are supported

All major relational databases are supported, and it is very easy to switch your model from e.g. Oracle to PostgreSql or SQL Server. The designer can deal with all database constructs and types, even UDTs.

Use the .NET version, language and ORM you like

The Designer generates code in both C# and VB.NET, for .NET 3.5 / 4.0 / 4.5 / 4.5.x / 4.6.x / 4.7.x, NET Standard 1.6, .NET Standard 2.0, for the O/R mapper frameworks Entity Framework, Entity Framework Core, NHibernate, Linq to Sql and our own LLBLGen Pro Runtime Framework. The choice is yours.

Only for V.I.P