As we’ve previously discussed, LightSpeed supports two kinds of inheritance, which we refer to as single table inheritance and concrete table inheritance. In this post, I want to talk about how to set up these kinds of inheritance in the LightSpeed model and in the database.
Concrete table inheritance (see Martin Fowler’s description)
Concrete table inheritance refers to having one database table for each concrete class in your model. For example, suppose you have an abstract base class Employee with a Name property, and derived classes PermanentEmployee with a Salary property and Contractor with an HourlyRate property. Then you’d have two database tables, PermanentEmployees with Name and Salary columns (in addition to the mandatory Id column of course), and Contractors with Name and HourlyRate columns.
CTI is appropriate when you don’t need to load objects polymorphically — you’ll always query for PermanentEmployees or Contractors, never for Employees — or if the base class is just adding helper methods rather than state.
To set up concrete table inheritance in the designer (model first):
To set up concrete table inheritance in the designer (database first):
If you’re using a nightly build of LightSpeed, we recommend marking the base class as abstract via its Inheritance property. This prevents you from accidentally instantiating an object with no backing table, and is currently required if you want to use database synchronisation with CTI hierarchies.
The resulting diagram will look like this:
Single table inheritance (see Martin Fowler’s description)
Single table inheritance refers to having one database table for all the types in the entire inheritance hierarchy, with a “discriminator” to indicate which type any given row is. If derived types declare properties, the columns for those properties have to go in the common table. For example, suppose that you have a base class Employee with Name and EmployeeType properties, and derived classes PermanentEmployee with a Salary property and Contractor with an HourlyRate property. Then you’d have one database table, Employees, with Name, EmployeeType, Salary and HourlyRate columns. LightSpeed would ignore the HourlyRate column for PermanentEmployee entities and would ignore the Salary column for Contractor entities.
STI is appropriate when you want to load objects polymorphically. This is handy even when you don’t have additional state associated with the derived classes — if you find yourself writing switch or Select Case statements on a property, that might be a hint to make that property a discriminator and create a virtual method with overrides in each derived class.
To set up single table inheritance in the designer (model first):
To set up single table inheritance in the designer (database first):
The resulting diagram will look like this:
Click here to download the Express Edition of LightSpeed
Single table and concrete inheritance with LightSpeed ORM…
Thank you for submitting this cool story – Trackback from DotNetShoutout…
[...] single table inheritance, properties that are meaningful only on a derived class appear on the base class because the [...]
Leave a Reply