The iBATIS.NET Data Access Objects framework has a number of goals. First, it attempts to hide the details of your persistence layer. This includes hiding all interface, implementation, and exception details of your persistence solution. For example: if your application is using raw ADO, the DAO framework will hide classes like DataReader, DataAdapter, Connection, and Command. Similarly, if your application is using the NHibernate object persistence library, the DAO framework will hide classes like Configuration, SessionFactory, Session, and HibernateException. All of these implementation details will be hidden behind a consistent DAO interface layer. Furthermore, the number of different data sources that are being used can be hidden from the view of the application.

The second goal of the framework is to simplify the persistence programming model while keeping it more homogeneous at the same time. Different persistence solutions have different programming semantics and behavior. The DAO framework attempts to hide this as much as possible, allowing the service and domain layer of your application to be written in a uniform fashion.

The DomDaoManagerBuilder class is responsible for the proper configuration of the DAO framework (via dao.config as described in previous sections). After configuration, another class called the DaoManager provides the core DAO API for each of your data access contexts. In particular, the DaoManager provides methods that allow you to access connection, transaction, and DAO instances.

Note

In prior versions of the DAO framework, the DaoManager handled configuration responsibilities. This has been superceded by a new configuration API found within the DomDaoManagerBuilder class. Old configuration method signatures have remained the same, but new configuration methods have been added for more flexibility. These new methods support the loading of configuration information through a Stream, Uri, FileInfo, or XmlDocument instance.