Spring DAO vs Spring ORM vs Spring JDBC

Pat's doubts

The recent focus on the data access technologies provided by spring is different for the spring-related projects I don't quite understand:

• Spring-dao (http://docs.spring.io/spring/docs/2.0.8/reference/dao.html)
• Spring-orm (http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/orm.html)
• SPRING-JDBC (http://docs.spring.io/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html)

As a personal understanding, Spring JDBC provides templates that can reduce the boilerplate code that writes SQL queries to access the database.
Spring-orm provides a simplified template for accessing the database via ROM technology, such as hibernate,my (i) Batis, and so on.
The data Access object (DAO) technology provided by the Spring website is designed to make it easy to use different data access technologies such as Jdbc,hibernate or JDO in a consistent way. spring-dao:spring
About ORM vs JDBC I know a little bit because they're all used to access the database in different ways. But for Spring-dao I was disoriented.
Do you have any friends to help clarify the difference between the three? What scenarios should be used for each preference?
In addition, spring now has another project Spring-data, is it a parent project of all the data access technologies provided by spring, or is it just a new name for Spring-dao?

Gaetan's explanation

Explanation of each of the technologies mentioned above.

Spring-dao

Spring-dao is not a Spring module, it is actually a specification that instructs you to write DAO operations and write good DAO operations. Therefore, for accessing your data it neither provides an interface nor provides a template for implementation. When writing a DAO, you should annotate it with @Repository so that the underlying technology (JDBC,HIBERNATE,JPA, and so on) can be consistently translated into the corresponding DataAccessException subclasses.
For example, suppose you are using Hibernate and your service layer captures hibernateexception for related processing. If you change to JPA and your DAO interface should not be changed, the service layer still compiles the block of code that captures hibernateexception, but you will never enter these blocks again, because your DAO now throws the JPA persistenceexception. By using @Repository on your DAO, the underlying technology-related exceptions are all interpreted as spring's dataaccessexception; Your service layer can catch these exceptions, and if you want to replace the persistence layer technology, because Spring The local exception is translated so the same Spring DataAccessException will still be thrown.
Note, however, that this usage is limited for the following reasons:

1. You should not catch exceptions in the persistence layer, because the underlying technology may have rolled the transaction back (depending on the specific exception type), so you should not continue to execute your fallback (in the persistence layer).
2. The level of exception provided by the underlying technology is often richer than that provided by Spring, and there is no qualification between the underlying technologies to match this. Such reliance is risky. But it's still a good idea to annotate your DAO class with @Repository, as these beans are automatically added by the scanner. In addition, Spring may add other useful features to this annotation.

Spring-jdbc

SPRING-JDBC provides a JDBC template class that removes the connection code to help you focus on SQL queries and related parameters. You just need to configure it with a DataSource, and then you can write code like this:

[Java]View PlainCopyprint?

1. int nbrows =  Jdbctemplate.queryforobject ( "Select count (1)  from person",  Integer.< span class= "keyword" >class)   
2.   
3.    
4. person p = jdbctemplate.queryforobject (
5.               rs ->  new person (rs.getstring (1),  rs.getstring ( 2),    
6.        &NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP;134561351656L);   

SPRING-JDBC also provides a jdbcdaosupport so that you can extend your DAO development. It mainly defines two properties: a DataSource and a jdbctemplate, both of which can be used to implement the DAO method. Jdbcdaosupport also provides an exception translator that converts SQL exceptions to Spring dataaccessexceptions.
If you plan to use pure JDBC, then you need to use the SPRING-JDBC module.

Spring-orm

Spring-orm is an umbrella module that includes many durable layer technologies (jpa,jdo,hibernate,ibatis). For each of these technologies, Spring provides an integration class so that each technology can be used in accordance with spring's configuration principles and smoothly integrated with spring transaction management.
For each technique, the configuration is primarily to inject a DataSource bean into a bean such as a sessionfactory or entitymanagerfactory. Pure JDBC does not require such an integration class (except for JdbcTemplate), because JDBC relies on only one DataSource.
If you plan to use an ORM technology like JPA or Hibernate, then you don't need the SPRING-JDBC module, you need this spring-orm module.

Spring-data

Spring-data is an umbrella module that provides a generic API to define how to access data in a more general way (DAO + annotations), including SQL and NOSQL data sources.
The preliminary idea is to provide a technology that developers can write to the DAO and entity classes in a technology-agnostic way, based only on configuration (in DAO and entity classes annotated + Spring configuration, or XML configuration) to determine whether the implementation technology is JPA (SQL) or redis,hadoop, etc. such as
If you follow the naming conventions that spring has defined for the method lookup, you don't even need to provide a query string for the lookup method in most simple scenarios. In a few other cases, you'll need to provide a query string in the comment for the lookup method.
After the application context is loaded, spring provides the proxy for the DAO interface, which contains all boilerplate code related to data access technology and invokes the configured query.
Spring-data focuses on non-SQL technology, but still provides a module for JPA (the only SQL technology, other than Hibernate, etc.).

Which is the choice?

Knowing this, you can now decide which one to choose. The good news is that you don't need to make a definitive final choice for the underlying technology. That's what Spring is all about: As a developer, you're more focused on business logic when you write code, and if you're working on your business, changing the underlying technology is just some implementation or configuration detail.

1. Use the POJO class to define a data model for an entity and use the get and set methods to represent the attributes of an entity and the relationships with other entities. You certainly need to annotate the entity classes and their methods according to the needs of the underlying technology, but now, as a primer POJO enough. Now you just need to focus on your business needs.
2. Define the interface for your DAO. A DAO contains exactly one entity, but you do not need to have one DAO for each entity, because you can load into additional entities by associating them. Follow strict naming conventions to define finder methods.
3. In this way, other people can imitate your DAO and start working on the business layer.
4. You can learn different persistence layer techniques (sql,no-sql) to find the one that best suits your needs and ultimately choose one. Thus, annotate and implement DAO for your entity (or if you choose to use spring-data you can let Spring implement DAO).
5. If your business needs evolve and your data access technology does not support it very well (for example, you used JDBC at first, only a few entities, but now you need a richer data model, and JPA is a better choice), then you need to modify your DAO implementation, Add some annotations to your entity and modify the Spring configuration (add a entitymanagerfactory definition). But these are only persistent layer changes, and the code for the business logic layer should not be affected by the changes.

Note: Transaction management

Spring provides an API for transaction management. If your data access plan uses spring, then you should also use spring for transaction management, because it's really good to integrate them together. For each spring-supported data access technology, there is a transaction manager that matches the local transaction, or you can choose JTA if you need a distributed transaction. They all implement the same API, so the choice of persistence layer technology is just a matter of a randomly tuned configuration, and its changes do not affect the business code.
Original link: http://stackoverflow.com/questions/24990400/spring-dao-vs-spring-orm-vs-spring-jdbc.

This article turns from http://blog.csdn.net/defonds/article/details/47445915 thanks to the author

Spring DAO vs Spring ORM vs Spring JDBC