一些复杂的逻辑该放到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相对简单，而对象类有自己的逻辑，因为直观印象这些逻辑的确应该归在对象上。

请大家说说看法，谢谢

[say___baby]

放在service里面，保持dao和pojo对象的干净，免得以后不好修改

[Doson]

up

[knightzhuwei]

这个好像没什么应该不应该的 也没什么统一说法到底是哪个好
你看着哪个顺眼就哪个呗

[xnjnmn]

－－service的确很复杂。

业务层根据名字就知道，就是这样
Dao和数据库打交到最好不要关联业务，这样修改起来只要修改service层

－－数据库返回的是三个List

不考虑性能斗无所谓

考虑性能问题 ，数据量大数据库层解决用存储过程

利用DAO得到的三个List，分别按客户号，账号等信息计算出存款信息，贷款信息，明细信息以及多个账号的按币种计算的余额－－－－这些斗是关联的吧，存储过程查询JAVA代码理生成一个list专用于你的那个复杂业务