struts转到webwork

很好的一个回复，我转录如下：
作者：动物园的猪
PO ,persistence object,
VO,value object
dto,data transfer object
bo,business object

好多的名词啊，晕！

我们开始也是这样做的，拿到hibernate的po，就一股脑的扔给view(jsp)显示去

了，不好，俺知道，确实不好。

后来，俺们这样做了：用beanutil把po的各个属性值拷贝给了FormBean，让formb

ean去跟view打交道。

再后来，俺们觉得，action不应该直接就调用dao，俺们加了一个BusinessFacade
action---->facade--->dao
action把formbean的值转到po，然后交给facade,facade再调用dao

再后来，俺们觉得，还是martinFlower的domain

model更酷一些，俺们就把buinessFacade重构成了一个Biz对象，他是一个业务实

体，他有着和po差不多该有的属性，用来存放业务值，但是他也有着同样的各种

业务方法，他已经不再是一个facade了，而是一个facade+PO了，我们叫他真正的

业务对象。他有几个职责：接受web层数据；加工数据；持续化数据（不是自己做

，是调用dao）.

你们看，多么曲折的系统重构历程啊，可是，就是这样，俺们仍然感到很多很多

的不足，因为，这个Biz对象，还是只能代表一个对象，而不太好表现一个对象图

（就是他和别的对象的关系），太抽象，是吧？

举个例子吧：

俺们有一个账户业务对象：AccountBiz

他有一些属性：
代码:
String guid;
String name;
String password;


他还有一些方法：
代码:
findHisRoles();
load();


我在action中,这样调用他
代码:
biz = new AccountBiz("guid");
biz.load();
List roles = biz.findHisRoles();


你看，他找到了他的所拥有的所有角色，可是，你想想，roles里面是什么？理想的是：RoleBiz,你知道的，业务层，应该看到的都是业务层的对象，可是呢，实际上，这个方法的实现是：
代码:
public List findHisRoles(){
  return dao.findHisRoles(this.getGuid());
}
看看，实际上，返回的是一堆AccountPO的实例，我是不是应该把这些PO，一个个的都转化成Biz呢，我们现在没有做，看来是应该做的。

但是，如此做的话，实际上，你的业务层的对象看来就真的变成了，hibernate还原出来的对象图+这个业务实体的业务方法。

嗯，这就是俺们的结论，这样实现固然很好，看上去很美，但是，对于中小项目而言，使用po直接的贯穿始终，俺们觉得也挺好的。

嗯，跟贴吧，拍砖吧

确实存在这样的问题。楼主的问题很有共性。建议有同感的兄弟们看到后都帮忙顶顶。让有经验的兄弟们说说。。。。。。

其实，大家也不要为这些东西争论了，是该安静下来学习学习了，多去看看老马的《企业架构模式》吧，中文版刚刚拿到手，希望和大家一起研读。

另外，我们做企业应用的兄弟们，有谁常常关注与业务建模呢？我十分想了解几个对某一个领域的业务建模的实例，能给出一个你的建模和思考过程，然后大家来评述一些，会让更多的人感觉收益的。

只要实用就好，这是MartinFowler大叔说的。

每种模式都有各自的优缺点，又何必那么教条，非一定要怎样怎样才好呢。

:mrgreen: ，顶一下！

终于找到一个和我观点一致了。讨论好坏没有意思。找到每个技术的适用领域才更加实用。也能起到了抛砖引玉的作用。

为什么要转到WebWork呀，WebWork只是用了Velocity的引擎。Velocity也有提供给Struts的工具呀，可以同时在表示层显示Velocity模板和Jsp文件。

]
地球人都知道webwork的视图可以选择jsp，velocity，freemarker，jaspereport，xslt等等。

在我觉得WebWrok,在J2EE Web框架的领域,它确实能给你带来很多生产率的提供,它基本上是J2EE Web框架的顶峰了(不包括展现层).任何技术,你没有切身体会,没有在实践中使用过,希望不要妄加评论.一个人是要为自己说的话负责任的!