I got the following problem;

I have 3 tables:

TariffGroups, RateCards and RateCardPool.

Basically a TariffGroup is a set of RateCards. It can have 1 or more RateCard.
RateCards can belong to 1 or more TariffGroup, thats why i created a third table called RateCardPool.

RateCardPool has 2 fields, TariffGroupID and RateCardID, this are primary keys of TariffGroups and RateCards respectivelly, so as you figure out it makes a composite key.

Thanks to RateCardPool i can associate more tahn 1 RateCard to More than 1 TariffGroup.

Now, I have 3 clases:

TariffGroup, RateCard, and RateCardPool

I need some help making the mappings to make this work with NHibernate.

Can you please try to help me out!

Thanks

I had a similar problem. You end up not needing an object for the intersecting table. This table is used only in your mapping files to provide the many-to-many-relationship between the 2 objects.

Here is a sample of my mapping files...

Project



The following mapping file is for the ProjectClass object. This mapping file uses the inverse keyword to provide a backward reference to the Project object...

ProjectClass


Hope this helps.
Greg

Thanks Greg!!!!

I wanted to follow-up and see if this in fact helped you out. Let me know..

Thanks

Greg

The most flexible solution probably is mapping all these 3 classes and the two many-to-one association between them.

I don't think I agree. Consider the following classes:



This is a many-to-many as a Customer may have many accounts, and an account can be a joint-account between 2 or more Customers.

The table structure though needs the intersecting table for the associations, your domain model does not in this case.

This is the goal of an ORM tool, is to allow developers of the Domain model to design their domain objects independant of the database implementation.

What your suggesting is to map your domain objects to reflect the table structure. That is a more TableModule design pattern instead of the domain model pattern.

I don't think I was suggesting a TableModule design. Actually it is also recommended by Hibernate in Action (check out the banner).
In my experience, adding an intermediate class between Account and Customer will give you the following strength:
first, you will have a class that can help manage this complex association.
secondly, in this class, you can store more information such as the time when a customer is added as an extra owner to the joint-account or the priority of the owners over the account.
This design might not be suitable for you domain but these two capabilities just give you more flexibility as I was suggesting.