请教关于domain对象注入service

在一个domain对象中，
注入相关的service，不知道这样的设计是好还是坏。
因为这个service是这个domain对象的某个行为不可缺少的一部分.

举个例子，
在User这么一个domain对象中，
需要有一个支付这么一个行为，暂时称它为pay
在pay的时候，需要调用相关的service来完成支付的操作.

public class A{
  private PayService payService;
  
  public void pay(){
    payService.doPay(this);
 }
}

不知道这样的设计是否存在问题..
如果有问题的话，又应该如何设计呢.
本人小菜一个，望各位大大不吝赐教

评论

28 楼 marlonyao 2009-01-12  

是可以调用的，且不讨论你举的例子这么调用是不是合适的。在DDD中，Entity和Service实际上是同一层，因此之间有双向依赖没有什么不可的。事务控制并不是在service中控制的，而是单独在Application Service层控制的。

这样做的难点在于hibernate之类的框架不能够注射Service。

27 楼 xiao0556 2009-01-12  

czx566 写道

    依赖顺序最好是从下到上，好像有一条法则~~~

依赖倒置原则　一种设计原则。
减少偶合（最好没有）。
还有很多设计原则　单一职责　保证自己的变化尽量少的传播

26 楼 coolworm 2009-01-12  

请问DOMAIN 对象 是什么？ 我是小菜，能解释一下吗？ 让我也学习一下

25 楼 aidiyuxin 2009-01-12  

兄弟~~你要明白为什么要注入
你注入弄反啦~~完全没有di在里面啊

24 楼 InnocentBoy 2009-01-12  

你完全可以做一个user对象，再做一个userService的对象。这样依赖就没问题了吧！

23 楼 kakac001 2009-01-10  

呵.
本想说对这个问题已经心里有点数了.
没想到居然上了javaeye首页.
谢谢各位的解答.

之前可能没有描述好,再做点补充吧.

为什么要写一个payService：
因为这个PayService还依赖着其他的service.
而这些service与user并没有什么太多的联系，
如果将这些service也一起注入给user.那这个user会让人很头疼.
而且这个PayService里也有一些逻辑，以及事务.
呵，所以有了这个PayService来做个中间层.


to pipilu:

诚然，这个user似乎是承载了太多的功能.
并没有将User细分到这个程度，
算是一个“混血儿”吧  呵

22 楼 wangyugod 2009-01-10  

kakac001 写道

呵 把pay封装到PayService中，pay是作为User的一个行为，至于自己的实现是怎样,
跟User应该没多大关系吧？
主要是因为pay的实现复杂了些些
所以才把它放到一个相应的service中来处理.呵

如果只是实现复杂了些，并不是把它作为一个service的理由，service是提供给Application层或者其他层次使用的；你可以使用一个接口来定义pay这个操作，如PayProcessorInterface，然后注入到User中，这样就可以了，也不需要与service耦合。作为一个domain object，本身应该不会调用到service的东西的

21 楼 wangyugod 2009-01-10  

kakac001 写道

在一个domain对象中，
注入相关的service，不知道这样的设计是好还是坏。
因为这个service是这个domain对象的某个行为不可缺少的一部分.

举个例子，
在User这么一个domain对象中，
需要有一个支付这么一个行为，暂时称它为pay
在pay的时候，需要调用相关的service来完成支付的操作.

public class A{
  private PayService payService;
  
  public void pay(){
    payService.doPay(this);
 }
}

不知道这样的设计是否存在问题..
如果有问题的话，又应该如何设计呢.
本人小菜一个，望各位大大不吝赐教

属于User的行为肯定要定义在User中，但是为什么一定要使用service来实现它的行为呢？Service不是为domain object服务的，domain layer的service是为Application layer服务的。这个service中的doPay除了会被User调用之外难道还会被其他对象调用吗？为什么要定义成为service呢？能说一下你这个Service中的doPay()都做了些什么吗？我认为没有必要定义成为service

20 楼 nextway.cn 2009-01-10  

主要是为了分层，便于理解后后期的维护吧

19 楼 leexhwhy 2009-01-10  

czx566 写道

   我觉得领域对象的方法，应该只涉及到改变自身状态行为

   如果还涉及到其他领域对象的状态改变
 
   那么这个方法都应该放到service中！

   所以就楼主的例子来说：
 
   pay 一般来讲 都至少应该涉及到 支付方 和 接受方 两个领域 对象的， 那么pay方法放在   service层是必须的！

    那么如果我假设 楼主 你 的系统 只关心把钱付出去了，对于之外的事情你系统不毫不关心，那么此时你把pay方法放在user中也不无不可，并指定自己的事务规则，不过建议这个时候你改变你的方法名：deduct 这样更为合理。

   那么我又假设，如果有一天你的系统升级了，要求关心 这个钱 的去向或则至少
要记录一下，那么deduct你就应该建立一个payServcice,里面有领域对象的deduct的调用和 其他的调用，当然也包括事务的设置。

     

同意楼上的说法，建议去看看《POJO in Action》,上面讲的很清楚，关于对象自身状态的改变，应该是本对象负责，有关集合操作或者其他，还是在service中

18 楼 czx566 2009-01-10  

   我觉得领域对象的方法，应该只涉及到改变自身状态行为

   如果还涉及到其他领域对象的状态改变
 
   那么这个方法都应该放到service中！

   所以就楼主的例子来说：
 
   pay 一般来讲 都至少应该涉及到 支付方 和 接受方 两个领域 对象的， 那么pay方法放在   service层是必须的！

    那么如果我假设 楼主 你 的系统 只关心把钱付出去了，对于之外的事情你系统不毫不关心，那么此时你把pay方法放在user中也不无不可，并指定自己的事务规则，不过建议这个时候你改变你的方法名：deduct 这样更为合理。

   那么我又假设，如果有一天你的系统升级了，要求关心 这个钱 的去向或则至少
要记录一下，那么deduct你就应该建立一个payServcice,里面有领域对象的deduct的调用和 其他的调用，当然也包括事务的设置。

     

17 楼 pipilu 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来用，还是打算当作付帐机器人来用？或者是专管缴费的公司行政人员？
   

16 楼 kakac001 2009-01-10  

pipilu 写道

楼主你说的：

引用

原本是想说pay作为User的一个行为，会更oo一些.

既然这么认为，那你又为什么把pay封装到PayService中呢？？跟你的说法不矛盾么？

呵 把pay封装到PayService中，pay是作为User的一个行为，至于自己的实现是怎样,
跟User应该没多大关系吧？
主要是因为pay的实现复杂了些些
所以才把它放到一个相应的service中来处理.呵

pipilu 写道

    奇怪！怎么更oo了呢？？？所谓的面向对象，并不是从概念上说这个对象有什么属性或行为，就都要封装到这个对象里。这是对面向对象错误的理解。主要取决这个对象要怎么用！
    举例说，比如正方形这个类，如果我们使用它的目的是计算面积，那它的父类就是平行四边形，可以把它看作是平行四边形的派生。而如果你只是用来表示图形，那它应该是多边形的子类。

    系统就是给客户（User）用的，如果按你那种思路来封装对象，一个User就够了（登录、付帐、管理系统配置、上传文件、修改记录等等）

真心请教下.关于我对面向对象的错误理解，能否另外举个例子呢？
这个例子我没能明白..thx


哈，是呀，理论上来说是需要一个User就够了，
但是也就是这样充血，会导致太多的耦合.呵

15 楼 pipilu 2009-01-10  

楼主你说的：

引用

原本是想说pay作为User的一个行为，会更oo一些.

既然这么认为，那你又为什么把pay封装到PayService中呢？？跟你的说法不矛盾么？

    奇怪！怎么更oo了呢？？？所谓的面向对象，并不是从概念上说这个对象有什么属性或行为，就都要封装到这个对象里。这是对面向对象错误的理解。主要取决这个对象要怎么用！
    举例说，比如正方形这个类，如果我们使用它的目的是计算面积，那它的父类就是平行四边形，可以把它看作是平行四边形的派生。而如果你只是用来表示图形，那它应该是多边形的子类。

    系统就是给客户（User）用的，如果按你那种思路来封装对象，一个User就够了（登录、付帐、管理系统配置、上传文件、修改记录等等）
   

14 楼 kakac001 2009-01-10  

抛出异常的爱 写道

当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时
125种组合......
人的脑子一般是思考不过来的.
用domain封来封去....事务,边际变模糊了.......
最后都放到action里去作事务.

呵.貌似大部分人都推荐用单纯的service来做.
原本是想说pay作为User的一个行为，会更oo一些.

昨天也有就这个问题请教了下一位牛人.
是这样的看法，这个问题目前没有一个绝对的准则来说是好是坏，
各有利弊，需要自己去权衡.
作为他本人，他也是比较不倾向于充血.
也正如异常这边说的，这样的耦合性大了许多.
之后可能不好控制

呵..谢谢大家了..

13 楼 samm 2009-01-09  

抛出异常的爱 写道

当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时
125种组合......
人的脑子一般是思考不过来的.
用domain封来封去....事务,边际变模糊了.......
最后都放到action里去作事务.

额，想请教下，你一般事务是怎么放的？
我的想法是一个事务对应了service的一个方法。这样就可以在service做事务控制了。

12 楼 抛出异常的爱 2009-01-09  

当一个业务逻辑包含了N个表,N个DAO,N个逻辑关系
N大于5时
125种组合......
人的脑子一般是思考不过来的.
用domain封来封去....事务,边际变模糊了.......
最后都放到action里去作事务.

11 楼 alexma 2009-01-09  

对于经验少的新手来说，纯贫血模型是最简单，最不容易出错的。

10 楼 jansel 2009-01-09  

两种对象模型，一种是充血的模型，一种是贫血的模型。

贫血的仅仅做数据的承载，不做逻辑；

而充血既做承载也做逻辑。

9 楼 kakac001 2009-01-09  

嗯.了解了. thx

题外话..这些“法则”有哪里有专门的介绍吗？