Implementing inheritance in reverse mapped database model

DESCRIPTION

Inheritance is one of the many features of OpenAccess which comes with the forward mapping approach. To implement inheritance in the reverse mapping scenario however, requires some skills that we will demonstrate in this article. It is a common approach to go the “database schema first” design, when starting new application development.

SOLUTION

For the purpose of this example we created a simple database schema that will be used in an inheritance model.



There is a common scenario where we create Person and Employee tables and we intend to make the Employee to inherit the Person in our application codebase.
The first important thing to notice is that the identification field of the Employee must be the same as the one of the Person. That way a one-to-one relation is in effect that resembles inheritance between classes in the application’s codebase. The next step is to produce our persistent classes using the OpenAccess reverse-mapping wizard. First thing to do is to remove the reference to the Person class from the Employee class (which is automatically created by the wizard). We can do that by expanding the node of our derived class in the advanced tree view, and selecting the reference to the Person by clicking the Remove button on the right.



After the removal of the reference click “Generate & Save Config”.
Since OpenAccess has already created our class model there are few steps we should take to make our Inheritance model work as desired:

1. Manual changes that need to be made in the Employee.Telerik.OpenAccess.cs file:

step 1: We make the Employee class explicitly inherit the Person class.

step 2:We delete the field that is used for identity of the Employee class ( the “employeeID” field), because since we have inherited the Person class we already have its identification field available.

step 3:"IdentityField" parameter from the Telerik.OpenAccess.Persistent() attribute of the Employee class should be removed as well because the field no longer exists in this class.



2. Changes that need to be made in the Employee.cs file:

step 1:Only the property for the id field needs to be removed

3. Changes that need to be made in the App.config file:

step 1: The value for the node of type ”extension” with key=”db-do-not-create-table” should be set to false. This is done so OpenAccess can edit our existing tables for the purpose of inheritance. This is usually the first child node of the “class” node in the “mappings” section and the step should be repeated for every class whose mapping info is described in the app.confg. In our case we perform this action for the Employee and Person.

step 2:The “field” node for the employeeID field which we deleted from the .cs files should also be removed from the app.config.



Now that we have set our persistent model as required, we need to specify the strategy of inheritance used by OpenAccess. We start the Forward Mapping wizard, select the derived class and choose the vertical option in the “strategy” combo box (which is found in the “inheritance” group box). Vertical inheritance strategy means that separate tables will be used for the different classes in the hierarchy and that is what we initially wanted in the design of our schema. More on how inheritance can be handled with OpenAccess is available in this article.



The last action that needs to be taken is to change the property “UpdateDatabse” of the project where our persistent classes are stored and rebuild the application. In Solution Explorer, select your project and press F4 to open the Properties pane. Set the UpdateDatabase property to True. Build your project.

This is how the database schema will look after OpenAccess ORM slightly modify it for our needs:


The only difference in the Employee table is that the identity field of it is also “PersonID” as it is in the table for the class it derives from. A “voa_class” column is also created in the Person table and that column is used by OpenAccess so it can track the class type of each record in it. That is of course, because a record in the Person table may be of type Person or Employee or any other class that eventually derive from it.

The following code is a small example that demonstrates what we just did with inheritance: