IBATIS DATA ACCESS OBJECTS DEVELOPER GUIDE
0
komentar
Download free iBATIS Data Access Objects Developer Guide pdf. 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 data without 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.
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, and another 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 that DAO 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.
Download iBATIS Data Access Objects Developer Guide
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, and another 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 that DAO 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.
Download iBATIS Data Access Objects Developer Guide
Categories:
Database
If You Like This Post, Share it With Your Friends & Peers
0 komentar:
Post a Comment