In this case the answer is pretty simple. Do not use many-to-many. Use pairing object. Exactly for the reasons you've mentioned: Extend the pairing object with more properties:
Check here 24. Best Practices, a cite:
Don't use exotic association mappings.
Good usecases for a real many-to-many associations are rare. Most of the time you need additional information stored in the "link table". In this case, it is much better to use two one-to-many associations to an intermediate link class. In fact, we think that most associations are one-to-many and many-to-one, you should be careful when using any other association style and ask yourself if it is really neccessary.
Other words, create the one-to-many relations refering the pairing objects from boht ends, and many-to-one from the pairing object.
Also check these:
An example of the Address and Company. First Pairing object
public class AddressCompany
{
// the relation to both sides
public virtual Address Address { get; set; }
public virtual Company Company { get; set; }
// many other settings we need
public virtual string Description { get; set; }
public virtual DateTime CreationDate { get; set; }
...
}
the Address and Company in a nut-shell:
public class Address
{
public virtual IList<AddressCompany> Companies { get; set; }
...
}
public class Company
{
public virtual IList<AddressCompany> Addresses { get; set; }
...
}
The mapping is as expected:
public AddressMap()
{
HasMany(x => x.Companies)
...
}
public CompanyMap()
{
HasMany(x => x.Addresses)
...
}
public AddressCompanyMap()
{
References(x => x.Address)..
References(x => x.Company)..
...
}
So, this is representing the Pairing object
Well, but now we can find some Companies Created after a date:
var subquery = QueryOver.Of<AddressCompany>()
.Where(c => c.CreationDate > new DateTime(2000, 1, 1))
.Select(c => c.Company.ID);
var query = session.QueryOver<Company>()
.WithSubquery
.WhereProperty(c => c.ID)
.In(subquery)
...;
This way we can also filter Company over the Address...
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
