Spring DAO vs Spring ORM vs Spring JDBC

Pat's doubts have recently focused on the data-access technologies provided by spring, and the different aspects of the spring-related projects I'm not too clear about:

• 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.
Spring-dao on the Spring website:Spring provides data Access object (DAO) technology designed to make it easy to use different data access technologies such as Jdbc,hibernate or JDO in a consistent way.
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 of each of the above mentioned techniques.
Spring-daospring-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 use the@RepositoryIt is annotated so that the underlying technology (JDBC,HIBERNATE,JPA, and so on) can be translated in a consistent manner to the correspondingDataAccessExceptionSub-class.
For example, suppose you are using Hibernate, your service layer captureshibernateexceptionFor the relevant processing. If you change to JPA, your DAO interface should not change, and the service layer still compiles the capturehibernateexceptionBlocks of code, but you'll never get into these blocks again, because your DAO now throws the JPApersistenceexception。 By using the on your DAO@Repository, the underlying technology-related anomalies are explained in Spring'sDataAccessExceptionYour service layer can catch these exceptions, and if you want to replace the persistence layer technology, because spring translates local exceptions, it still throws the same springDataAccessException。
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-JDBCSPRING-JDBC provides a JDBC template class that removes the connection code to help you focus on SQL queries and related parameters. You just have to configure it with aDataSource, and then you can write the code like this:

int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);


Person p = jdbcTemplate.queryForObject("select first, last from person where id=?", 
             rs -> new Person(rs.getString(1), rs.getString(2)), 
             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-ormspring-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 some kind ofsessionfactoryOrentitymanagerfactorysuch as beans. 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-dataspring-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.).
The choice of which one understands these, now you can decide which 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.

Spring DAO vs Spring ORM vs Spring JDBC