毕业设计之每天总结 一

遇到的问题：

1.ConstraintViolationException

提交参数中有null;

今天的学习：

1.

<bean id="paperList"
		  class="com.shu.cms.action.collection.PaperAction">
		<property name="action" value="list" />
		<property name="commandClass" value="com.shu.cms.form.collection.PaperForm"/>
		<property name="formView" value="/admin/collection/paper_list" />
		<property name="successView" value="redirect:/paper_list.htm" />
		<property name="paperService" ref="paperService" /> 
	</bean>

commandClass 属性用于绑定页面对应的视图View对应的Form

2.DAO层设计

一个HibernateDAO用于实现基本insert，update ，delete操作。所有事务处理用一个参数类封装

再在底层使用HibernateUtil,拆解封装事务进行数据库操作.

HibernateUtil.doQuery();

在这之前我的DAO层设计（如图）：

这种设计是在李刚的J2EE开发书上看的，当时因为觉得获取list的需求会很不一样，各种各样的条件于是就会有很多特例的操作方法，所以把这些基本操作都

分别让DAO各自实现list。这样就会在单独的类里面产生很多个list方法，相应的接口中也一样。当时就觉得非常混乱。而且代码也有很多的重复

每次修改一个数据库操作就得把涉及到的DAO接口实现类，以及底层的数据库操作代码都修改一遍。觉得没体现到什么便捷。

今天学到了另外一种DAO层设计如图：

这样的话各种各样的数据库操作都用一个操作类（QueryParam）进行封装。这样list就只需要一个就行。于是把这些方法都放在HibernateDAO上。具体的StudentDAO

什么的就只要继承HibernateDAO就行。只需要封装特定的操作最后调用相应DAO的list方法。然后在HibernateDAO中用HibernateUtil解析QueryParam来实现list（QueryParam）.如此就不需要在XxxDAO中编写一大堆list了。以后需要增加或者修改需求的话只需要重新定义个QueryParam然后调用studentDAO.list(QueryParam)就行

这样就把执行事务和事务本身给区分开来了