使用struts+spring+hibernate做项目的困惑。

环境：
spring:1.1
hibernate:2.1.6
strut:1.2.4

在做这个项目前，我们一直用servlet+jsp+javabean+jdbc开发系统，开发过程简单，效率也还可以，但就是sql写的太多，后期维护的工作量越来越大。而且PO基本上是table的一个对应，PO之间没有类的关系。在前期系统分析，基本上是做数据结构分析，功能分析等。

在做现在这个项目，我坚决按照面向对象分析系统，一个迭代过程中产生4种图：用例图、类图、序列图，和页面流程图。

开发过程：
1、按照分析的结果，形成PO，并且在PO上添加hibernate doclet，然后生成Mapping文件，生成数据库结构。这时候的PO之间的关系完全按照现实中的事物之间的关系构造的。
2、PO做完后，就做DAO的接口，在对接口做测试类，然后利用spring提供的hibernateTemplate封装了数据库数据分页，然后实现了DAO接口类。
3、做业务类，过程也是按照接口，测试类，实现类的过程做
4、表现层，也就是Struts，没有什么说的。

现在遇到的下列问题：
1、我的PO都是按照对象关系来建立的，因此用hibernate查询的时候，一个查询竟然涉及到9个表，有可能是A和B、c有关系，而B又和D有关系，等等。这样一个很长的left join，我觉得对效率有很大的影响。
2、用Struts，用ActionForm做VO，就存在转换的问题，因为PO是面向对象的，而ActionForm是和表现对应的，一般来说我都将几个PO要显示的属性合成一个ActionForm，这样就带来了转换的问题，麻烦！！！用BeanUtils的copy，又出现问题，lazy initiation错误，尽管我不copy lazy的属性。于是我只有封装BeanUtils，指定那些不用copy，那些要copy的。还有PO的hashcode()，我只有将非lazy=true的属性写到hashcode中。
3、从ActionForm到PO时，还有个问题，就是ActionForm的信息不全，我通常只有从数据库Load一个对象，然后在copy属性，然后在dao.save(obj)。这样的效率有没有影响？
4、因为将事务交给Spring 容器管理，因此，一些需要共享事务的原子操作，我就只有利用HibernateCallback对象，将一个大操作的select ,delete,insert ,update都放在callback里面，我不知道有没有比这更好的方式？

谢谢大家。

谈谈我的做法：
1、过多的关联，我想应该是设计的问题。多对一关联，不一定非要关联到一个entity，放一个id也是可以的。

2、“ActionForm做VO”，其实也就是dto了，在同一个应用中，我认为dto是多余的麻烦，dto主要在分布式情况用的多。但在Web层直接使用entity,如果事务是Service级别，确实会有lazy load的问题，我用open session in view。这样，一个Action方法是一个事务单元。

3、做编辑的时候，标准的做法，当然是先Load，再修改。这样，当然不会有数据丢失的问题。

  解决2、3，无疑WebWork最能胜任（绝对没有做广告的嫌疑）！可以轻松搞定。

4、事务提交，我也是由Spring容器管理，使用HibernateCallback，但还没有发现什么不好的。

放id我倒不是特别反对，但用id的话hibernate生成的ddl就不能产生外键关联了
我最近做的一个项目需要用hessian传送
hibernate entity，有时候对象关联很麻烦 ，这时候是否需要dto呀？
但在hibernate entity和dto之间copy属性有是个大问题
我们现在的做法是把查询出来的hibernate entity clone一份，把
lazy的many-to-one，one-to-one中的proxied 对象取出，或者如果
client不需要这个关联对象的话，就把它set为null或只保留一个id，
而对于one-to-many，many-to-many则全部转换成java标准的set，list实现，累死了，
还不如用rmi得了，不过这样client端就要依赖hibernate的包了。

1.在mapping文件class元素加上lazy=true,<many-to-one outer-join=false>
2.ActionForm的属性使用po,如
xxForm
{
  Book book;
}
html里使用<input name="book.name"/>
,lazyload同样使用opensessioninview，不然好麻烦！
3.喜欢先在action load出来，再调用业务层的方法，这样才能享受面向对象的好处，也让业务层的代码干净，如:
xxService{
   doxxService(Po po)
   {
        po.doSomething()
       
        makePoPersistent(po);
   }
}

性能方面的考虑，hibernate有很好的缓存机制，所以性能应该不会差。

4.没看明白你的意思.我的做法是一个事务用一个方法封装，可能出现事务方法a调用事务方法b，事务属性用required，spring里作为一个事务处理。不过好象有人说过spring支持嵌套事务了。

上面的几个问题，我说说我的看法：

1、Hibernate的PO设计原则是尽量的fine-grained的，一次关联9张表，那就要考虑设计的思路是否出问题了。

2、在Web层/Client层放弃DTO，直接渲染PO，带来的Lazy loading问题。对于纯Web应用，可以应用OpenSessionInView模式，对于Client应用通过Hessian访问服务器端Service组件，我的建议则是把对象关联操作封装到DAO接口上去，例如：

Parent.getChildren();

相应的在ParentDAO增加：

ParentDAOImpl.getChildren(parent) {
    getHibernateTemplate().initialize(parent.getChildren());
     return parent.getChildren();
}

在Client端取某parent的children的时候，不要直接调用parent.getChildren(),而改用Hessian调用parentDAO.getChildren(parent)。

3、Spring管理的事务问题

我觉得你还没有真正理解Spring的事务管理机制。

1. 使用Lazy load
2. 使用Cache
3. outer join设置hibernate.max_fetch_depth

可能项目开始的设计不好也不一定，即使hibernate对对象关系的良好支持，也不要借此“对对象关联”大开杀戒吧！查询效率应该在设计初期就应该慎重考虑。
事务不是问题，应用级别的事务spring支持不要太好噢！
DTO现在越来越被反对！万不得已不要使用。

我设计的几个表是树形结构：
A与B是一对多关联，B对C是一对多关联，C对D是一对多关联，D对E又是一对多关联，A和F是一对多关联，A自身也关联。
这些我都在Hibernate中设置为one-to-many了，这样是不是对系统的性能有很大的影响呢？还有其他方式设计这种结构吗？或者是说在hibernate中都有哪几种方式改变这种设计方式的性能，不知大家有没有什么比较好的方法，请教我。

如果是fine-graned的话，那在查询条件复杂的情况下，由于PO之间没有关联，那又要怎样处理？因为我记得如果PO之间没有关联，HQL是没法将他们关联起来的，难道碰上复杂查询条件的话就只能直接去getConnection,再写普通的SQL。

我当初就是自己探讨Hibernater+Spring+Struts，最终用在实践的项目中的。
总的感觉就是作为刚开始用新技术时就会有些很难掌握全局的地方，但是如果你作完了第一次，以后就会在应用中发现并改正存在的问题。有时看资料可以得到些启发，但最终实践后才会真正知道“原来如此”完美的技术。
   最后给大家的忠告是：不要光看资料，马上实践练练！