Отображение «многие ко многим» с дополнительными столбцами в таблице соединений - PullRequest
2 голосов
/ 23 января 2009

Вот домен, который я хочу иметь:

public class Person
{
    public int Id { get; set; }
    public IList<AcquiredCertificate> AcquiredCertificates { get; set; }
}

public class AcquiredCertificate
{
    public Person Acquirer { get; set; }
    public Certificate Certificate { get; set; }
    public DateTime DateAcquired;
}

public class Certificate
{
    public int Id { get; set; }     
}

И вот схема, которая у меня есть:

CREATE TABLE People (
    PersonId INT PRIMARY KEY
);

CREATE TABLE Certificates (
    CertificateId INT PRIMARY KEY
);

CREATE TABLE CertificatesAcquiredByPeople (
    PersonId INT,
    CertificatedId INT,
    DateAcquired DATETIME
);

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

Как бы я отобразил это с помощью NHibernate? Я полагаю, что тег компонента в файле hbm должен делать то, что я хочу, но я не могу понять это.

Мой домен не в порядке, потому что у меня есть свойство DateAcquired в моем классе Certificate? Дата действительно касается только лица, имеющего сертификат.

[Изменить]

Теперь я изменил модель предметной области, чтобы отразить, что необходим новый объект. Теперь для сопоставления мне нужно 3 (для каждой сущности) сопоставления или я могу сделать это с 2 (для персоны и сертификата)?

Ответы [ 5 ]

5 голосов
/ 24 января 2009

По своему замыслу NHibernate поддерживает неявное отображение «многие ко многим» только в том случае, если абсолютно НИЧЕГО, кроме пары FK, представленных в промежуточной (средней) таблице, которая содержит отношение «многие ко многим».

Некоторое время назад Билли МакКафферти писал об этой «проблеме» (на самом деле это не проблема с момента ее разработки) ...

http://devlicio.us/blogs/billy_mccafferty/archive/2008/07/11/when-to-use-many-to-one-s-vs-many-to-many-with-nhibernate.aspx

1 голос
/ 23 января 2009

Я думаю, вам нужно 3, если вы когда-либо собираетесь получить значение DateTime.

0 голосов
/ 24 января 2009

Re: ваш обновленный Q, вам понадобятся три отображения, по одному для каждой из трех сущностей, которые теперь участвуют в паре отношений один-ко-многим.

0 голосов
/ 23 января 2009

Я бы переименовал CertificatesAciredByPeople что-то
как CertificatesAcquiredEvent (подразумевается, что существует более одного ключа и дата / время)

Я согласен, что это должен быть отдельный объект, если говорить о NHibernate.

0 голосов
/ 23 января 2009

Ваша реализация в точности верна. Ваша объединяющая таблица включает в себя два ключевых поля (создание составного первичного ключа для таблицы), и поле datetime является излишним. На самом деле это дополнительный атрибут в соединительной таблице, для которого вам нужен объект.

На диаграмме классов UML он также будет отображаться как атрибут в соединении.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...