Ibatis
Páginas: 14 (3330 palabras)
Publicado: 27 de julio de 2011
iBATIS Data Access Objects Developer Guide
Version 2.0
February 18, 2006
Developer Guide
iBATIS Data Access Objects 2.0
2
Introduction
When developing robust Java applications, it is often a good idea to isolate the specifics of your persistence implementation behind a common API. Data Access Objects allow you to create simple components that provide access to your datawithout revealing the specifics of the implementation to the rest of your application. Using DAOs you can allow your application to be dynamically configured to use different persistence mechanisms. If you have a complex application with a number of different databases and persistence approaches involved, DAOs can help you create a consistent API for the rest of your application to use.
Data AccessObjects (com.ibatis.dao.*)
The iBATIS Data Access Objects API can be used to help hide persistence layer implementation details from the rest of your application by allowing dynamic, pluggable DAO components to be swapped in and out easily. For example, you could have two implementations of a particular DAO, one that uses the iBATIS SQL Maps framework to persist objects to the database, andanother that uses the Hibernate framework. Another example would be a DAO that provides caching services for another DAO. Depending on the situation (e.g. limited database performance vs. limited memory), either the cache DAO could be “plugged in” or the standard un-cached DAO could be used. These examples show the convenience that the DAO pattern provides, however, more important is the safety thatDAO provides. The DAO pattern protects your application from possibly being tied to a particular persistence approach. In the event that your current solution becomes unsuitable (or even unavailable), you can simply create new DAO implementations to support a new solution, without having to modify any code in the other layers of your application. Note! The DAO framework and SQLMaps Framework arecompletely separate and are not dependent on each other in any way. Please feel free to use either one separately, or both together.
The Components of the Data Access Objects API
There are a number of classes that make up the DAO API. Each has a very specific and important role. The following table lists the classes and a brief description. The next sections will provide more detail on howto use these classes. Class/Interface (Patterns) DaoManager (Façade) DaoTransaction (Marker Interface) DaoException (RuntimeException) Dao (Marker Interface) Description Responsible for configuration of the DAO framework (via dao.xml), instantiating Dao implementations and acts as a façade to the rest of the API. A generic interface for marking transactions (connections). A common implementationwould wrap a JDBC connection object. All methods and classes in the DAO API throw this exception exclusively. Dao implementations should also throw this exception exclusively. Avoid throwing any other exception type, and instead nest them within the DaoException. A marker interface for all DAO implementations. This interface must be implemented by all DAO classes. This interface does not declareany methods to be implemented, and only acts as a marker (i.e. something for the DaoFactory to identify the class by).
http://www.ibatis.com
by Clinton Begin
Developer Guide
iBATIS Data Access Objects 2.0
3
JDBC Transaction Manager Implementations
SQLMAP HIBERNATE JDBC JTA EXTERNAL Manages transactions via the SQL Maps framework and its transaction management services includingvarious DataSource and transaction manager configurations. Provides easy integration for Hibernate and its associated transaction facilities (SessionFactory, Session, Transaction). Manages transactions via the JDBC API using the basic DataSource and Connection interfaces. Manages JTA global (distributed) transaction services. Requires a managed DataSource that can be accessed via JNDI. Allows...
Version 2.0
February 18, 2006
Developer Guide
iBATIS Data Access Objects 2.0
2
Introduction
When developing robust Java applications, it is often a good idea to isolate the specifics of your persistence implementation behind a common API. Data Access Objects allow you to create simple components that provide access to your datawithout revealing the specifics of the implementation to the rest of your application. Using DAOs you can allow your application to be dynamically configured to use different persistence mechanisms. If you have a complex application with a number of different databases and persistence approaches involved, DAOs can help you create a consistent API for the rest of your application to use.
Data AccessObjects (com.ibatis.dao.*)
The iBATIS Data Access Objects API can be used to help hide persistence layer implementation details from the rest of your application by allowing dynamic, pluggable DAO components to be swapped in and out easily. For example, you could have two implementations of a particular DAO, one that uses the iBATIS SQL Maps framework to persist objects to the database, andanother that uses the Hibernate framework. Another example would be a DAO that provides caching services for another DAO. Depending on the situation (e.g. limited database performance vs. limited memory), either the cache DAO could be “plugged in” or the standard un-cached DAO could be used. These examples show the convenience that the DAO pattern provides, however, more important is the safety thatDAO provides. The DAO pattern protects your application from possibly being tied to a particular persistence approach. In the event that your current solution becomes unsuitable (or even unavailable), you can simply create new DAO implementations to support a new solution, without having to modify any code in the other layers of your application. Note! The DAO framework and SQLMaps Framework arecompletely separate and are not dependent on each other in any way. Please feel free to use either one separately, or both together.
The Components of the Data Access Objects API
There are a number of classes that make up the DAO API. Each has a very specific and important role. The following table lists the classes and a brief description. The next sections will provide more detail on howto use these classes. Class/Interface (Patterns) DaoManager (Façade) DaoTransaction (Marker Interface) DaoException (RuntimeException) Dao (Marker Interface) Description Responsible for configuration of the DAO framework (via dao.xml), instantiating Dao implementations and acts as a façade to the rest of the API. A generic interface for marking transactions (connections). A common implementationwould wrap a JDBC connection object. All methods and classes in the DAO API throw this exception exclusively. Dao implementations should also throw this exception exclusively. Avoid throwing any other exception type, and instead nest them within the DaoException. A marker interface for all DAO implementations. This interface must be implemented by all DAO classes. This interface does not declareany methods to be implemented, and only acts as a marker (i.e. something for the DaoFactory to identify the class by).
http://www.ibatis.com
by Clinton Begin
Developer Guide
iBATIS Data Access Objects 2.0
3
JDBC Transaction Manager Implementations
SQLMAP HIBERNATE JDBC JTA EXTERNAL Manages transactions via the SQL Maps framework and its transaction management services includingvarious DataSource and transaction manager configurations. Provides easy integration for Hibernate and its associated transaction facilities (SessionFactory, Session, Transaction). Manages transactions via the JDBC API using the basic DataSource and Connection interfaces. Manages JTA global (distributed) transaction services. Requires a managed DataSource that can be accessed via JNDI. Allows...
Leer documento completo
Regístrate para leer el documento completo.