|
锁定老帖子 主题：请教关于domain对象注入service
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-09
两种对象模型，一种是充血的模型，一种是贫血的模型。
贫血的仅仅做数据的承载，不做逻辑； 而充血既做承载也做逻辑。 |
| 返回顶楼 | |
|
发表时间：2009-01-09
对于经验少的新手来说，纯贫血模型是最简单，最不容易出错的。
|
| 返回顶楼 | |
|
发表时间：2009-01-09
当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时 125种组合...... 人的脑子一般是思考不过来的. 用domain封来封去....事务,边际变模糊了....... 最后都放到action里去作事务. |
| 返回顶楼 | |
|
发表时间：2009-01-09
抛出异常的爱 写道 当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时 125种组合...... 人的脑子一般是思考不过来的. 用domain封来封去....事务,边际变模糊了....... 最后都放到action里去作事务. 额，想请教下，你一般事务是怎么放的？ 我的想法是一个事务对应了service的一个方法。这样就可以在service做事务控制了。 |
| 返回顶楼 | |
|
发表时间：2009-01-10
抛出异常的爱 写道 当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时 125种组合...... 人的脑子一般是思考不过来的. 用domain封来封去....事务,边际变模糊了....... 最后都放到action里去作事务. 呵.貌似大部分人都推荐用单纯的service来做. 原本是想说pay作为User的一个行为，会更oo一些. 昨天也有就这个问题请教了下一位牛人. 是这样的看法，这个问题目前没有一个绝对的准则来说是好是坏， 各有利弊，需要自己去权衡. 作为他本人，他也是比较不倾向于充血. 也正如异常这边说的，这样的耦合性大了许多. 之后可能不好控制 呵..谢谢大家了.. |
| 返回顶楼 | |
|
发表时间：2009-01-10
最后修改：2009-01-10
楼主你说的：
引用 原本是想说pay作为User的一个行为，会更oo一些.
既然这么认为，那你又为什么把pay封装到PayService中呢？？跟你的说法不矛盾么？ 奇怪！怎么更oo了呢？？？所谓的面向对象，并不是从概念上说这个对象有什么属性或行为，就都要封装到这个对象里。这是对面向对象错误的理解。主要取决这个对象要怎么用！ 举例说，比如正方形这个类，如果我们使用它的目的是计算面积，那它的父类就是平行四边形，可以把它看作是平行四边形的派生。而如果你只是用来表示图形，那它应该是多边形的子类。 系统就是给客户（User）用的，如果按你那种思路来封装对象，一个User就够了（登录、付帐、管理系统配置、上传文件、修改记录等等） |
| 返回顶楼 | |
|
发表时间：2009-01-10
pipilu 写道 楼主你说的：
引用 原本是想说pay作为User的一个行为，会更oo一些.
既然这么认为，那你又为什么把pay封装到PayService中呢？？跟你的说法不矛盾么？ 呵 把pay封装到PayService中，pay是作为User的一个行为，至于自己的实现是怎样, 跟User应该没多大关系吧？ 主要是因为pay的实现复杂了些些 所以才把它放到一个相应的service中来处理.呵 pipilu 写道 奇怪！怎么更oo了呢？？？所谓的面向对象，并不是从概念上说这个对象有什么属性或行为，就都要封装到这个对象里。这是对面向对象错误的理解。主要取决这个对象要怎么用！ 举例说，比如正方形这个类，如果我们使用它的目的是计算面积，那它的父类就是平行四边形，可以把它看作是平行四边形的派生。而如果你只是用来表示图形，那它应该是多边形的子类。 系统就是给客户（User）用的，如果按你那种思路来封装对象，一个User就够了（登录、付帐、管理系统配置、上传文件、修改记录等等） 真心请教下.关于我对面向对象的错误理解，能否另外举个例子呢？ 这个例子我没能明白..thx 哈，是呀，理论上来说是需要一个User就够了， 但是也就是这样充血，会导致太多的耦合.呵 |
| 返回顶楼 | |
|
发表时间：2009-01-10
最后修改：2009-01-10
kakac001 写道 pipilu 写道 楼主你说的：
引用 原本是想说pay作为User的一个行为，会更oo一些.
既然这么认为，那你又为什么把pay封装到PayService中呢？？跟你的说法不矛盾么？ 呵 把pay封装到PayService中，pay是作为User的一个行为，至于自己的实现是怎样, 跟User应该没多大关系吧？ 主要是因为pay的实现复杂了些些 所以才把它放到一个相应的service中来处理.呵 pipilu 写道 奇怪！怎么更oo了呢？？？所谓的面向对象，并不是从概念上说这个对象有什么属性或行为，就都要封装到这个对象里。这是对面向对象错误的理解。主要取决这个对象要怎么用！ 举例说，比如正方形这个类，如果我们使用它的目的是计算面积，那它的父类就是平行四边形，可以把它看作是平行四边形的派生。而如果你只是用来表示图形，那它应该是多边形的子类。 系统就是给客户（User）用的，如果按你那种思路来封装对象，一个User就够了（登录、付帐、管理系统配置、上传文件、修改记录等等） 真心请教下.关于我对面向对象的错误理解，能否另外举个例子呢？ 这个例子我没能明白..thx 哈，是呀，理论上来说是需要一个User就够了， 但是也就是这样充血，会导致太多的耦合.呵 呵呵，其实这个问题，如果从依赖性或耦合程度上来解释，肯定很容易给出结论。 但我只是想从面向对象的设计上说一说（因为你是从面向对象的角度来提出那个想法的） 你的那个PayService应该不是一个通用的工具类（跟业务无关，处于依赖关系的最下游）。如果pay被划分为User的形为，那么就在User里封装好了，不要再在PayService里也可以pay——使用PayService的pay和使用User的pay有什么区别么？？莫非，业务以后可能有这样的扩展：通过User来pay时，会有一些额外的处理（pay前或pay后）？？如果不是，为什么它俩职责一样，却在不同的类里呢？ 根据使用来划分对象，我记得以前看书，书上讲面向对象时，总是举动物的例子：动物，子类是哺乳动物，哺乳动物子类有猫，而猫又分为黑猫和白猫。那我就以猫为例来说明吧。 如果我们买猫是作为宠物的，那我们肯定关心它的：毛色、品种及是不是纯种、打没打疫苗、擅不擅长滚线球。 而如果我们买猫是为了吃肉（罪过，，我有一次问一个瑞典女孩儿她对中国的印象，她说：They eat their cats and dogs），那我们更关心是老猫还是小猫（枚举类型）、公母、重量。 这样在你的程序里，如果猫是作为食物的，那毛色和会不会滚线球就不是Cat这个类的属性了。抓耗子也不会是Cat的成员函数了（虽然抓耗子是猫的一个行为，但不是你用这个猫的目的） 那个User你打算怎么用呢？？你是打算把它当作UserInfo来用，还是打算当作付帐机器人来用？或者是专管缴费的公司行政人员？ |
| 返回顶楼 | |
|
发表时间：2009-01-10
我觉得领域对象的方法，应该只涉及到改变自身状态行为
如果还涉及到其他领域对象的状态改变 那么这个方法都应该放到service中！ 所以就楼主的例子来说： pay 一般来讲 都至少应该涉及到 支付方 和 接受方 两个领域 对象的， 那么pay方法放在 service层是必须的！ 那么如果我假设 楼主 你 的系统 只关心把钱付出去了，对于之外的事情你系统不毫不关心，那么此时你把pay方法放在user中也不无不可，并指定自己的事务规则，不过建议这个时候你改变你的方法名：deduct 这样更为合理。 那么我又假设，如果有一天你的系统升级了，要求关心 这个钱 的去向或则至少 要记录一下，那么deduct你就应该建立一个payServcice,里面有领域对象的deduct的调用和 其他的调用，当然也包括事务的设置。 |
| 返回顶楼 | |
|
发表时间：2009-01-10
最后修改：2009-01-10
czx566 写道 我觉得领域对象的方法，应该只涉及到改变自身状态行为
如果还涉及到其他领域对象的状态改变 那么这个方法都应该放到service中！ 所以就楼主的例子来说： pay 一般来讲 都至少应该涉及到 支付方 和 接受方 两个领域 对象的， 那么pay方法放在 service层是必须的！ 那么如果我假设 楼主 你 的系统 只关心把钱付出去了，对于之外的事情你系统不毫不关心，那么此时你把pay方法放在user中也不无不可，并指定自己的事务规则，不过建议这个时候你改变你的方法名：deduct 这样更为合理。 那么我又假设，如果有一天你的系统升级了，要求关心 这个钱 的去向或则至少 要记录一下，那么deduct你就应该建立一个payServcice,里面有领域对象的deduct的调用和 其他的调用，当然也包括事务的设置。 同意楼上的说法，建议去看看《POJO in Action》,上面讲的很清楚，关于对象自身状态的改变，应该是本对象负责，有关集合操作或者其他，还是在service中 |
| 返回顶楼 | |
