What are the factors that determine when you choose different data access technologies? The access choices would then be straight JDBC, Spring's JDBC framework, iBatis, and Hibernate or JDO. The straight JDBC solution would, in our opinion, be the solution of choice only when you are not allowed to use any framework besides what is delivered in J2SE or J2EE.
If your project has only a few persistent classes or you have to map to an existing database with several stored procedures, then a Spring JDBC solution makes sense. There is very little to configure and if you have only a few classes to map to a Java class, then the MappingSQLQueyr makes mapping straightforward. The Storedprocedure class makes working with stored procedures easy.
If you have many classes that map to an existing database or you don't have control over the database design, then you have to look at the mapping options between the tables and your java classes.
When to Choose O/R Mapping
O/R mapping can have many benefits, but it is important to remember that not every application fits the O/R mapping paradigm.
Central issues are heavy use of set access and aggregate functions, and batch updates of many rows. If an application is mainly concerned with either of those — for example, a reporting application — and does not allow for a significant amount of caching in an object mapper, set-based relational access via Spring JDBC or iBATIS SQL Maps is probably the best choice.
Because all O/R mapping frameworks have a learning curve and setup cost, applications with very simple data access requirements are also often best to stick with JDBC-based solutions. Of course, if a team is already proficient with a particular O/R mapping framework, this concern may be less important.
Indicators that O/R mapping is appropriate are:
A typical load/edit/store workflow for domain objects: for example, load a product record, edit it, and synchronize the updated state with the database.
Objects may be possibly queried for in large sets but are updated and deleted individually.
A significant number of objects lend themselves to being cached aggressively (a "read-mostly" scenario, common in web applications).
There is a sufficiently natural mapping between domain objects and database tables and fields. This is, of course, not always easy to judge up front. Database views and triggers can sometimes be used to bridge the gap between the OO model and relational schema.
There are no unusual requirements in terms of custom SQL optimizations. Good O/R mapping solutions can issue efficient SQL in many cases, as with Hibernate's "dialect" support, but some SQL optimizations can be done only via a wholly relational paradigm
If your project has only a few persistent classes or you have to map to an existing database with several stored procedures, then a Spring JDBC solution makes sense. There is very little to configure and if you have only a few classes to map to a Java class, then the MappingSQLQueyr makes mapping straightforward. The Storedprocedure class makes working with stored procedures easy.
If you have many classes that map to an existing database or you don't have control over the database design, then you have to look at the mapping options between the tables and your java classes.
When to Choose O/R Mapping
O/R mapping can have many benefits, but it is important to remember that not every application fits the O/R mapping paradigm.
Central issues are heavy use of set access and aggregate functions, and batch updates of many rows. If an application is mainly concerned with either of those — for example, a reporting application — and does not allow for a significant amount of caching in an object mapper, set-based relational access via Spring JDBC or iBATIS SQL Maps is probably the best choice.
Because all O/R mapping frameworks have a learning curve and setup cost, applications with very simple data access requirements are also often best to stick with JDBC-based solutions. Of course, if a team is already proficient with a particular O/R mapping framework, this concern may be less important.
Indicators that O/R mapping is appropriate are:
A typical load/edit/store workflow for domain objects: for example, load a product record, edit it, and synchronize the updated state with the database.
Objects may be possibly queried for in large sets but are updated and deleted individually.
A significant number of objects lend themselves to being cached aggressively (a "read-mostly" scenario, common in web applications).
There is a sufficiently natural mapping between domain objects and database tables and fields. This is, of course, not always easy to judge up front. Database views and triggers can sometimes be used to bridge the gap between the OO model and relational schema.
There are no unusual requirements in terms of custom SQL optimizations. Good O/R mapping solutions can issue efficient SQL in many cases, as with Hibernate's "dialect" support, but some SQL optimizations can be done only via a wholly relational paradigm
Comments
Post a Comment