Spring DAO vs Spring ORM vs Spring JDBC

1. int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);  
2.   
3.   
4. Person p = jdbcTemplate.queryForObject("select first, last from person where id=?",   
5.              rs -> new Person(rs.getString(1), rs.getString(2)),   
6.              134561351656L);  

Spring-JDBC 还提供了一个 JdbcDaoSupport，这样你可以对你的 DAO 进行扩展开发。它主要定义了两个属性：一个 DataSource 和一个 JdbcTemplate，它们都可以用来实现 DAO 方法。JdbcDaoSupport 还提供了一个将 SQL 异常转换为 Spring DataAccessExceptions 的异常翻译器。
如果你计划使用纯 jdbc，那么你需要使用 Spring-JDBC 模块。

Spring-ORM

Spring-ORM 是一个囊括了很多持久层技术(JPA，JDO，Hibernate，iBatis)的总括模块。对于这些技术中的每一个，Spring 都提供了集成类，这样每一种技术都能够在遵循 Spring 的配置原则下进行使用，并平稳地和 Spring 事务管理进行集成。
对于每一种技术，配置主要在于将一个 DataSource bean 注入到某种 SessionFactory 或者 EntityManagerFactory 等 bean 中。纯 JDBC 不需要这样的一个集成类(JdbcTemplate 除外)，因为 JDBC 仅依赖于一个 DataSource。
如果你计划使用一种 ORM 技术，比如 JPA 或者 Hibernate，那么你就不需要 Spring-JDBC 模块了，你需要的是这个 Spring-ORM 模块。

Spring-Data

Spring-Data 是一个提供了一个通用 API 来定义如何以一个更通用的方式访问数据(DAO + 注解)的总括模块，包括 SQL 和 NOSQL 数据源。
初步设想是提供一种技术，开发者可以以一种技术无关的方式为 DAO 和实体类写接口，仅仅基于配置(在 DAO 和实体类加注解 + spring 配置，或者 xml 配置)，就可以决定实现技术是 JPA(SQL) 还是 redis，hadoop 等等。
如果你遵循了 spring 为方法查找定义的命名规范，大多数简单的场景下你甚至都不需要为查找方法提供查询字符串。其他少数情况下，你需要在查找方法的注解里提供查询字符串。
在应用上下文被加载后，spring 为 DAO 接口提供代理，它包含有数据访问技术相关的所有样板代码，并调用配置的查询。
Spring-Data 专注于非 SQL 技术，但仍为 JPA(唯一的 SQL 技术，其他诸如 Hibernate 等没有)提供了一个模块。

该选择哪个

了解了这些，现在你可以决定选用哪一个了。好消息是你不需要为底层技术做一个明确的最终选择。这正是 Spring 主旨所在：作为一名开发人员，在你写代码的时候更多专注于业务逻辑，如果你把业务处理好了，改变底层技术只是一些实现或者配置细节的工作。

1. 使用 POJO 类为实体定义一个数据模型，并使用 get 和 set 方法来表示实体的属性以及和其他实体的关系。你当然需要根据底层技术的需要为实体类及其方法加注解，但是现在，作为入门 POJO 足够了。现在你只需要专注于业务需求。
2. 为你的 DAO 定义接口。一个 DAO 刚好包含一个实体，但你也无需为每个实体都对应一个 DAO，因为通过关联关系你可以加载到额外的实体。遵循严格的命名约定定义查找器方法。
3. 藉此，其他人就可以模仿你的 DAO 开始业务层的工作了。
4. 你可以学习不同的持久层技术(sql，no-sql)来寻找最适合你需要的那个，并最终选择一个。藉此，为你的实体注解并实现 DAO(或者如果你选择使用 Spring-Data 你可以让 Spring 来实现 DAO)。
5. 如果你的业务需求进化，而你的数据访问技术对此的支持并不充分(比方说，一开始你使用了 JDBC，只有寥寥几个实体，但是现在需要一个更加丰富的数据模型，而 JPA 是一个比较好的选择)，那么你需要修改你的 DAO 实现，在你的实体上添加一些注解并修改 Spring 配置(添加一个 EntityManagerFactory 定义)。但这些也只是持久层的改动，对于业务逻辑层的代码不应该受到到因此改动的影响。

注意：事务管理

Spring 为事务管理提供了一个 API。如果你的数据访问计划使用 spring，那么你也应该用 spring 来做事务管理，因为它们整合在一起确实很好。对于每一个 spring 支持的数据访问技术，都有一个为本地事务匹配的事务管理器，或者如果你需要分布式事务你也可以选择 JTA。它们都实现了同样的 API，因此持久层技术的选择只是一个随意调整的配置的事情，它的更改不会影响到业务代码。
原文链接：http://stackoverflow.com/questions/24990400/spring-dao-vs-spring-orm-vs-spring-jdbc。

本文转自http://blog.csdn.net/defonds/article/details/47445915 感谢作者

Spring DAO vs Spring ORM vs Spring JDBC

标签：