Как избежать идентификации объекта с помощью NHibernate

Question

Я пытаюсь изучить NHibernate, и я наткнулся на проблему комбинированного проектирования баз данных / «обучения тому, как работает NHibernate».

В моем случае я пытаюсь разработать простую таблицу сстроки и столбцы, где каждая строка имеет «описание», а затем список «значений столбцов» (своего рода), который содержит данные, а также информацию сортировки.В коде это выглядело бы примерно так:

public class Row
{
    public virtual int ID { get; set; }
    public virtual string Description { get; set; }
    public virtual ICollection<Column> Columns { get; set; }
}

public class Column
{
    public virtual Row ParentRow { get; set; }
    public virtual int SortID { get; set; }
    public virtual string Value { get; set; }
}

Моя конечная цель состояла в том, чтобы создать схему базы данных, которая была бы ...

• Две таблицы "Row"и «Столбец»
• В строке есть два столбца: ID и Описание.
• В столбце есть три столбца: ParentID, SortID и Value.

Поскольку столбец можетпринадлежат только одной строке, и в идеале каждый столбец должен иметь уникальный идентификатор сортировки в каждом ParentID, первичным ключом таблицы Column могут быть ParentID и SortID вместо четвертого столбца «ID».

ОднакоNHibernate борется со мной на каждом шагу.Он настаивает на том, что у меня должен быть идентификатор для поля столбца.Я полагаю, у меня есть несколько вопросов:

1. Является ли моя "цель схемы" самой по себе серьезной ошибкой?Неужели для каждой колонки лучше иметь собственный идентификатор?Если да, то почему?
2. Независимо от того, является ли схема, которую я ищу, хорошим дизайном, можно ли это сделать в NHibernate?До сих пор я успешно сопоставил класс «Row», но я не могу сопоставить класс «Column» без жалоб NHibernate на необходимость предоставить ему идентификатор.(для чего это стоит, я использую Fluent NHibernate).Как мне обойти это?

Answer 1

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

Чтобы узнать, как отобразить составные идентификаторы первичного ключа, прочитайте раздел композитный-идентификатор в документации по Nhibernate.

Все это, исходя из опыта, я обнаружил, чтоНесоставные идентификаторы первичного ключа - ваш лучший друг ORM.Это значительно облегчает жизнь во многих случаях, например, при генерации идентификатора приложения, пакетировании и т. Д. В таблицах, похожих на вашу таблицу «столбцов», я предпочитаю иметь синтетический идентификатор первичного ключа ( Суррогатный ключ ).Но опять же, это зависит от ваших потребностей, YMMV.

Answer 2

в моделировании ООП существует два разных типа. Типы ссылок и типы значений. Разница между ними заключается в том, что для справочных типов вы заботитесь о , которыми они являются , которые идентифицируются некоторым идентификатором, а для типов значений вы заботитесь о чем они являются.

Простой пример в мире .net:

DateTime d1 = новый DateTime (2012,12,21);

DateTime d2 = новый DateTime (2012,12,21);

Теперь нас действительно волнует, указывают ли эти два времени даты на разные экземпляры памяти (и они указывают так)

Нет, но мы просто заботимся о том, кто они, следовательно, они равны.

Сначала вы должны решить, должна ли ваша сущность быть типом значения или ссылочным типом. Если это ссылочный тип, вы должны следовать приведенному выше определению и дать nhibernate некоторый идентификатор. Если вы не можете дать идентификатор, тогда это должен быть тип значения. В этом случае вам не важно, какой это, а какой. Для такого случая nhibernate предлагает вам компонентов . С компонентами, которые могут находиться в одной и той же таблице или отдельно, нет необходимости определять ID. Однако nhibernate не будет относиться к ним как к сущности.