Concepts - Entities, Typed lists and Typed views

Preface

Entities, typed lists and typed views are the elements forming the building blocks of the functionality you design with the LLBLGen Pro system. The designer of the LLBLGen Pro system lets you design these elements before they are used to generate code. Below you'll find a short description per element of what the element stands for, how it is used in the LLBLGen Pro designer and in which context you should place the element when using the generated code.

The text below can be a little theoretic at first, but don't let that stop you reading it. Each subsection has, when applicable, a summary which explains in short what you need to know, which is enough to get started with the designer later on. When available, documents on the internet are linked to help you further understand what the background is of certain theories used. If some theory is not completely clear to you, you are advised to download the documents linked at the bottom of this page or visit the sites mentioned. It is however not necessary to become an expert in E/R model, NIAM/ORM (Object Role Modelling) or other modelling technique to work with LLBLGen Pro. On the contrary: when you understand the basic concepts behind these modelling techniques and theory, you are fully equipped to start designing your first LLBLGen Pro project!

Entities

LLBLGen Pro's core element to work with is the Entity. The term 'Entity' has a lot of, often contradicting, definitions: Martin Fowler defined the entity differently than the people who defined it decades ago: Peter Chen and Edward Yourdon. LLBLGen Pro uses the 'ancient' definition of an 'entity', defined by Dr. Peter Chen in relation to his Entity Relationship Model ^[1]:

"Entity and Entity set. Let e denote an entity which exists in our minds. Entities are classified into different entity sets such as EMPLOYEE, PROJECT, and DEPARTMENT. There is a predicate associated with each entity set to test whether an entity belongs to it. For example, if we know an entity is in the entity set EMPLOYEE, then we know that it has the properties common to the other entities in the entity set EMPLOYEE. Among these properties is the afore- mentioned test predicate."

Typically, entities are realized in a database schema as a table or view: the entity 'Customer' is realized as the 'Customer' table, 'Order' as the 'Order' table etc. There are exceptions to this rule:

• An m:n relation is often realized using an 'intermediate' table.
• When an entity supertype/subtype hierarchy is defined, an entity in a relational model can be physically realized with more than one table/view. This is further discussed in the section Entity inheritance and relational models

So unless inheritance is used to create a hierarchy of entity types, an entity has a 1:1 relation with its physical counterpart in the database model, be it a table or a view. In normal terms, this is also known as 'entity is mapped onto a table or view' and at least mapped onto one table/view.

The concept of an entity is therefore a definition for a relational model element and has been used by database designers, DBA's and software engineers all over the world for many years. It is then logical to adapt that concept of an entity for the Entity element used in the LLBLGen Pro system. LLBLGen Pro uses a table or view definition as the base definition for an entity, also when supertype/subtypes are used in an inheritance scenario: an entity is always at least mapped onto one table or view. Also, tables which are used for the construction of m:n relations (the aforementioned 'intermediate tables') are seen as separate entities. The reason for this is that the intermediate table's definition often is 'objectified'^[2], which means that the table fields (attributes) used to form the m:n relation are seen as separate attributes which can hold a new set of fields (attributes).

An example of this is when an m:n relation has been defined between the entities Department and Employee via the intermediate table DepartmentEmployees. This DepartmentEmployees table has two fields: DepartmentID and EmployeeID. Now we can use this m:n relation to add to the model specific fields, which relate to the m:n relation. For example: startDate. This date holds the date an employee started to work for a department. This field will be added to the DepartmentEmployees table. When that is the case, the relationship between Department and Employee has been objectified into a new entity: DepartmentEmployees. To give better insight in this, LLBLGen Pro always sees every table as an entity so you will see every relation as a possible objectified relation.
Also, it's often the case that m:n relationships are defined between two entities using a third entity with its own set of fields (attributes). An example of this is the m:n relation between Order and Product via OrderRow.

Entity Fields (Attributes)

The attributes, or fields, of an entity are already mentioned above. An example of entity attributes are: CustomerID, CompanyName, or EmployeeID. These attributes together form the entity definition's data fields and also the table's column set. In LLBLGen Pro you'll recognize them as fields mapped on database fields. So when for example a table called 'Customer' is defined as the map target of an Entity definition in LLBLGen Pro (which is a 1:1 relationship; they represent the same semantic element), the fields of that table are available as Entity fields in LLBLGen Pro, and each entity field has a 1:1 relation with its related table or view field.

Entity relations

Entities can have relations with other entities, be it a 1:1, 1:n (one to many), m:1 (many to one) or m:n (many to many) relation. These relations are defined automatically by LLBLGen Pro and can be used to traverse from one entity to another. To make that possible, LLBLGen Pro defines fields mapped on relations. An example for this is the field Orders in a Customer entity which represents an entity set of Order entities related to the Customer.

Summary
Entities are a common concept defined by Dr. Peter Chen in 1976, and are used in both the database world as in the software development world. Entity definitions are physically represented by table or view definitions, an entity itself is represented by a table or view row (record) and an entity set is represented by a set of table or view rows (record set). Entities in LLBLGen Pro are 1:1 representations of tables or views found in the catalog(s)/schema(s) of the project loaded and target 1 table or view only. Table or view fields are represented in LLBLGen Pro entities as entity fields mapped on database fields. These entity fields have a 1:1 relation with their table /view field equivalents.

Relations between entities are automatically defined by LLBLGen Pro and are used to define extra fields in the entities to traverse from one entity to another, using the information of the starting entity. For example, Customer.Orders contains all Order entities related to the customer holding the Orders field, which is mapped on the 1:n relation between Customer and Order. Exactly how entities and their relationships look like in generated code depends on the selected template group and preset. See for more details: Generating code, Task based code generation and Templates and Template groups. The designer works with the definition of an entity and you as a user do too. You shouldn't think in terms of classes and objects yet, an entity definition can result in a lot of classes (entity base class, entity class, entity modification asp.net form class etc.), however they're all based on the same entity definition.

Typed lists

To make life easier when working with entities, LLBLGen Pro defines the concept of a Typed List. A Typed List is a list of entity fields from a set of entities which have 1:1, 1:n or m:1 relations which each other. This way you can create custom, read-only views in LLBLGen Pro on the whole set of entity definitions in your project, which can span more than one entity and do not have to contain all fields of all participating entities. Typed Lists are a powerful, easy way to define read-only lists building on existing entity definitions and their relations. LLBLGen Pro includes a powerful editor for defining typed lists within seconds which are guaranteed to be based on an existing set of relationships between entities participating in the Typed List. All entity fields in a Typed List are fields mapped on database fields. Fields mapped on relations can't be used as Typed List fields. All Typed Lists are generated as Typed DataTable classes.

Summary
A Typed List is a collection of entity fields from a set of entities which have one or more relations with each other of the type: 1:1, 1:n or m:1. A Typed List is a read-only view on the entities in your database.

Typed Views

LLBLGen Pro can create Typed View definitions which map in a 1:1 way on existing views in the catalog(s)/schema(s). Typed Views can come in handy when you've defined special lists using database view technology, and you want to use them in a typed manner in your .NET project but in a read-only way. LLBLGen Pro offers you the ability to define a Typed View equivalent of a database view, which can then be used in your .NET code in a read-only way. A Typed View is, like the Typed List, generated as a Typed DataTable class, so you can use it in your .NET code in a typed way, which increases code stability and development speed. An entity mapped onto a view can also be used to retrieve view data, as well as a Typed View created from the same database view. If you're using the view data in a read-only fashion, it is recommended to use the Typed View object, as it contains less overhead for bulk fetches, and can be somewhat faster in bulk-fetch scenarios.

Views can also be seen as entities (as discussed above). And therefore it can be useful in some scenario's to map an entity onto a view as well. LLBLGen Pro lets you map a TypedView and an entity (or multiple entities) onto an existing database view at the same time. If you want to use a view in joins or filters, it's key you map an entity onto the view so you can define custom relations inside the LLBLGen Pro Designer.

Stored procedure calls

To re-use existing code, defined in stored procedures in the target catalog(s)/schema(s), in your .NET code, LLBLGen Pro can create Stored procedure call definitions. These definitions define a call to a given stored procedure, be it a retrieval procedure (i.e. returns a resultset) or an action procedure (does not define a resultset), which will be generated as an OO-method in the .NET code. This way you can keep your investment in stored procedure code, and at the same time utilize the code in a typed, easy way.