2010-12-05 2 views
1

Мы переносим текущее приложение C# для использования nHibernate. Поскольку nHibernate продвигает чисто ориентированный на домен дизайн, мы можем добавить бизнес-объекты в качестве свойств классов или продолжать использовать идентификатор.nHibernate - Объекты или ObjectID в классах

Позвольте мне проиллюстрировать это примером;

Возьмите следующий существующий класс. Адрес (и дети) идентифицируются только по их идентификатору.

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; } 
} 

Когда мы преобразуем класс использовать NHibernate, мы также хотели бы воспользоваться возможностью, чтобы изменить структуру класса в «лицо», чтобы лучше приспособить из потребностей. Надеясь, что NHibernate будет заботиться о все извлечении данных «под капотом»

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; } 
    public virtual List<ChildrenObject> Children { get; set; } 
} 

теперь хранить объект адреса и список объектов Детей против личности. Это лучше для наших бизнес-потребностей, поскольку у нас есть вся информация при доступе к классу, и мы можем отказаться от использования идентификаторов, но вместо этого использовать базовый объект.

В этом случае, то, что nHibernate сохранится для Person.Address? Будет ли он сохраняться только уникальный идентификатор, назначенный для этого объекта в таблице Person? Как насчет ChildrenObject?

ответ

5

Вы должны использовать объекты домена как свойства, такие как во втором примере, который вы даете.

NHibernate сохранится уникальный AddressObject. AddressObject будет иметь отношение «один ко многим» с классом Person, поэтому у вас должно быть List типа Person в классе AddressObject, представляющем Persons, которые там живут. Эти отношения также должны быть определены в файле AddressObject.hbm.xml так:

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

И в Person.hbm.xml так:

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

Кроме того, почему есть класс, специфичный для детей ? Если вы подразумеваете под этим буквальное определение детей, почему бы просто не использовать класс Person для этой цели?

0

Существует два основных типа объектов DDD, представляющих интерес; Entity или ValueObject. Вы, или, точнее, ваш домен, определяет контекст, в котором указывается, какой тип объекта является Entity и который является ValueObject.

Если объект явно является Сущностью, вы должны всегда сделать вашу жизнь проще и сохранить ее с помощью суррогатного идентификатора, хотя идентификатор не имеет смысла в вашей объектной модели. Создайте класс EntityBase класса, который абстрагирует детали Id для вас и наследует Person и другие Entity от него.

Адрес интересен тем, что некоторые домены это объект, а другие - объект ValueObject. Если вы решите, что это объект Value, тогда сопоставьте его как компонент в NHibernate.

NHibernate заботится обо всех несчастных деталях, которые окружают тот факт, что сохраняемые объекты сильно отличаются от объектов в памяти.

HTH,
Berryl

Смежные вопросы