В nHibernate можно ли сопоставить абстрактный базовый класс с коллекцией?

Question

У меня есть базовый класс для элементов контента в CMS, который я создаю. В настоящее время он является абстрактным, потому что я хочу, чтобы производные классы были созданы. Производные классы, такие как BlogPost, Article, Photo и т. Д., Настроены как объединенный подкласс к моему классу ContentBase в nHibernate.

Я пытаюсь настроить сопоставление «многие-ко-многим» между этим классом и классом тегов. Я хочу иметь набор тегов в классе ContentBase и набор элементов ContentBase в классе тегов.

Будет ли nHibernate разрешать мне отображать абстрактный класс ContentBase в виде коллекции класса Tag? Я предполагаю, что нет, поскольку он не сможет создавать экземпляры этого класса при восстановлении объекта тега из db. Я действительно не хочу, чтобы вам приходилось использовать набор элементов контента для каждого типа (например, TaggedBlogPosts, TaggedArticles и т. Д.) В классе Tag.

Вся причина, по которой я делаю это, состоит в том, что логически элемент контента может иметь много тегов, а 1 тег может принадлежать нескольким элементам контента. для того, чтобы nHibernate управлял отношениями для меня в таблице сопоставлений, я считаю, что мне нужно настроить ассоциацию «многие-ко-многим» и добавить тег в коллекцию ContentBase.Tags, а затем элемент контента в коллекцию Tags.TaggedContentItems перед созданием записи таблицы сопоставления в nHibernate.

Вот мои отображения для справки:

<class name="CMS.Core.Model.Tag,CMS.Core" table="bp_Tags"> 
    <id column="TagName" name="TagName" type="String" unsaved-value=""> 
     <generator class="assigned" /> 
    </id> 
    <bag name="_taggedContentList" table="bp_Tags_Mappings" inverse="true" cascade="save-update" lazy="true"> 
     <key column="TagName" /> 
     <many-to-many class="CMS.Core.Model.ContentBase,CMS.Core" column="Target_Id" /> 
    </bag> 
    </class> 

    <class name="CMS.Core.Model.ContentBase,CMS.Core" table="bp_Content"> 
    <id name="Id" column="Id" type="Int32" unsaved-value="0"> 
     <generator class="native"></generator> 
    </id> 
    <property name="SubmittedBy" column="SubmittedBy" type="string" length="256" not-null="true" /> 
    <property name="SubmittedDate" column="SubmittedDate" type="datetime" not-null="true" /> 
    <property name="PublishDate" column="PublishDate" type="datetime" not-null="true" /> 
    <property name="State" column="State" type="CMS.Core.Model.ContentStates,CMS.Core" not-null="true" /> 
    <property name="ContentType" column="ContentType" type="CMS.Core.Model.ContentTypes,CMS.Core" not-null="true" /> 

    <bag name="_tagsList" table="bp_Tags_Mappings" lazy="false" cascade="save-update"> 
     <key column="Target_Id" /> 
     <many-to-many class="CMS.Core.Model.Tag,CMS.Core" column="TagName" lazy="false" /> 
    </bag> 
    ... 
     <joined-subclass name="CMS.Core.Model.BlogPost,CMS.Core" table="bp_Content_BlogPosts" > 
      <key column="Id" /> 
      <property name="Body" type="string" column="Body" /> 
      <property name="Title" type="string" column="Title" /> 
     </joined-subclass> 
    ... 

Answer 1

Я хотел бы также предположить, что Hibernate будет необходимо создать экземпляр базового класса, который имеет смысл, так как есть данные непосредственно связаны с ним в БД.

Похоже, что ваши объекты данных находятся в отдельной сборке из вашего основного приложения. Точка не создавая основы базы с бизнес-точки зрения, поэтому, если вы сделаете конструктор internal для сборки Core, выполняет ли это то, что вы хотите? Если нет, может быть полезно спросить себя: кто я защищаю эту функциональность?

Answer 2

NHibernate должен позволить вам отображать абстрактный класс в виде коллекции, если вы нарисуете сам абстрактный класс (похоже, что у вас есть).

Альтернативой является изменение вашей стратегии на подход, основанный на таблице для каждого класса. Это помещает весь ваш контент в одну таблицу с столбцом дискриминатора для определения типа содержимого. NHibernate знает, как материализовать каждый тип контента на основе дискриминатора. Недостатком является то, что:

1. Каждое уникальное свойство конкретных классов должно иметь тип nullable.
2. Эта таблица может стать громоздкой, если для каждого конкретного класса существует множество свойств.

Таблица на класс-иерархия является предпочтительной стратегией отображения по умолчанию (для NHibernate в действии). Я бы начал с подхода и изменил его на таблицу на подкласс, когда это необходимо.

Все отдельное решение будет содержать сопоставление как есть и полагаться на запрос, чтобы получить контент по тегу, не беспокоясь о тегах, содержащих ссылку на коллекцию контента.