NHibernate file reference

Unfortunately, this relationship is not the easiest thing to model in nHibernate, and there are some inherent problems you will run into when trying to query the data in the reference table, which will require complex workarounds, but once you get them it works very well ...

My approach to this is to set it as two one-two-one mappings with the following relationship in Store mapping and feedback in the StockItem mapping.

<bag name="StockItems" table="StockItemStore" lazy="true">
  <key column="StoreId" />
  <composite-element class="SuperStore.Components.StockItemStore, SuperStore.Components">
    <property name="ParLevel" type="Int32" />
    <many-to-one name="StockItem" column="StockItemId" class="SuperStore.Components.StockItem, SuperStore.Components" fetch="join" cascade="all" />
  </composite-element>
</bag>

      

        
        
        
      

    

the Store class will have the following collection:

public virtual IList< StockItemStore > StockItems {get;set;}

and StockItem will have the opposite again:

public virtual IList< StockItemStore > Stores {get;set;}

A StockItemStore object can contain any object (Store or StockItem) and any additional information found in the binding table. (in this case only ParLevel.

depending on which side you are looking at the StockItemStore object from the Store or StockItem will be null. It can be broken down into two classes, but I find this approach easier to work with. It just requires you as a developer to know which side you are approaching from, but its a good compromise to make the code simpler and more reusable in my opinion.

public class StockItemStore
{
    private StockItem stockItem;
    private Store store;

    public virtual StockItem StockItem
    {
        get
        {
            if (stockItem == null)
            {
                stockItem = new StockItem();
            }

            return stockItem;
        }
        set
        {
            stockItem = value;
        }
    }

    public virtual Store store
    {
        get
        {
            if (store == null)
            {
                store = new Store();
            }

            return store;
        }
        set
        {
            store = value;
        }
    }

    public virtual int ParLevel { get; set; }

}

      

        
        
        
      

    

My approach is not using a single unique ID in the StockItemStore as you defined in your question, but rather what constitutes the composite key in the link table. But it has served me well in the past overall. I'm sure you could train this ID in some way if you really need it.

This approach is great for queries using HQL. if you try to use ICriteria queries it tends to get a little disgusting. There are several solutions that use database views to mimic another table used for queries that worked for me.

If you need to make ICriteria queries, let me know and I can post some code examples.

• Max