Understanding the Default Mapping

By default, LightSpeed maps the domain model to the database as follows.

Entity Classes Map to Tables

Each entity class maps to a database table.  The name of the table is the name of the entity class.  For example, an Employee entity class is mapped to an Employee table.

If the LightSpeedContext.PluralizeTableNames configuration option is set to true, then the name of each table is the plural of the entity class name.  For example, a Person entity class is mapped to a People table. (Pluralization uses English language rules, and allows for most common irregular plural forms.)

The ‘table per class’ mapping changes if you use inheritance in your domain model.  See Domain Modelling Techniques for more information.

Entity Id Maps to the Id Column

The Entity<TId> base class defines an Id property which represents an identifying key for the entity.  The Id property maps to the Id column.

Consequently, in the default mapping, every table must have an Id column (which should be the primary key).

The ‘Id column’ mapping changes if you use composite keys.  You should only do this if you are working with a legacy database that you cannot change to support a scalar surrogate key.  See Working with Legacy Databases for more information.

Fields Map to Columns

Each field in an entity maps to a database column.  The name of the column is the name of the field.  For example, a FirstName field is mapped to a FirstName column.

The ‘column per field’ mapping changes if you use value objects to represent structures or semantics that turn up repeatedly in the business model.  See Domain Modelling Techniques for more information.

It’s important to be aware that LightSpeed maps fields, not properties, to columns.  This allows you to decouple your API from your persistence model if required.  For example, you might choose not to present some attributes directly as properties, instead allowing them to be accessed and modified only through domain methods.  If you are using the designer, of course, it cannot create domain methods for you, but you can suppress the wrapper properties by setting the Generation option to FieldOnly.

Associations Map to Foreign Key Columns

Each one-to-many or one-to-one association in an entity is backed by a field which maps the foreign key for that association.  (Many-to-many associations are represented by a pair of one-to-many associations, and are therefore backed by a pair of foreign keys fields.)  The foreign key maps to a column just as a normal field does.  The foreign key field name is that of the backreference (or EntityHolder field) , with an “Id” suffix.  For example, a Manager association is backed by a ManagerId field which is mapped to a ManagerId column.

Id Values Come From KeyTable

When LightSpeed needs to assign an Id to an entity, by default it obtains the next value from a table named KeyTable.  (Actually, for efficiency, LightSpeed gets values in blocks, rather than one at a time.)  In the default mapping, therefore, each database must contain a table named KeyTable with the appropriate schema.  See Identity Generation below for more information.

Default Mapping Example

The picture below shows a simple LightSpeed and how it is mapped in the database.  Note that:

·         The database table names are the same as the entity names.

·         Each database table has a primary key named Id.  This isn’t shown on the LightSpeed designer, but it is present in each LightSpeed entity.

·         The database column names are the same as the entity property names.

·         The database contains a foreign key column for each association, and the foreign key name is the name of the association followed by “Id.”