Hi all,

I have a query regarding inheritance implementation.

I have multiple tables ... say Patient, Doctor and Nurse. They may share common fields(such as firstname, lastname etc) and methods. All these fields are stored in the individual entity tables.

In my domain model, these entities(Patient, Doctor and Nurse) derive from a class Person. Person does not have a corresponding table in the database.

How do I implement this kind of inheritance using LLBLGen?

Thanks for your replies.

Regards, Indrajeet

LLBLGen Pro mapes it's objects from the Relational model (hence the name O/R mapper)

So you'd better create a database Table (Person) to hold those shared fields. Then each other table should have its own PK as the FK to the Person table (i.e. same PKs)

Then use the LLBLGen Pro Designer to define those inheritance relations.

Walaa wrote:

LLBLGen Pro mapes it's objects from the Relational model (hence the name O/R mapper)

So you'd better create a database Table (Person) to hold those shared fields. Then each other table should have its own PK as the FK to the Person table (i.e. same PKs)

Then use the LLBLGen Pro Designer to define those inheritance relations.

So is it not possible to have an abstract base class without a corresponding table (in a target per entity hierarchy)?

Correct. The abstract base class is already defined: EntityBase (or EntityBase2).

What CAN be done is a central base class between the entity class and EntityBase (or EntityBase2). Please check the 3rd party section for v2.0 for downloading the templates for that.

Otis wrote:

Correct. The abstract base class is already defined: EntityBase (or EntityBase2).

What CAN be done is a central base class between the entity class and EntityBase (or EntityBase2). Please check the 3rd party section for v2.0 for downloading the templates for that.

Thanks - I'll have a look. I presume that this intermediary class is not a first-class LLBLGen entity - i.e. it has no factory and cannot participate in relations etc.?

Why do you want relations for a base entity that doesn't have a table?

Relations are mainly used to fetch data from related entities.

Walaa wrote:

Why do you want relations for a base entity that doesn't have a table?

Relations are mainly used to fetch data from related entities.

The concrete subclasses would inherit the relations and be able to use them.

Though, what's the start entity of the relation (e.g.: Start entity 1:n end entity ) ? If you say: the abstract base class without mapping, that's not true, because it can't be used as a relation for the entity.

The elements llblgen pro offers are for using the entities in the entity model, which are represented by containers in code and table/view definitions in the db (with inheritance eventually, see Object Role Modelling, http://www.orm.net). It thus doesn't make sense to define relations between entities in code, as the entities in code are containers for the entity data (== the entity).

[urldescription="Please read my essay about this here"] http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx[/url]

Otis wrote:

Though, what's the start entity of the relation (e.g.: Start entity 1:n end entity ) ? If you say: the abstract base class without mapping, that's not true, because it can't be used as a relation for the entity.

The elements llblgen pro offers are for using the entities in the entity model, which are represented by containers in code and table/view definitions in the db (with inheritance eventually, see Object Role Modelling, http://www.orm.net). It thus doesn't make sense to define relations between entities in code, as the entities in code are containers for the entity data (== the entity).

[urldescription="Please read my essay about this here"] http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx[/url]

My motivation to have an abstract base class (without table) with concrete subclasses is to avoid the overhead of joins and multi-table updates in scenarios where the bulk of the operations are on the distinct concrete subclasses rather than the base class. E.g. customers and suppliers share many functional characteristics e.g. contacts, addresses etc. but are semantically very different and therefore polymorphic operations on them may be fairly rare. In such cases, it would be ideal to have a mechanism that allows the common functionality to be in one place (abstract base class) but the data management overhead to be optimised for non-polymorphic operations.

I read your essay and have to confess to being drawn toward the MDA camp that would like to model in uml and have the code and db generated from there. However, having used LLGLGen Pro for a (little) while I find the pragmatism and closeness to the database compelling and reassuring and the templating looks to be an excellent feature. As you say "there is no clear "this is how you do it" answer to that question". Do you think there may come a time when the LLBLGen design process can start with a class diagram instead of a database?

jaschag wrote:

Do you think there may come a time when the LLBLGen design process can start with a class diagram instead of a database?

Why bother, when "The Database Model is the Domain Model"?

http://weblogs.asp.net/fbouma/archive/2006/08/23/Essay_3A00_-The-Database-Model-is-the-Domain-Model.aspx

Seriously, I think Frans is right on with his approach, which is why I've loved LLBLGen since I found it. Class diagrams should model behavior, not data. They CAN model data because classes DO contain data (otherwise they wouldn't be very useful), but classes exist to perform work. The data exists in and of itself, which is why I believe it is the place to start every application.