DTO数据传送对象

前几天学校asp.net实验室招人,去问了下:主要考一些存储结构、触发器.本想进去锻炼下的,但内心的真是想法让我连报名都不想去了. 在数据库里写存储结构、触发器.无异于面对sql语句编程,java只是一个小丑,对象是被sql强奸了的DTO.将

我们在开发系统时,一般VO（或者是PO）对应的是数据库中的表中的记录，view object是提供给客户端显示用的对象，在业务逻辑部分是BO。在很多情况下，我们把VO或者是PO作为了BO，但是在复杂的业务环境中，这种方式的脆弱性就体现出来了，如果我的业务对象比较复杂（具体来说，比如包含了多个

关于暴露业务模型（Exposed Domain Model Pattern） 这个问题涉及到企业应用社区中许多流行了好多年的热门词：POJO，DTO（VO），FAÇADE。这个问题非常复杂，比贫血模型更易引起争论；其中由方法论层面上的问题，也有技术层面的问题，在这里也无法给出全面的分析，那

数据库中有两个表 表1中有A,B两个字段. 表2中有B,C两个字段. B和C关联 现在我想做个类. 把表1和表2的数据关联起来. 如: public Class

web层向业务层，或业务层向web层传递数据时 常使用到的是DTO，如果使用Map怎么样？

这如何理解?DDD我觉得很是能自圆其说的一种设计思想.一直想把的什么失血和贫血,BO,VO,POJO,还有怎么分层跟DDD作一个整合.一些基层框架可以DDD提供服务,比如ibatis,我觉得这些东西如果放在DDD这么一个环境下能很好的解释. 但现在总感觉没突破这一层.

最近看domain model，好像大家都很摈弃失血模型，认为domain object中不能只有getter/setter代码，而应该加入不依赖於持久化的逻辑方法为什么呢？谢谢

不好意思,我不是捣乱,只是概念太多了,弄的我大脑有点儿乱.想请教一下各位. VO 有人说是value object 有人说是view Object ,后者就是对应界面Form属性的.对吗? PO 对应数据库的属性?当然,应该是没有业务逻辑的. DAO 里面应该有一些

在我理解业务对象是一个系统的基础，就像盖房子中的砖头，砖头的形状变了搭建房子的方法也就改变了，同样业务对象的结构改变了，系统的架构和设计也就改变了。所以应该是设计的基础。再来说DTO，字面理解看，data transfer object，数据传输对象，我理解主要是在多层开发的时候，各个层次传

在阅读DDD过程中出现几个疑问：1.值对象到底有什么作用？为什么不把它的值直接设置成为实体的属性呢？2.值对象在数据库映射的时候该怎么处理？当成实体表中的字段？还是单独一张表呢？ 望各们帮我解答下！

我们从数据库中提取数据，才能确定应用程序的执行方式。为了构建最佳的提取计划，我们需要了解每种提取类型。直接获取数据是最简单的，无需编写任何显式SQL查询语句，并且在我们知道实体主键时非常有用。 如何通过通过Spring Data EntityMan

如题.使用POJO产生了什么样的好处?怎么觉得从模型里把方法剥夺了，看起来那么奇怪呢?

大家能详细谈谈DTO、BO和PO吗？从它们三的本身和应用的环境。

快被弄昏了，他们有些什么关系，又应该位于系统的那些层次上面

把表映射成对象，有些时候造成冗余数据的传输，降低了系统性能，特别是在表字段比较多的情况下：比如一个用户表有30个字段，包括地址，描述等 ，但我有一个方法只要用户名列表，用o/r mapping后，一般都是用select * from mytable，造成很多数据根本不要传输的进入了传输，是不是我不应

在《J2EE设计模式》中关于VO的看法，说是为了减少实体Beans在网络上的传输负载，当一个应用程序调用实体Beans的时候，实体Beans把它所得到的数据存放到关联的VO中，然后通过这个VO把数据传给那个应用程序。现在的问题是，我们已经有了会话Beans来作为远程调用的接口，把实体Bean