讨论：多层架构中是不是绝对不能把PO传递到表现层？

教训的是，，其实设计上不是我的事，当时我在实现的时候就觉得很慢，后来上面果然变更了^_^

大家看过spring 的jpetstore 的例子吗？
里面一是使用ibatis 的po(org.springframework.samples.jpetstore.domain 包）
还有就是Command object（spring mvc中的概念)  org.springfamework.samples.web.spring 包）
如果说是dto 是service 层传给表示层的话，那这个例子中没有dto,最应该使用dto的service都是直接使用domain object(看org.springframework.samples.jpetstore.service)
command object 是一个数据绑定对象，也可以说是接近dto的东西

在这个例子中command object只是域对象的一层简单包装

如

public class AccountForm
{
	private Account account;

	public AccountForm(Account account);
	{
		this.account=account;
		...	
	}
	.....
}

在view中，使用jstl直接使用Account 域对象


${accountForm.account.name}

大家对这个怎么看?

这应该说是个很无聊的设计，一个类很简单地包装了另一个类，有什么意思？

一个po，如区域,它有上级区域，一般我们这样表示

public class AreaForm
{
	private Area parent;
	public Area getParent();{
		return this.parent;
	}
	public void setParent(Area area);{
		this.parent=area;
	}
}

而不是直接用parentId


在spring的mvc模式中，parent这个属性很难被视图绑定，而绑定parentId属性则很自然(虽然parent也可以通过注册PropertyEditor来转换)

<spring:bind path="areaForm.parentId">
	<select name="${status.expression}">
		<c:forEach var="area" items="areas">
			<option value="${area.id}"
				<c:if test="${area.id==status.value} >
				selected
				</c:if>>${area.name}
		</c:forEach>
	</select>
</spring>

在spring 中,绑定view的是command object,很多任务原来的po都可以完成，但像上一个任务，或

是像用户注册时需要重复口令，介面可能在新增和更新下共用，需要在原来的po上增加一些功能，推测因此有了

像AccountForm这样的对象存在


对java 我是新手，不知道这样的理解对不对

对你的说法表示怀疑。我对spring不甚了解，但从ActionForm取名来讲，应该是对页面表单的抽象就像struts一样。spring应该不会限制要用Form结尾的最为ActionForm，所以直接用po应该没有问题。

XANDA说，我会盖房子，但是如果现在需要我去盖狗屋，那我就可以用盖狗屋的方法。凤午凰扬说，你都已经盖了那么多年的房子了，所以即使现在盖狗屋也应该用盖房子的方法。

呵呵，我从来没有说盖个狗屋需要盖成房子样，相反我赞成根据实际情况处理。不过，呵呵，可以拉盖狗屋来讨论建筑学的结构么？楼上说呢？
   楼上很有趣的比喻，不过搞错了意思，呵呵。

好长的贴子，看的眼花啦。
大家都把自己的经验拿出来分享，这种精神值得称赞。
狗屋和高楼是个很有意思的比喻，我们不应该拒绝学习盖高楼的方法，但我们盖狗屋时候也不能忽略狗屋和高楼之间的需求差异。
对于楼主的问题，除非简单的测试代码，我觉得一杆子到底终非良策。还是给po一个自由的空间为好，小项目也是项目，拿人家money，需求就是会变化的:(  ，多一些vo对象开销，换来的长期的便利。

补充一下，我也不喜欢那些反反复复倒来倒去的二传手。但vo和po的关系应该不在此列。

我还是没搞懂VO存在的意义，在我下载的一些国外的应用程序代码中也没有看到有VO的应用。他们通常用的是包名是domain或pojos，没有VO或DTO。

而这个讨论中有关使用VO能带来的好处至今也没有人列举出来，前面凤舞凰扬列举了一个，但并不说明问题。

我所想到的DTO能够用的场合:
在表现层需要一个由多表合并的数据的时候。

但这并不是前面提到的对PO的简单clone，如果是简单的clone，我还是觉得没有任何意义。

:D 讨论真是激烈啊
偶只讨论具体的问题，在struts和hibernate结合的项目中，我们传递的方式是这样的：
   Form->  ConvertToModel  Model->                     Model->
jsp-----------------action-------------------------service----------------dao
     <-Form(s) ConvertToForm <-Model(s)                  <-Model(s)

model就是一个pojo，没有任何的持久化代码，个人认为在model中没有必要加入持久化代码，觉得user.save(); 和 dao.save(user)没有太大的区别。
实际上在这种传递的过程中只需要进行一次Form<->Model的相互转换。
在Form中如果存在其他的引用，我们也会将引用的Model转换成Form，除了Collection中的Model。不过，针对Hibernate的LazyInitException我们在ConvertToForm的时候做了特殊的处理，因为做一个通用的deeply copy的方法一定会访问到所以的getters，如果碰到抛出了LazyException我们就会catch住不作处理。我们的Form和Model之间遵循一定的命名规范，方便在框架中自动进行属性copy。