Java泛型的使用以及注入DAO --由SpringSide想到的
2006-08-31 11:25
399 查看
DAO层的BaseHibernateDao类支持泛型,其目的是使得 子类 声明其操作的Persistence Class,以获得完整的CRUD功能。例如:
但是,由于BaseDAOHibernate提供了丰富的CRUD功能,所以在大多数情况下,子类不需要扩展。由此,我们很自然的想到,每一个Manager类直接注入BaseDAOHibernate(而不是它的子类):
可实际上,这是不行的。BaseHibernateDao的getObject方法会抛出NullPointerException。跟踪代码,发现,getObject()方法调用了HibernateTemplate的get(Class,Serializable id)方法。为了拿到泛型的实际类型,使用了getEntityClass()方法,而getEntityClass()方法总是返回null。这是怎么回事呢,我们看getEntityClass()的实现,发现,这方法调用了Class.getGenericSuperclass();该方法用于获取超类中声明的泛型的实际类型。如果我们使用UserDAO,由于它继承了BaseDAOHibernate<User>,所以没有问题,而如果直接用BaseDAOHibernate<User>,由于没有所谓的Superclass,所以entityClass总是null.
解决的办法是:如果Dao子类无需扩展BaseDAOHibernate,那么可以省略,用Manager类直接扩展BaseDAOHibernate即可。这样作似乎破坏了分层体系,并且有滥用继承的嫌疑(造成Manager层与Dao层紧密耦合),同时也违反了IOC一切都注入的思想。但是,其好处也是明显的,那就是 开发效率 高!
是呀,按照Rod和Appfuse的做法,一个CRUD要写5个类(DAO interface,DAO impl,Manager Interface,Manager impl, Action)和至少两个配置文件(applicationContext.xml,web层的配置),的确够麻烦,看人家ROR。
所以,我同意SS和白衣的看法:大多数项目或模块,可以省略一个Dao层,直接在Manager层继承BaseDAOHibernate即可。但是,个人仍然提倡用一个ManagerInterface(SpringSide连这个也省了),因为这个Interface可以隔离Web层和Manager+DAO层,在一定程度上,提高扩展性。
例子:
public class UserDAO extends BaseHibernateDao<User> { User getUser(Integer userId) { return getObject(id);//method of BaseDAOHibernate } }
但是,由于BaseDAOHibernate提供了丰富的CRUD功能,所以在大多数情况下,子类不需要扩展。由此,我们很自然的想到,每一个Manager类直接注入BaseDAOHibernate(而不是它的子类):
public class UserManager extends BaseManager<User> { private BaseHibernateDao<User> dao; //getter and setter of dao property... //business methods public User getUserById(Integer id) { return getDao().getObject(id); } }
可实际上,这是不行的。BaseHibernateDao的getObject方法会抛出NullPointerException。跟踪代码,发现,getObject()方法调用了HibernateTemplate的get(Class,Serializable id)方法。为了拿到泛型的实际类型,使用了getEntityClass()方法,而getEntityClass()方法总是返回null。这是怎么回事呢,我们看getEntityClass()的实现,发现,这方法调用了Class.getGenericSuperclass();该方法用于获取超类中声明的泛型的实际类型。如果我们使用UserDAO,由于它继承了BaseDAOHibernate<User>,所以没有问题,而如果直接用BaseDAOHibernate<User>,由于没有所谓的Superclass,所以entityClass总是null.
解决的办法是:如果Dao子类无需扩展BaseDAOHibernate,那么可以省略,用Manager类直接扩展BaseDAOHibernate即可。这样作似乎破坏了分层体系,并且有滥用继承的嫌疑(造成Manager层与Dao层紧密耦合),同时也违反了IOC一切都注入的思想。但是,其好处也是明显的,那就是 开发效率 高!
是呀,按照Rod和Appfuse的做法,一个CRUD要写5个类(DAO interface,DAO impl,Manager Interface,Manager impl, Action)和至少两个配置文件(applicationContext.xml,web层的配置),的确够麻烦,看人家ROR。
所以,我同意SS和白衣的看法:大多数项目或模块,可以省略一个Dao层,直接在Manager层继承BaseDAOHibernate即可。但是,个人仍然提倡用一个ManagerInterface(SpringSide连这个也省了),因为这个Interface可以隔离Web层和Manager+DAO层,在一定程度上,提高扩展性。
例子:
Interface UserManager extendes Manager<User> { User getUserById(int id); } public class UserManagerImpl extends BaseDAOHibernate<User> implements UserManager { public User getUserById(int id) { return getObject(id); } }
相关文章推荐
- 使用mybatis自带工具,自动生成表对应domain、mapper.xml以及dao
- 当Dao层继承了HibernateDaoSupport,使用底层SQL语句,session获取的方法,以及解决关联查询no session的问题
- 为什么使用Java泛型 以及 Java泛型使用方法
- 为什么使用Java泛型 以及 Java泛型使用方法
- Asp.Net MVC 之 Autofac 初步使用2 集成mvc 属性注入以及自动注入
- java泛型操作复习,以及讲解在android中使用的场景
- PDO防注入原理分析以及使用PDO的注意事项
- 在普通Java类里使用spring里注入的service、dao等
- 为什么使用Java泛型 以及 Java泛型使用方法
- 为什么使用Java泛型 以及 Java泛型使用方法
- 使用ASP.NET Web Api构建基于REST风格的服务实战系列教程【四】——实现模型工厂,依赖注入以及格式配置
- 使用Spring的@Autowired 实现DAO, Service, Controller三层的注入
- SpringBoot项目使用注入的Service或DAO时值为空
- PDO防注入原理分析以及使用PDO的注意事项
- Java框架spring 学习笔记(十六):c3p0连接池的配置以及dao使用jdbcTemplate
- java泛型操作复习,以及讲解在android中使用的场景
- [转载]PDO防注入原理分析以及使用PDO的注意事项
- 简单三步快速学会使用Mybatis-Generator自动生成entity实体、dao接口以及mapper映射文件(postgre使用实例)
- PDO防注入原理分析以及使用PDO的注意事项
- PDO防注入原理分析以及使用PDO的注意事项