• 我在设计中遇到一个问题！而且我想或许大家也会有类似的困惑，还是我多想了抑或是孤陋寡闻。具体问题如下，简化了分析模型利用ctrl（action）接受客户端提交的请求并分配到不同的DS（DOMAIN SERVICE），然后DS调用BO,BO在调用DAO来完成持久化！粗略地看看是没有太大的问题，耦
  • 我们在开发系统时,一般VO（或者是PO）对应的是数据库中的表中的记录，view object是提供给客户端显示用的对象，在业务逻辑部分是BO。在很多情况下，我们把VO或者是PO作为了BO，但是在复杂的业务环境中，这种方式的脆弱性就体现出来了，如果我的业务对象比较复杂（具体来说，比如包含了多个
  • 通用业务逻辑的提取有没有必要呢？我说的不是验证、权限、UI，而是领域业务中的业务逻辑。 icon
  • BO里的字段总会有各种类型：int、DateTime、string、float、decimal等。最近和个朋友正在架构公司的底层平台，朋友坚持所有的字段都用字符串来表示。小弟我总觉得这样做不妥，和朋友争论了一番。原来正常一个类变了个样： class EmployeeInfo icon
  • 一般来说，一个实体bean表示的是一个表中的某条记录（我的理解），在bang的《EJB/JBOSS实战开发教程》是如此描述：“，CMP可以看成是内存中的数据表。只要对CMP实现数据操作，就相当于对数据表实现操作。见下图，CMP 通过JNDI 和数据表建立Mapping 映射后，所有对CMP的操作，都 icon
  • 数据库中有两个表 表1中有A,B两个字段. 表2中有B,C两个字段. B和C关联 现在我想做个类. 把表1和表2的数据关联起来. 如: public Class icon
  • 这如何理解?DDD我觉得很是能自圆其说的一种设计思想.一直想把的什么失血和贫血,BO,VO,POJO,还有怎么分层跟DDD作一个整合.一些基层框架可以DDD提供服务,比如ibatis,我觉得这些东西如果放在DDD这么一个环境下能很好的解释. 但现在总感觉没突破这一层. icon
  • 在设计一个业务对象的时候，我将业务对象的属性和方法设计完整，可是在实现的时候发现，实现这个业务对象的时候，属性和方法的实现不同，在我看来业务层对于上一层次应该只暴露接口而不暴露实现，那么是否应该将设计的业务对象的方法剥离到接口上去，为业务对象只保留属性。我不知道这样理解对不对？还有个 icon
  • 不好意思,我不是捣乱,只是概念太多了,弄的我大脑有点儿乱.想请教一下各位. VO 有人说是value object 有人说是view Object ,后者就是对应界面Form属性的.对吗? PO 对应数据库的属性?当然,应该是没有业务逻辑的. DAO 里面应该有一些 icon
  • 在我理解业务对象是一个系统的基础，就像盖房子中的砖头，砖头的形状变了搭建房子的方法也就改变了，同样业务对象的结构改变了，系统的架构和设计也就改变了。所以应该是设计的基础。再来说DTO，字面理解看，data transfer object，数据传输对象，我理解主要是在多层开发的时候，各个层次传 icon
  • 大家能详细谈谈DTO、BO和PO吗？从它们三的本身和应用的环境。 icon
  • 快被弄昏了，他们有些什么关系，又应该位于系统的那些层次上面 icon
  • 我很想知道，究竟在什么时候，我们需要EJB能够提供的那种业务对象的分布能力。我知道那是很好的东西，但我希望有人能给我一个需求，一个用得上它的需求。多谢了。 icon
  • 关于购物车当用户向购物车添加一个物品后， 1）立即访问数据库，把物品数量减1（假设用户买了一个），当在最后结帐时，假如用户放弃购买，就再从数据库把物品数量加1。 2）把这个数量（1）保存在session中，在jsp页面显示的物品数量减1，到最后用户结帐时再访问数据 icon