Я работаю над переносом приложения в NHibernate и использую Fluent NHibernate. Я сталкиваюсь с проблемой сопоставления коллекции типов значений с совокупным корнем.
У меня есть тип значения PhoneNumber
, который имеет несколько свойств & mdash; Number
, NumberType
и Description
. В моем домене есть несколько объектов, у которых есть коллекции телефонных номеров.
В базе данных (SQL 2008) эти значения хранятся в разных таблицах. Так что у меня могут быть Customers
и CustomerPhoneNumbers
, а также Vendors
и VendorPhoneNumbers
. Таблицы телефонных номеров идентичны, за исключением внешнего ключа, который связывает их с их родителем.
Проблема в том, что я хотел бы использовать простой тип значения PhoneNumber
без необходимости создавать типы CustomerPhoneNumber
и VendorPhoneNumber
, свойства которых связывают их с родительским типом, и я не знаю, как это сделать. добиться этого в NHibernate. Возможно ли это или мне нужно изменить мои доменные объекты, чтобы они более точно соответствовали базовой схеме базы данных?
ОБНОВЛЕНИЕ: немного больше информации
Похоже, у меня проблемы даже с получением основной карты для поиска. Вот упрощенный пример того, что у меня есть:
public class CustomerMap : ClassMap<Customer>
{
public CustomerMap()
{
Table("Customers");
Id(x => x.Id);
Map(x => x.Name);
Component(x => x.Address);
HasMany(x => x.PhoneNumbers)
.KeyColumn("CustomerId")
.Cascade.All()
.Table("CustomerPhoneNumbers");
}
}
public class PhoneNumberMap : ClassMap<PhoneNumber>
{
public PhoneNumberMap()
{
Id(x => x.Id);
Map(x => x.Number, "PhoneNumber");
Map(x => x.PhoneNumberType);
Map(x => x.Description);
}
}
Похоже, что SQL генерируется неправильно. Когда я пытаюсь просмотреть список телефонных номеров клиента, я получаю ошибку ADO, которая показывает, что NHibernate ищет таблицу с именем PhoneNumber
.
Кажется, что он не берет часть Table("CustomerPhoneNumbers")
и по умолчанию использует таблицу, названную так же, как объект. Однако я не могу указать таблицу в PhoneNumberMap, потому что она будет отличаться в зависимости от того, какой агрегированный корень мы выбираем.