通用业务逻辑的提取有没有必要呢？我说的不是验证、权限、UI，而是领域业务中的业务逻辑。.

这如何理解?DDD我觉得很是能自圆其说的一种设计思想.一直想把的什么失血和贫血,BO,VO,POJO,还有怎么分层跟DDD作一个整合.一些基层框架可以DDD提供服务,比如ibatis,我觉得这.

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

在设计一个业务对象的时候，我将业务对象的属性和方法设计完整，可是在实现的时候发现，实现这个业务对象的时候，属性和方法的实现不同，在我看来业务层对于上一层次应该只暴露接口而不暴露实现，那么是否应该将设计.

在我理解业务对象是一个系统的基础，就像盖房子中的砖头，砖头的形状变了搭建房子的方法也就改变了，同样业务对象的结构改变了，系统的架构和设计也就改变了。所以应该是设计的基础。再来说DTO，字面理解看，da.

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

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

不好意思,我不是捣乱,只是概念太多了,弄的我大脑有点儿乱.想请教一下各位. VO 有人说是value object 有人说是view Object ,后者就是对应界面Form属性的.对吗? P.

我在设计中遇到一个问题！而且我想或许大家也会有类似的困惑，还是我多想了抑或是孤陋寡闻。具体问题如下，简化了分析模型利用ctrl（action）接受客户端提交的请求并分配到不同的DS（DOMAIN SE.

BO里的字段总会有各种类型：int、DateTime、string、float、decimal等。最近和个朋友正在架构公司的底层平台，朋友坚持所有的字段都用字符串来表示。小弟我总觉得这样做不妥.

关于购物车当用户向购物车添加一个物品后， 1）立即访问数据库，把物品数量减1（假设用户买了一个），当在最后结帐时，假如用户放弃购买，就再从数据库把物品数量加1。 2）把这个数量（1）保存在.

我们在开发系统时,一般VO（或者是PO）对应的是数据库中的表中的记录，view object是提供给客户端显示用的对象，在业务逻辑部分是BO。在很多情况下，我们把VO或者是PO作为了BO，但是在复杂的.

我很想知道，究竟在什么时候，我们需要EJB能够提供的那种业务对象的分布能力。我知道那是很好的东西，但我希望有人能给我一个需求，一个用得上它的需求。多谢了。.