Support for Table-per-Type inheritance

Aug 18, 2011 at 10:15 AM
Edited Aug 18, 2011 at 10:16 AM

When mapping the database model to my entity model I have a situation which can be compared to this, known as TPT or Table-per-Type inheritance.

In short, there is an Employee class that inherits from Contact (a person).

The entity model is setup correctly, but I can't get the TT to generate the class for, in this case, Employee. Is this supported in the CslaExtension?

Aug 18, 2011 at 10:21 AM

No, inheritance support is not implemented yet.


Aug 18, 2011 at 10:23 AM

Hmz, that's too bad. Have you found a strategy to deal with this TPT pattern yet?

Aug 18, 2011 at 10:33 AM

I have a similar situation in one of my projects.

You can generate the Employee class using EditableRoot pattern, and for the Contact use EditableChild, so instead of "is-a" you'll have a "contains" relationship. Mark Contact CSLA properties of the Employee entity as public. Write all common Contact business logic in it's own partial class, so you'll have all the code in one place.

Is this solution ok for you?


Aug 18, 2011 at 3:22 PM

No, this is not the solution, since all of the fields have to be available in the Employee entity so it can be bound to datalists (all on the same level) etc.

I've come up with another solution though. Instead of inheriting, I've copied the fields of Contact to Employee, added a mapping on the added fields on Employee to Contact and removed the Contact entity from the diagram. In this case this works well and the EditableRoot class for Employee can be generated.

It got even better, the Employee class had an association (1..*) to, lets say, Project which in this case had to inherit from Assignment (like Employee had to inherit from Contact). I applied the same pattern to Projects and Assignment and added association from Employee to Project, and adjusted the referential constraint.

This all works quite well in this scenario, although the example used might sound a bit odd.
Perhaps the example of PurchaseOrder (inherited from) -> Order 1.. (which has one or more) ..* OrderLine (inherited by) <- PurchaseOrderLine would clarify the pattern a bit more.

Aug 19, 2011 at 7:18 AM

Nice, you've found a good solution that works. 

Inheritance is generally not recommended when working with CSLA framework but I don't follow that recommendation very strictly. However, I try to avoid inheritance when possible and use "contains" instead.

You can expose "base" object (Contact) as public property of the Employee so it can be bound to the user interface. If you need to expose some fields from Contact on Employee object (in the same level), you can write proxy properties on Employee that just get and set properties of the contained Contact object.