只显示主题贴

2006-03-16
全文显示

为什么我的程序传递DTO

关于Service层是传递DTO还是PO到表示层的争论，由来已久。但都没有定论。 现在，我要在传递DTO方式这边，加上一些砝码，使得天平倾斜过来。 传递DTO模式有以下优点： 1.DTO和DomainObject是不同视角下的产物，它们通过Assembler相互转换。这样，DTO和DomainObject就可以独立变化。DomainObject的内部结构变化不会影响表示层代码。 2.由于Service接口，依赖DTO来定义，所以Service接口，也不会因为DomainObject的变化而改变。进而,Service接口将不依赖DomainObject的lazy load。本来Service接口 ...
  • 进入论坛 Java 版
2005-11-08
全文显示

关于用户故事这件事

重新开个新帖： 最进一直在研究用户故事，有些心得同大家交流下，欢迎排砖： 我认为用户故事同用例最大的区别在于： 使用的方式 用例被看作需求的主要成果，用来作为设计，实现，测试的前置条件。并且作为工件在项目中需要保留。 相反 用户故事作为获取需求的开始，起到提纲的作用，最初的用户故事，可看作将要满足的功能的站位符，提醒我们有这么回事。 在UP中你会看到：有特性和用例的区别。 在XP中只有用户故事。 这样用户故事势必会跨越更大的描述空间，也就是说它可以象特性那样粗，也可以象用例关注的那样细，这是通过epic做到的。 还有用户故事既然叫“用户故事”，那么它至少是用户能看得懂的故事。 也就是说对开 ...
2004-12-21
全文显示

Domain Model 探索

一直想系统的整理一下自己有关Domain Model实践的尝试。但总觉得自己的想法还不够系统而作罢。 然而从另一方面看“系统的东西”也许永远做不到，失去了目标的生活该会多乏味。 因此我决定将自己有关Domain Model设计的有关实践和思考和盘托出，也算是抛砖引玉。欢迎大家 参与讨论，遇到同你的观点相左的地方，希望能以包容的态度来面对，我们是朝同一方向走的伙伴而不是 相互对视的敌人。：） 在深入讨论之前我先抛出一些原则和概念，最后你会看到这些概念和原则的威力。 1.按照概念依赖的原则来组织业务层。 2.将业务活动（业务流程）建模成类。 3.用业务活动（业务流程）作为关联整个业务层各种对象的 ...
  • 进入论坛 Java 版
partech
搜索本博客
最近加入圈子
存档
最新评论
评论排行榜