Mapping a Decorator Pattern in NHibernate

[Diego Jancic]

Hi!
Hope you can help my with you issue...
I made a domain model (http://cedev.com.ar/model.jpg) and what I'm
trying to is the NHibernate mappings to persist it. (It's uses the
Decorator Pattern, of course..)
It's importante to know that a Person might be a Student and a Tutor
at the same time (that's why it's not a simple inheritance)
I created a table for ConcretePerson, another one for SystemUser (only
with the Id), other for Tutor and other for Student (only with the Id
too). The problem is that a partner is criticizing me (and with good
reasons) that the ConcretePerson table should have fields like
"IsStudent", "IsTutor" and so on, to improve the performance and don't
let NH make a lot of joins to find a student...

What can I do??

Thanks in Advance!,
Diego

 

[Guest]

hi,
hope this will help yo
http://www.codeproject.com/aspnet/N...sp?df=100&forumid=278860&exp=0&select=2055053

Regards,
Husam al-aáraj
www.aaraj.net

 

[Diego Jancic]

Hi,
I already read that article, which part do you consider important ?

Thanks,
Diego

 

[Frans Bouma [C# MVP]]

Hi!
Hope you can help my with you issue...
I made a domain model (http://cedev.com.ar/model.jpg) and what I'm
trying to is the NHibernate mappings to persist it. (It's uses the
Decorator Pattern, of course..)
It's importante to know that a Person might be a Student and a Tutor
at the same time (that's why it's not a simple inheritance)
I created a table for ConcretePerson, another one for SystemUser (only
with the Id), other for Tutor and other for Student (only with the Id
too). The problem is that a partner is criticizing me (and with good
reasons) that the ConcretePerson table should have fields like
"IsStudent", "IsTutor" and so on, to improve the performance and don't
let NH make a lot of joins to find a student...

If you want to use inheritance, you can model it in two ways: single
table inheritance, which requires a discriminator column (e.g.
PersonType) and multi-table inheritance, which has per type its own
table (there are variants on this, but it all comes down to that).

Single table inheritance is faster as you don't have to use joins with
the tables of the sub/super types. It's also less usable as you can't
create mandatory relations between subtypes and another entity mapped
on another table: the fk fields have to be nullable in that regard.

While inheritance is a must-have feature for o/r mappers, it is often
mis-used. The main issue here is that people tend to forget that a type
is fixed: once you have an instance of an entity of type T saved into
the DB, that instance is fixed. You can't change an object in-memory
into a different type it doesn't have as well.

A typical example of misuse of inheritance is often seen in structures
where a 'role' would have been better. Your situation is such a case:
Say you create a new student instance. After a while that student
becomes a tutor. That student doesn't change type. So you have to
create a new entity instance, namely of type tutor, and save that with
the data of the student. Then, after a month, the student gets bored
and isn't a tutor anymore. Same thing happens.

Better is to use a role system in THIS situation: Student has the role
of tutor or not. You could also argue (if person is also used to store
people who were students but now have graduated) that person is such a
candidate, thus that person should have a role 'student' and thus could
have multiple roles.

The typical indication that you need such a mechanism is when you see
that the types can change on a live instance.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------