digitaldias wrote:
> Given the following hierarchy:
>
> ORDER
> Each order can have multiple orderlines (ORDERLINE)
> Each orderline can have multiple missions (MISSION)
>
> (The mission table contains details on how to pick a particular item from warehouse, i.e. an orderline can contain instructions to pick 100 of an item, in which case there would possibly be various warehouse locations to pick from, hence the "mission" table, which details this).
>
> The want:
> I would like to use ORDER as a discriminator for each type of orders that exist, i.e: Purchase Order, Sales Order, putaway order, refill order. Each type of order will then have it's details in a specific orderline and mission object. This is easy to do on the Order level, I can just add a TYPE field for the ORDER table and discriminate on that. The reason is that a PurchaseOrderLine focuses on a different set of properties than a pickingOrderLine, but, due to the legacy code being like it is, we need to store all of them in the same table.
>
> So - how do I set up so that a PurchaseOrderLine uses it's order discriminator? and worse, so that the PutAwayMission discriminates against it's .Orderline.Order?
>
> One (very ugly) solution is to add a discriminator field to both ORDERLINE and MISSION tables, but somehow, this disgusts me and feels very much like bad design.
>
> Is there some way to do a property-discriminator in hbm that understands inheritance?
>
> Also, if you have a different suggestion entirely, I'd love to hear it :)
I have encountered a similar situation (using Linq-to-SQL).
I dealt with it by having OrderLine.Order return an instance of Order,
and then hand-shadowing that property in derived classes, so that
PurchaseOrderLine.Order returns a PurchaseOrder -- by performing a cast
on the value returned by the property in the base class.
Adelle.
