Hi Frank - I think its perfectly legal to use a related entity in the
business key. Of course there are limits when you consider the
implications of loading related entities.
I usually do one of the following:
Assuming that the business key is Contract.Number and WorkItem.Number:
1) You could create a readonly ContractNumber property on WorkItem and
have it filled using a computed column:
<property name="ContractNumber" insert="false" update="false"
formula="(SELECT c.Number FROM Contract c WHERE
c.ContractId = Id)" />
2) You could just reference Contract from the equals method of
WorkItem using Contract.Number. Of course that would entail that you
always load the Contract, but it does look like that it is the
aggregated root of your domain so it would be loaded anyway.
Regards
Thomas
On 23 Aug., 11:23, Frank <[email protected]> wrote:
> Okay here is the straightened version, sorry for the confusion.
> There are two classes Contract and WorkItem. I'm looking for a
> business key for WorkItem here.
>
> public class Contract
> {
> public virtual int Id {get; set;}
> public virtual int Number {get; set;}
> public virtual IList<WorkItem> WorkItems {get; set;}
>
> }
>
> public class WorkItem
> {
> public virtual int Id {get; set;}
> public virtual int Number {get; set;}
> public virtual Contract {get; set;}
>
> }
>
> A candidate for the business key for WorkItem would be the Contract
> and the WorkItem.Number. Each WorkItem is guaranteed to have a
> contract so there would be no nulls in there. Is it a bad idea to use
> a related Entity (Contract in this case) for the business key?
>
> Greets
> Frank
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
