One of the full examples for this is:
Tables:
Person
--
PersonId
<name etc>
ADPerson
--
ObjectSid
PersonId
User
--
ObjectSid
IsActive, etc
The domainmodel is:
UserInfo {
Id (from person table)
ObjectSid (from adperson table)
Name (from person table)
IsActive (from user table)
}
This is part of a list relationship
Order -> OrderLine -> Resonsible : UserInfo
There is a couple of others in this particular system. That are similar to
this. We played around with projections, but for this scenario with a deep
graph (it's actually deeper then the example) it's really a mess to go about
it that way.
--
Patrik
On Thu, Oct 1, 2009 at 4:11 PM, Fabio Maulo <[email protected]> wrote:
> You have forgot the response to my question:
> How look your domain?
>
> 2009/10/1 Patrik Lowendahl <[email protected]>
>
> "The POID should be unique inside a class hierarchy or, even better, inside
>> your domain."
>> This statement is leaky. The domain should not care about POID, at all,
>> POID is a storage concern. Not a business concern. I have a longer argument
>> on my old blog about this: http://www.lowendahl.net/showShout.aspx?id=103
>>
>> "A POID should refer uniquely one, and only one, entity instance."
>> Yes, but there is nothing that says that there can't be several entities
>> that store their POID in the same table.
>>
>> See my response to Anne for a bit more info on the last statement.
>>
>> --
>> Patrik Löwendahl
>> http://blog.lowendahl.net
>> http://twitter.com/lowendahl
>>
>>
>> On Wed, Sep 30, 2009 at 5:35 PM, Fabio Maulo <[email protected]>wrote:
>>
>>> ORM (object relational mapping):The POID should be unique inside a class
>>> hierarchy or, even better, inside your domain.
>>> A POID should refer uniquely one, and only one, entity instance.
>>>
>>> How look your domain?
>>>
>>> 2009/9/23 Patrik Lowendahl <[email protected]>
>>>
>>> Is there any plans on supporting joins mapping on any other column then
>>>> the class PK?
>>>>
>>>> I see a lot of legacy where they have used arbitrary columns as the FK,
>>>> like this example:
>>>>
>>>> [Person]
>>>> PersonId
>>>>
>>>> [AdPerson]
>>>> PersonId
>>>> ObjectSID
>>>>
>>>> [User]
>>>> ObjectSID
>>>>
>>>> Doing a projection over this (UserInfo) becomes bothersome and the
>>>> simplest solution would be something like:
>>>>
>>>> <class name="AdPerson">
>>>> ...
>>>> <join table="Person">
>>>> <key column="PersonId" />
>>>> ...
>>>> </join>
>>>> <join table User>
>>>> <key column="ObjectSID" foreign-key="ObjectSID" />
>>>> ---
>>>>
>>>> For the record, I don't agree with the database model, but this is what
>>>> I have to work with and a construct like the above would make it a lot more
>>>> easy to manage.
>>>>
>>>> --
>>>> Patrik
>>>>
>>>>
>>>
>>>
>>> --
>>> Fabio Maulo
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Fabio Maulo
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
