The DaoManager class is responsible for the configuration of the DAO Framework by parsing a special configuration XML file. The configuration XML file specifies the following items:

A DAO context is a grouping of related configuration information and DAO implementations. Usually a context is associated with a single data source such as a relational database or a flat file. By configuring multiple contexts, you can easily centralize the data access configuration for multiple databases. The structure of the DAO configuration file (commonly called dao.config but not required) is as follows. Values that you will likely change for your application are highlighted.

<?xml version="1.0" encoding="utf-8"?>
<daoConfig  xmlns="http://ibatis.apache.org/dataAccess" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<providers resource="providers.config">

<!-- Example ADO.NET DAO Configuration -->
<context id="SimpleDao" default="true">
  <properties resource="properties.config"/>

  <database>
    <!-- Optional ( default ) -->
    <provider name="sqlServer1.1"/>
    <dataSource name="iBatisNet" 
                connectionString="data source=${datasource};database=${database};
                                  user id=${userid};password=${password};"/>
  </database>

  <daoFactory>
    <dao interface="IBatisNet.Test.Dao.Interfaces.IAccountDao, IBatisNet.Test"
         implementation="IBatisNet.Test.Dao.Implementations.Ado.AccountDao, IBatisNet.Test"/>
  </daoFactory>
</context>

<!-- Example SQL Maps DAO Configuration -->
<context id="SqlMapDao">
  <properties resource="properties2.config"/>
    
  <database>
     <provider name="OleDb1.1"/> 
     <dataSource name="iBatisNet" 
                 connectionString="Provider=SQLOLEDB;Server=${database};database=IBatisNet;
                                   user id=${userid};password=${password};"/>
  </database>

  <daoSessionHandler id="SqlMap">
    <property name="resource" value="SqlMap.config"/>
    <!-- 
    url and embedded options are also available
    <property name="url" value="C:\iBATIS\IBatisNet.DataAccess.Test\bin\Debug\SqlMap.config"/>
    <property name="embedded" value="bin.Debug.SqlMap.config, IBatisNet.DataAccess.Test"/>
    -->
  </daoSessionHandler>

  <daoFactory>
    <dao interface="IBatisNet.Test.Dao.Interfaces.IAccountDao, IBatisNet.Test"
         implementation="IBatisNet.Test.Dao.Implementations.DataMapper.AccountDao, IBatisNet.Test"/>
  </daoFactory>
</context>

</daoConfig>     

In the example above, what we end up with is two DAO contexts. DAOs are automatically aware of which context they belong to and therefore which session handler to use. Again, there can be any number of DAO contexts specified in a dao.config file, and generally, a context will refer to a single specific data source.

In order to manage multiple configurations for different environments (DEVT, Q/A, PROD), you can also make use of the optional <properties> element as shown above. This allows you to use placeholders in the place of literal value elements. If you have a "properties" file with the following values:

<add key="userid" value="IBatisNet" />
<add key="password" value="test" />
<add key="database" value="iBatisNet" />
<add key="datasource" value="(local)\NetSDK" />

You can use placeholders defined in that properties file instead of explicit values in the dao.config file. For example:

<dataSource name="iBatisNet" 
            connectionString="data source=${datasource};database=${database};
                              user id=${userid};password=${password};"/>

This allows for easier management of different environment configurations. Only one properties resource file may be specified per context.

Continuing with the example above, the provider and the datasource values are given within the database element. Following that, an optional daoSessionHandler may be specified. If none is specified, the default iBATIS.NET DAO SessionHandler called SimpleDaoSessionHandler will be used. In the example, the second context identifies the SessionHandler as SqlMap, meaning that the DAO implementations will be using iBATIS.NET Data Mapper SqlMaps instead of basic ADO calls.

Next in the context under daoFactory, is the specification of all DAO interfaces and their associated implementations. These mappings link a generic DAO interface to a concrete (specific) implementation. This is where we can see the pluggable nature of Data Access Objects. By simply replacing the implementation class for a given DAO mapping, the persistence approach taken can be completely changed (e.g. from ADO to iBATIS DataMapper SqlMaps to NHibernate).