Understanding Business Key Equality

jyoung · **Joined:** Sat Jun 09, 2007 8:22 pm **Posts:** 9

I think I have the basic idea down, but my question is; what do you do if you don't have a business key?

For example, an Order has many OrderItems.
The Order key could be defined as OrderNumber (NOT ID) and DateCreated.
But say that OrderItem only contains an ID, Order and Product. (I know you would have price etc., in a full system)

What do I define as a business key here for OrderItem? Order.OrderId and Product.ProductId? If I do that then I am lazy loading the Order and Product when I may not have to and I am doing it in what should be a very fast simple operation, but incur two database hits.

I thought to expose an OrderId and ProductId property on the OrderItem class, but that kinda seems to defeat the purpose of a Domain Object.

Any advice is appreciated.

Thanks,
Joe

jlockwood · **Posted:** Sat Sep 15, 2007 4:13 am

All my domain entities have an ID. Evan's description of entities in Domain Driven Design is really what it's all about. The ID is the unique reference for an entity apart from your domain model. In fact, I often have a generic abstract base called something like DomainEntity<IdType> that covers all my persitable objects.

The vast majority of my IDs are similar to surrogate keys. Some legacy tables (esp. in oracle) have a code (varchar) or some other field with business value as a primary key and I treat those as IDs in my mapping files (although they grate against the purist in me). In the objects themselves I'll have the Code and ID properties share the same field value, with neither having public setters (because the entity would no longer be itself if it's identity was changed).

Billy McCafferty has a good article that covers this and a number of other topics.
http://www.codeproject.com/aspnet/NHibe ... ctices.asp

To address your question more specifically, All your classes could have a property, ID, that has no business value. This is there to identify an entity and support your data repository only. An order has many orderitems and an orderitem has one product, right?

So...

Code:

public interface IDomainEntity<IdType>
{
     IdType ID {get;set;}
}

//let's say order's PK is an int
public interface IOrder : IDomainEntity<int>
{
     List<IOrderItem> OrderItems {get;set;}
}

//let's say OrderItem's PK is a string
public interface IOrderItem : IDomainEntity<string>
{
     IProduct Product {get;set;}
}

public interface IProduct : IDomainEntity<int>
{
...
}

...forgive me, I LOVE interfaces!

On mapping, you could set any lazy loading off if you wanted. Order could have a set of OrderItems.

On DB end,
Order could have PK OrderID
Product could have PK ProductID
OrderItem could have PK OrderItemID
and FK to Order.OrderID
and FK to Product.ProductID
*This would only be in the DB and would be resolved in class map file, the classes don't need to be set up like the tables.

Make sense?

BTW, you can use interfaces instead of declaring all your props as virtual
;)