nHibernate - Objects or ObjectID's in classes

We are migrating a current C# application to use nHibernate. As nHibernate promotes a purely domain driven design can we add business objects as properties of classes or should be continue to use an ID.

Let me illustrate this with an example;

Take the following existing class. The Address (and children) are identified by their ID' only.

public class Person
{
    public int PersonID { get; set; }
    public string FirstName { get; set; }
    public string FirstName { get; set; }
    public int AddressID { get; set; }
    public List<int> ChildrenIDs { get; set; }
}

When we convert the class to use nHibernate we would also like to take the opportunity to change the structure of the 'Person' class to better accommodate out needs. Hoping that nHibernate will take care of all the data retrieval 'under the hood'

public class Person
{
    public virtual int PersonID { get; private set; }
    public virtual string FirstName { get; set; }
    public virtual string FirstName { get; set; }
    public virtual AddressObject Address { get; set; }
    开发者_JAVA技巧public virtual List<ChildrenObject> Children { get; set; }
}

We now store an Address object and a List of Children objects against the Person. This is better for our business needs as we have all the information when accessing the class and we can move away from using ID's but instead using the underlying object.

In this scenario, what would nHibernate persist for the Person.Address? Will it persist only the unique ID that is nominated for that object in the Person table? What about ChildrenObject?

---

You should use domain objects as properties such as in the second example you give.

NHibernate will persist a unique AddressObject. The AddressObject will have a one-to-many relationship with the Person class presumably, so you should have a List of type Person in the AddressObject class representing the Persons who live there. This relationship should also be defined in your AddressObject.hbm.xml file like this:

<set name="persons" cascade="all" inverse="true" lazy="true">
    <key column="address_id"/>
    <one-to-many class="Person"/>
</set>

And in Person.hbm.xml like this:

<many-to-one name="address"
    class="AddressObject"
    column="address_id"/>

Also, why have a class specific for children? If what you mean by that is the literal definition of children, why not just use the Person class for this purpose?

---

There are two basic DDD types of objects of interest; an Entity or a ValueObject. You, or more accurately, your domain, determines the context that says which type of object is an Entity and which is a ValueObject.

If an object is clearly an Entity, you should always make your life easier and persist it with a surrogate id of some sort, even though the id has no meaning within your object model. Make an EntityBase sort of class that abstracts the details of an Id for you and inherit Person and other Entities from it.

An Address is interesting in that some domains it is an Entity and others it is a ValueObject. If you decide it is a Value Object, then map it as a component in NHibernate.

NHibernate takes care of all the unfortunate details that surround the fact that persisted objects are quite different than in-memory objects.

HTH,
Berryl