MULTIPLE DATABASES AND SESSION FACTORIES in C#

Encoder Code 3/9 in C# MULTIPLE DATABASES AND SESSION FACTORIES

We ve demonstrated the creation of a single SessionFactory, which is all that most applications need. If you need another ISessionFactory instance in the case of multiple databases, for example repeat the process. Each SessionFactory is then available for one database and ready to produce ISession instances to work with that particular database and a set of class mappings. Once you have your SessionFactory, you can go on to create sessions, and start loading and saving objects.

Of course, there is more to configuring NHibernate than pointing to mapping documents. You also need to specify how database connections are to be obtained, along

with various other settings that affect the behavior of NHibernate at runtime. The multitude of configuration properties may appear overwhelming (a complete list appears in the NHibernate documentation), but don t worry; most define reasonable default values, and only a handful are commonly required. To specify configuration options, you may use any of the following techniques:

Pass an instance of System.Collections.IDictionary to Configuration. SetProperties(), or use Configuration.SetProperty() for each property (or manipulate the collection Configuration.Properties directly). Set all properties in application configuration file (App.config or Web.config). Include <property> elements in an XML file called hibernate.cfg.xml in the current directory.

The first option is rarely used except for quick testing and prototypes, but most applications need a fixed configuration file. Both the application configuration file and the hibernate.cfg.xml file provide the same function: to configure NHibernate. Which file you choose to use depends on your syntax preference. hibernate.cfg.xml is the filename chosen by convention. You can use any filename (such as NHibernate.config, because .config files are automatically protected by ASP.NET when deployed) and provide this filename to the Configure() method. It s even possible to mix both options and have different settings for development and deployment. A rarely used alternative option is to let the application provide an ADO.NET IDbConnection when it opens an NHibernate ISession from the SessionFactory (for example, by calling sessionFactory.OpenSession(myConnection)). Using this option means you don t have to specify any database-connection properties (the other properties are still required). We don t recommend this approach for new applications that can be configured to use the environment s database-connection infrastructure. Of all the configuration options, database-connection settings are the most important because, without them, NHibernate won t know how to correctly talk to the database.

Most of the time, the application is responsible for obtaining ADO.NET connections. NHibernate is part of the application, so it s responsible for getting these connections. You tell NHibernate how to get (or create new) ADO.NET connections. Figure 2.2 shows how .NET applications interact with ADO.NET. Without NHibernate, the application code usually receives an ADO.NET connection from the connection pool (which is configured transparently) and uses it to execute SQL statements.

Hello NHibernate!

With NHibernate, the picture changes: NHibernate acts as a client of ADO.NET and its connection pool, as shown in figure 2.3. The application code uses the NHibernate ISession and IQuery APIs for persistence operations and only has to manage database transactions, ideally using the NHibernate ITransaction API.

Listing 2.6 uses a file named hibernate.cfg.xml to configure NHibernate to access a Microsoft SQL Server 2000 database.

< xml version="1.0" > <hibernate-configuration xmlns="urn:nhibernate-configuration-2.2"> <session-factory> <property name="connection.provider"> NHibernate.Connection.DriverConnectionProvider </property> <property name="dialect"> NHibernate.Dialect.MsSql2000Dialect </property> <property name="connection.driver_class"> NHibernate.Driver.SqlClientDriver </property> <property name="connection.connection_string"> Data Source=(local); Initial Catalog=nhibernate; Integrated Security=SSPI </property> </session-factory> </hibernate-configuration>

This code s lines specify the following information:

connection.provider specifies the name of the .NET class implementing the IConnectionProvider interface; here, we use the default one. dialect specifies the name of the .NET class implementing the database Dialect. Dialects are how NHIbernate can take advantage of database-specific fea-

tures. Despite the ANSI standardization effort, SQL is implemented differently by various databases vendors. You must specify a Dialect. NHibernate includes built-in support for most popular SQL databases, and new dialects may be defined easily.