困惑：关于使用Struts、Hiberante，请大家讨论一下

Question

Hiberante没用过，Struts也是一知半解，向个位前辈学习，up

Answer 1

1、是否在action中就不能写数据操作部分的代码呢？
你说的对，你非要写到action中也没有办法。
2、dao中如果无法体现事务的处理，能在action中写呢？但这样是否违反了mvc？
我明白你的意思，你的action是一个线程，在你的action中可能用到好几个dao实现一个事物
解决的办法是利用java.lang.ThreadLocal保存线程中的连接，dao中将连结取出。
3、dao中如果要写每个逻辑的处理，那和action是不是又重复了？
前2个问题照做就没有这个问题
4、po、vo、actionform这几个是否有重叠的地方？怎么做比较合理，在业务修改的时候既能尽量少的修改代码，又能使这些重复量最少？
本来就是有重复的，之所以采用po、vo、actionform是为了层次分明，他们之间也还是存在一些区别的，如果完全一样，干脆用一个就行了。po是hibernate层的，vo只是个中间层次，actionform就不用说了。

Answer 2

学习，我是小猫感觉OO就是把传统开发方式后期遇到的麻烦都提前到设计阶段来了。*_*在读Design Patterns Explained时，看到作者一再的说responsibility，也就是说某个逻辑究竟应该由那个类来负责，在分层的框架设计时，就是确定那个层来负责。很难啊……

Answer 3

2、dao中如果无法体现事务的处理，能在action中写呢？但这样是否违反了mvc？
   当然不应该在action中写， 这里的mvc只是指web层范围内的，你指的dao无法体现，如果是指一个事务涉及了好几个DAO的话，我想你应该有一层service，每一个service方法视为一个事务。thread这是具体实现上的细节了。
3、dao中如果要写每个逻辑的处理，那和action是不是又重复了？
   dao 是低层的数据访问方法，逻辑不应该在这里出现，当然也不是在action中，还是应该有一个业务层的。
4、po、vo、actionform这几个是否有重叠的地方？怎么做比较合理，在业务修改的时候既能尽量少的修改代码，又能使这些重复量最少？
   vo是值对象，不带任何业务方法，便于在各层间传递，actionform可以理解为vo的一个特定子集，它只负责从页面上收集表单数据组装给action中的bean使用，顺道负责一些简单的非逻辑验证工作。po见上面兄弟所言

Answer 4

to wwwer1(武陵豪杰) :
我目前负责的一个项目就是这么做，方便是方便，可以很大程度上使开发人员工作内容分开，可是在事务处理的时候就比较麻烦，按照 _chage(青之六号) 所说的做法是可以，但是这样无形也加重了开发量，而且在业务变更的时候可能有不少的修改量。
to _chage(青之六号) ：
按你的说法增加了两层，业务层和service层，那action和dao具体要做什么比较合理呢？

Answer 5

我的观点就是Action中不出现业务逻辑，只是用来做一个控制器，把前台的参数传到后台的DAO或者BIZ层去，逻辑由后台去做，这样才能体现MVC的价值

Answer 6

to 老蒋:在业务逻辑层细分这两层不是硬性规定的，非此不可，而是根据业务复杂程序而定，因敌势而制敌者，谓之神。如果80%都是crud操作，就可以不要这一层了。
关于service layer，在企业应用架构模式一书中是这样定义的：通过一个服务层来定义应用程序边界，在服务层中建立一组可用的操作集合，提供给应用程序的请求。所以很显然，service是业务层的边界类，而action可算算表示层的边界，在action中调用
service方法。至于dao这个东东，原则上它属于数据持久层的，不提倡在表示层上直接调用它，只有相邻层才有依赖关系，跨层依赖是不好滴。dao是低层的细粒度方法，重用的可能性更大，一个service方法往往会调度若干dao类完成
整个事务。

Answer 7

老蒋，你指的“事务处理比较麻烦”，我的看法是这样的，事务处理是一个典型的非主线事件，也即是现在流行的AOP中的"方面"，现在的ORM，处理的方式不外乎二，一是编程实现，如ibatis，hibernate,
采用动态代理，在从工厂类获取每一个需要事务处理的业务类时，在方法前后都加上了事务代码，事务处理方式是灵活的，可以选jdbc,将来如果发生变化，有异构数据库，可以轻松转成jta，而对程序员是不可见的，他们无需负责事务，只要作好约定就可以了，比如说，以后缀名为_Tx结尾的方法都默认为一个事务。
    另一个方法是基于容器配置，典型的是spring，（EJB也是），这种方法更加灵活。
    至于你指出的，增加了开发量，使用 OO思想设计的领域模型，肯定比面向过程思维的脚本式编码类的数量要多很多，不过它带来的后期利益完全可以带来更大的回报。而且，在dao这一层面上，完全可以用代码生成技术加以辅助，如xDoclet。

Answer 8

to  _chage(青之六号) ：
说的不错，我尽量在接下去的架构设计中应用上，最近项目比较赶，没什么时间仔细把这些划分开，不过还好还有时间。由于架构设计需要平台无关，所以，我觉得由动态代理实现比较合理，不过这就要修改原有的设计代码，因为原本数据操作的封装没用工厂；至于那个service层，我还比较持保留，除了简单的crud可以在dao中做，其他按照这种约定的设计应该可以做的出来。有没有兴趣做个朋友，我在厦门工作，[email protected]