|
锁定老帖子 主题：是否应该让实体类具备丰富的业务逻辑？
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2005-03-24
引用 引用: item.getPrice()*getBuyer().getDiscount(); 这是非常糟糕，也是非常常见的Bad Smell！它有个名字叫“train wreck”。请注意不要与陌生人讲话原则。 请问：public countPrice（）不是order 本身的职责 应该属于谁的职责？在同一个层次内的类不相互相互协作，非得通过上级（上个层次来讲话么） （有个小小的问题 ） 引用 也是非常常见的Bad Smell！它有个名字叫“train wreck”。请注意不要与陌生人讲话原则。 “train wreck”这个名词好像来自敏捷开发。。但是有个奇怪的现象敏捷提倡的是组织内部非正式的交流，而不是通过严格的组织结构，上传下达来写作的，这位fans打着敏捷的旗号：做的却是层年内部不要多交流的，让上级来协调的事。有点讽刺意味。 |
| 返回顶楼 | |
|
发表时间：2005-03-24
andyyehoo 写道 [quote="frankensteinlin
Class Order{
public countPrice{
Items item =getItems();;
while (....);{
item.getPrice();*getBuyer();.getDiscount();;
}
}
}
如果用service+dao+*类型1*的对象该如何写？可能会非常复杂哦 这个是血小板比较多的Domain Object，而且只是涉及到Domain之间的交互，不会和什么数据库打交道的，我们有时候也会用这种小技巧，毕竟原则是死的，人是活的。不过还是还是写为getCountPrice()比较好吧，这样上层调用起来统一一些。
Class Order{
public countPrice{
Items item =getItems();; //need access db
while (....);{
item.getPrice();*getBuyer();.getDiscount();;//need access db
}
}
}
|
| 返回顶楼 | |
|
发表时间：2005-03-24
frankensteinlin 写道
Class Order{
public countPrice{
Items item =getItems();; //need access db
while (....);{
item.getPrice();*getBuyer();.getDiscount();;//need access db
}
}
}
为何需要访问数据库？Order对象整个从数据库Load出来的时候，这些属性都已经有了，item如果没有lazy=false的话会报错，不过这个是另外一码事了。 |
| 返回顶楼 | |
|
发表时间：2005-03-24
frankensteinlin 写道 引用 引用: item.getPrice()*getBuyer().getDiscount(); 这是非常糟糕，也是非常常见的Bad Smell！它有个名字叫“train wreck”。请注意不要与陌生人讲话原则。 请问：public countPrice（）不是order 本身的职责 应该属于谁的职责？在同一个层次内的类不相互相互协作，非得通过上级（上个层次来讲话么） （有个小小的问题 ） 引用 也是非常常见的Bad Smell！它有个名字叫“train wreck”。请注意不要与陌生人讲话原则。 “train wreck”这个名词好像来自敏捷开发。。但是有个奇怪的现象敏捷提倡的是组织内部非正式的交流，而不是通过严格的组织结构，上传下达来写作的，这位fans打着敏捷的旗号：做的却是层年内部不要多交流的，让上级来协调的事。有点讽刺意味。 这样做看起来简单，但是耦合性太强了。这一长串类中只要有一个需要改变，你就Over了！要限制类与外界通信的广度和宽度是个基本常识。当然如果这样做导致了大量的委托同样也是种Bad Smell，所以才需要你的智慧来权衡嘛。 不明白怎么就扯到敏捷上去了，但我认为敏捷组织没有上下级，更多的是协作关系。 |
| 返回顶楼 | |
|
发表时间：2005-03-24
andyyehoo 写道 为何需要访问数据库？Order对象整个从数据库Load出来的时候，这些属性都已经有了，item如果没有lazy=false的话会报错，不过这个是另外一码事了。 那你把整个关于order的对象树全load出来？内的内存足够大，我也只能说佩服了！ |
| 返回顶楼 | |
|
发表时间：2005-03-24
robbin 写道 To jackyz:
我认为按照Martin大叔的模型，就是这样得到的： Forum f = Forum.findById(forumId);; 我认为还是 Forum f =（new forum（））.findById(forumId);比较好。 其实这个和用dao 构造差不多forumDAO.findById(forumId);前者将dao隐藏起来，用起来更方便 |
| 返回顶楼 | |
|
发表时间：2005-03-24
partech 写道 robbin 写道 我认为Martin Fowler的Domain Object并不光包括你说的自身数据的业务逻辑，也包括你所说的外部的有持久化的服务。我想知道的就是这种Domain Object有什么好处。 那是你理解错误。 Martin Fowler并没有这样的观点。不说你了，仔细阅读大师的书，好处多多。  经过仔细查阅Martin Fowler的POEAA，partech的说法是准确的，Martin Fowler的Domain Object只包含和自身状态有关的逻辑，准确的说叫做"domain logic"，并不包括和其他domain object互相协作的逻辑，也不包括由外部动作触发的workflow logic，类似 loadXXXByPrimaryKey, addXXX, updateXXX统统属于业务逻辑对象，不应该放在domain object中。 |
| 返回顶楼 | |
|
发表时间：2005-03-24
看了这么长的帖子有点晕
关于实体类啊，我是这么理解的，掉电后能让你捶胸顿足的对象，就是实体，也就是实体类的的实例——状态保持；要是掉电后，死不足惜，重启后立马再现的对象，就是非实体——无状态对象。这里其实就是个数据是保存在代码外还是代码中的差别。 业务逻辑？这个太抽象了，不过就是一组操作，可以把它当函数理解，但有些操作不是一步就能完成的，这样肯定需要一些属性去记录状态，这也就需要对象而不仅仅是函数了，但这种状态保持，和实体的状态保持在意义上有所不同。 这里还有个hibernate的影响，由于hibernate的存在，从数据库里取数据的脏活，从代码中移到xml文件中去了——代码也就变成配置了(hibernate把xml描述的schema转换成sql)。 实体类是否应该具备丰富的业务逻辑？不，它只要管好自己就可以了——掉电后回来还能回复原样 |
| 返回顶楼 | |
|
发表时间：2005-03-24
frankensteinlin 写道 andyyehoo 写道 为何需要访问数据库？Order对象整个从数据库Load出来的时候，这些属性都已经有了，item如果没有lazy=false的话会报错，不过这个是另外一码事了。 那你把整个关于order的对象树全load出来？内的内存足够大，我也只能说佩服了！ 这个不是讨论重点，无论你在哪一层计算，都要把items装载进来，迟早问题而已 |
| 返回顶楼 | |
|
发表时间：2005-03-25
我基本同意robbin的，但是我很想同意第二种方案。因为这是我们一直在思考和在这个版面争论不休的。
我觉得同意第二种的人，请拿出一个实际的足够复杂的项目实现来，在我的项目经验中，采用第二种方案，到业务非常复杂的时候，往往会出现，你们所谓的domain object调用manage,而manage有反过来调用dao来持久domain object，这样一个循环让人感觉非常的不爽(特别是逻辑非常繁多的时候），所以，请支持第二种方案的人拿出足够复杂和实现的非常完善的项目证据，不要举那些简单的例子了，和做一些无谓的争吵了，完全没有价值，我们在这个问题上已经浪费了太多的口水。 |
| 返回顶楼 | |
