Вы, кажется, просите поменять соединение для данного сеанса. Или, скорее, это то, о чем просит написанный вами код - «вернуть сеанс, определенный параметром name, и теперь он также должен использовать строку подключения, предоставленную этим методом».
Это невозможно. NHibernate строит сессию (и фактически фабрику сессий) для каждого соединения, а однажды построенная фабрика и сессия являются неизменяемыми. Вы не можете изменить соединения для существующего сеанса.
У меня сложилось впечатление, что ваше приложение использует в основном исходную строку соединения, которая является движущейся целью, но после этого ваш "настоящий" сеанс находится в одной базе данных. Если это так, NHibernate может легко сделать это. Если это не так, то для некоторых вещей NHibernate просто не подходит. Может быть, понимание того, на чем работает NHibernate, полезно в любом случае?
Одна из моих истинных критики в отношении NHibernate заключается в том, что вы несколько загадочно используете терминологию и хорошо известный бесполезный характер сообщений об исключениях. Это в сочетании с тем фактом, что то, что он делает, на самом деле является механически сложным, действительно скрывает, что существует относительно простая и технически обоснованная базовая модель.
В этом случае, если вы подумаете об этом, этот бизнес неизменного сеанса имеет большой смысл. NHibernate подключается к базе данных, но также поддерживает объекты в сеансе, чтобы они могли быть сохранены в этой базе данных позже. NHibernate не поддерживает изменение соединений в сеансе, поскольку в этом сеансе уже могут быть другие объекты, и если вы меняете соединения, их постоянство больше не гарантируется.
Теперь вы можете создать фабрику / сеанс для каждой базы данных для нескольких баз данных и обращаться к ним в одном приложении, но объекты по-прежнему принадлежат их собственному сеансу. Вы даже можете переместить объекты в новый сеанс с другим подключением. В этом случае у вас есть сценарий «репликации». NHibernate поддерживает это, но вы должны сделать большую часть работы. Это также имеет смысл - они действительно не могут дать вам такую стабильную функциональность, как вы, и вам придется управлять таким процессом самостоятельно.
Вы также можете создать код, чтобы сделать именно то, что вы просите. Но подумай, что это такое. Создайте сеанс не для каждой базы данных, а только для этого конкретного экземпляра этого конкретного хранилища. Я думаю, что это, скорее всего, не совсем то, что вы хотите. Но это именно то, что семантика вашего запроса говорит сделать. С другой стороны, ваш существующий класс был построен на другой семантике, которая, как правило, более того нужна людям: «Создайте сеанс для этого конкретного определения соединения , т.е. этой базы данных».
Реальная потребность ввести строку соединения на уровне хранилища подразумевает, что теперь не только база данных является движущейся целью, но и на уровне фактической таблицы цель также перемещается. Если это так, то NHibernate, возможно, не очень хороший вариант. Если это не так, возможно, вы пытаетесь смешать парадигмы программирования. NHiberate навязывает несколько того, что я бы назвал «допущениями», а не какими-то реальными «ограничениями», и взамен вам не нужно писать кучу кода, который позволил бы вам получить более тонкую часть контроля, потому что часто вы действительно этого не делаете нужен этот дополнительный контроль.
Извините, если это больше не прямой ответ на ваш вопрос, надеюсь, это как-то полезно.
Оригинальный ответ:
Конечно, поскольку информация о соединении находится в базе данных аутентификации, это легко.
1) Сконфигурируйте NHibernate «обычным» способом и укажите конфигурацию в базе данных аутентификации. Получите соединение БД для пользователя, а затем закройте этот сеанс и фабрику сеансов. Вы закончили с этим сейчас.
2) На этот раз создайте новый сеанс и т. Д. В коде вместо файла конфигурации.
class MyNewSession
{
private ISession _session;
private ISessionFactory _factory;
public void InitializeSession()
{
NHibernate.Cfg.Configuration config = new NHibernate.Cfg.Configuration();
config.Properties.Clear();
IDictionary props = new Hashtable();
// Configure properties as needed, this is pretty minimal standard config here.
// Can read in properties from your own xml file or whatever.
// Just shown hardcoded here.
props["proxyfactory.factory_class"] = "NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle";
props["connection.provider"] = "NHibernate.Connection.DriverConnectionProvider";
props["dialect"] = "NHibernate.Dialect.MsSql2000Dialect";
props["connection.driver_class"] = "NHibernate.Driver.SqlClientDriver";
props["connection.connection_string"] = "<YOUR CONNECTION STRING HERE>";
props["connection.isolation"] = "ReadCommitted";
foreach (DictionaryEntry de in props)
{
config.Properties.Add(de.Key.ToString(), de.Value.ToString());
}
// Everything from here on out is the standard NHibernate calls
// you already use.
// Load mappings etc, etc
// . . .
_factory = config.BuildSessionFactory();
_session = _factory.OpenSession();
}
}