NHibernate: Один базовый класс, несколько отображений

Это могло бы помочь;

Использование NHibernate с несколькими базами данных

От статьи;

Введение

... описанное использование NHibernate с ASP.NET; это предложило инструкции для общения с единой базой данных. Но иногда необходимо общаться с несколькими базами данных одновременно. Чтобы NHibernate сделали это, фабрика сессии должна существовать для каждой базы данных, которой Вы будете общаться с. Но, как это часто бывает с несколькими базами данных, некоторые базы данных редко используются. Таким образом, это может быть хорошая идея не создать фабрики сессии, пока они не на самом деле необходимы. Эта статья берет, где предыдущий NHibernate с брошенной статьей ASP.NET и описывает детали реализации этого просто звучащего подхода. Хотя предыдущая статья, сфокусированная на ASP.NET, ниже предложения, поддерживается и в ASP.NET и в.NET.

...

Первое, что нужно сделать, когда работа с несколькими базами данных должна настроить необходимые связи. Создайте отдельный файл конфигурации для каждой базы данных, поместите их всех в центральную папку конфигурации и затем сошлитесь на них от web/app.config.

...

Я не на 100% уверен, что это сделает то, в чем я нуждаюсь, но я нашел этот поиск с помощью Google сегодня о NHibernate и анонимных типах:

http://infozerk.com/averyblog/refactoring-using-object-constructors-in-hql-with-nhibernate/

Интересная часть (мне, я плохо знаком с этим), 'новое' ключевое слово в пункте выбора HQL. Таким образом, то, что я мог сделать, выбрать SerialX из DatabaseX с помощью mappingX и передать его конструктору для SerialY (общий/основной Сериал). Таким образом, теперь мне генерировали SerialY от mappingX/databaseX, и (надо надеяться) я мог затем session.save, и NHibernate будет использовать mappingY/databaseY.

Причина мне нравится это, просто не имеет двух классов с теми же сохраненными данными (я думаю!). Нет действительно никакого функционального различия между этим и возвратом списка SerialX, итерации через него и генерации SerialY и добавления его к новому списку (первый и лучший данный ответ).

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

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

Можно затем агрегировать их всех вместе в единственный набор на прикладном уровне (Т.е. Список), где каждый из тех классов реализует Список),

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

Я записал действительно длинное сообщение с кодом и всем для ответа на Dan. Это закончилось, я думаю, что пропустил очевидное.

public class Serial
{
    public string SerialNumber {get; set;}
    public string ItemNumber {get; set;}
    public string OrderNumber {get; set;}
}

...

Serial serial = sessionX.get(typeof(Serial), someID);
sessionY.save(serial);

NHibernate должен использовать mappingX для получения и mappingY для сохранения, так как сессии не совместно используются, и отображение связывается с сессией. Таким образом, у меня может быть 2 отображения, указывающие на тот же класс потому что на какой-то конкретной сессии существует только единственное отображение на отношения класса.

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

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

Это сказало, что я нашел это через Google:

http://jira.nhibernate.org/browse/NH-662

Это - точно та же ситуация, и это кажется (возможно) обращенным в NH 2.1 +? Я еще не следовал ему.

(примечание: Dan, в моем случае я добираюсь от нескольких дб, только пишущий в один. Я все еще интересуюсь Вашим предложением об интерфейсе, потому что я думаю, что это - хорошая идея для других случаев. Вы определили бы отображение против интерфейса? Если я пытаюсь сохранить класс, который реализует интерфейс, который не имеет отображающегося определения, NHibernate использовал бы интерфейсное отображение? Или я должен был бы объявить пустые подклассы в отображении для каждого класса, который реализует интерфейсное отображение?)