一些复杂的逻辑该放到service里还是放到对象里？

[小水晶]

我有一个客户类Customer，用于记录客户的基本信息客户名，地址等及存款贷款信息和明细。

存款信息，贷款信息，以及明细都是List，因为里面有很多条。另外还要根据币种计算客户的存款和贷款的余额。但是在数据库中这些信息存放的方式使得我如果用SQL来查出这些信息就必须提供唯一的客户号，但是我有上万的客户要统计，所以数据库返回的是三个List，分别为所有的客户列表，所有客户的存款贷款信息列表，以及所有客户的明细信息列表。

我想到的两种设计：

1）IStmDao负责查询数据库并提供方法返回数据库中的三个List
IStmService提供方法getCustomersList，负责返回一组客户，这些客户的信息都已经设置好，利用DAO得到的三个List，分别按客户号，账号等信息计算出存款信息，贷款信息，明细信息以及多个账号的按币种计算的余额，然后调用Customer对象的set方法，设置这些属性。

Customer类为POJO，用他的属性时就简单的get就可以了，但service的确很复杂。

2）IStmDao仍然做同1的工作
IStmService提供的getCustomersList方法，没有复杂的逻辑，而是设置Customer对象的三个List，其内容就是dao返回的三个List，区别是dao返回的List中是所有的客户，而Service只把其中与某个客户相关的内容组成的list放到对象的属性中。这样Service没有那么复杂，也就是说计算的逻辑不在这里了。

而Customer对象不再是简单的POJO了，有他自己的逻辑，当要得到客户的存款信息时，需要遍历存款、贷款信息表，选出存款信息，并封装好List返回。


其实说简单了，计算的逻辑也不是很多，只是我想看看哪种设计更好，是应该保持简单的POJO做对象，然后有个复杂的service好，还是service相对简单，而对象类有自己的逻辑，因为直观印象这些逻辑的确应该归在对象上。

请大家说说看法，谢谢

[Landor2004]

先不管所谓的贫血不贫血，看设计能力，现在大部分的项目都是放到service里，而且我认为放在service里好管理

放在对象里，需要非常好的设计才能支持的好，否则会变得一团搞糟，无法维护，就等死吧

[临远]

贫血模式是放在service里
充血模式是放在domain里。

PS。我们用的是贫血模式

[tibetjungle]

Martin Fowler在《企业应用架构模式》中对你的疑问有清楚的回答。把逻辑放在Customer对象中，用的是领域模型模式。领域模型模式要求对领域建模，同时规划领域模型之间的关系。狂热的OO爱好者会推荐这种模式。但这种模式对OO技能的要求非常高，处理得不好，理不顺模型之间的关系，就会搞得异常复杂。

把逻辑写在Service里是Martin Fowler说的服务层模式，这个模式也是现在大多数Java开发采用的模式：Customer领域对象做为数据容器，Service处理业务逻辑。一般来说，采用这种方式实现业务逻辑会简单一些。

在OO实践水平还没有达到一定成都时，建议慎用领域模型(把业务逻辑放在Customer对象中)，采用Service分层模式更有利。

另外，觉得lz的ORM做得很混乱。按道理客户、贷款、借款是相互关联的信息，为什么分别加载，到后续才确定三者的关系呢？其实可以从取得客户信息时就加载借款和贷款信息了（呵呵，看你的应用场景，不要考虑延迟加载吧？），这样外层从DAO得到的就是一个封装了客户、借款、贷款信息的Customer对象了。这也是ORM应该做的依赖映射啊。

[Yedy2000]

我都是放service里面