Как вы сопоставляете отношения сущность -> интерфейс, используя Fluent NHibernate?

Question

с учетом следующего определения класса:

public class Order {
  public IProduct Product {get;set;}
}

У меня есть это (свободное) отображение

References(x=>x.Product, "ProductId");

И получите это исключение: ассоциация из таблицы Orders относится к несопоставленному классу, что имеет смысл, поскольку не знает, какую реализацию я передам ему.

Я понимаю, почему я должен определить тип в отображении (IProduct может быть любым), но я не уверен, как это сделать.

Спасибо

Кайл

Answer 1

Я думаю, что вы ищете .References<Product>(x=>x.Product, "ProductId");

Кстати, то же самое верно для .HasMany<>

Это похоже на <... class="Product" /> в xml

Я бы не рекомендовал отображать интерфейс, поскольку он ломает весь смысл его использования - вы сталкиваетесь с проблемами, как только он начинает реализовывать IStorable, а NH не может справиться с множественным наследованием.

Answer 2

Попробуйте сопоставить интерфейс IProduct вместо конкретного класса Product. (Обратите внимание, я не говорю о сопоставлении поля Product класса Order.)

Answer 3

Я работаю над улучшением поддержки прокси-интерфейсов в Fluent. Было несколько полезных патчей, связанных с проблемами 256 и 257, но им действительно нужно было все, что было указано вручную. Я продвинулся на шаг вперед и добавил поддержку установки прокси и изменения типов ссылок с предполагаемого (который будет прокси) на базовый сопоставленный класс, и добавил новое соглашение (ProxyConvention), чтобы настроить все это автоматически - просто создайте его экземпляр с помощью функции для получения интерфейса прокси из сопоставленного класса, и он должен позаботиться обо всем остальном.

Единственной лазейкой на данный момент является то, что она не может подобрать определения, явно указанные в файлах .hbm.xml.

Патч прилагается к выпуск 256

Answer 4

Вы можете отобразить интерфейсную-> реализацию-реализацию как отношение наследования, используя соответствующую модель наследования.

Это означало бы сопоставление IProduct, а затем создание карты подклассов Product в сопоставлении IProduct, например, с использованием таблицы на иерархию.

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