Java 从DAO组装域对象的逻辑应该驻留在哪里？

我已经阅读了这里的几乎所有问题和www上的许多相关论点，但我仍然不确定是否能很好地理解这一点，而且可能我错过了一些其他人显而易见的事情，因为我认为这是一种非常普遍的情况

请原谅我糟糕的英语和混淆的术语，但我对DAO和Repository的区别/优点/注意事项并不感兴趣，我认为这不会改变问题的“核心”，但也许我错了

很明显，这个例子太简单了，每个解决方案都很容易被滥用，但请将其视为一个更大系统的“案例”

假设您必须构建一个应用程序来向销售人员推荐要呼叫的人

每个潜在客户都有一些“文本”数据（即姓名、性别、出生日期、地址、电话号码、电子邮件等）、一张照片以及他/她与其他人和供应商互动的一些历史记录

文本数据驻留在Mysql表（person）上，照片位于文件系统中的某个位置，有人已经发布了服务，根据销售人员和每个潜在买家的分数，返回可能有兴趣联系的人员列表

我很可能会得出以下结论：

域对象个人，具有姓名、电话号码、地址、电子邮件和照片。所有属性的setter和getter加上方法getScore（）

两个DAO，一个用于mysql表，一个用于文件系统

获取给定销售人员（应用程序的用户，不在本例范围内）的潜在客户列表的服务

我不清楚的是：

域对象中的方法getScore（）可以直接调用服务层中的服务吗？若否，原因为何

对于来自不同DAO的数据，是否需要单独的DTO

如果是这样，我需要某种管理器或“超级”DAO，它们拥有关于如何组合这两条信息的逻辑（即从mysql DAO获取URI、检索文件、加载图片）？这应该驻留在数据层还是服务层？（在我看来，应该留在数据层，因为它处理的是存储的数据）

管理器或“超级DAO”的输出应该是另一个DTO，或者可以直接是域对象

如果是DTO，我是否需要一个调用manager/super DAO并构建域对象的服务（在这种情况下，我假设该服务将把分数“添加”到域对象中）

---

这是一个清晰的问题，我知道，但我不知道如何设计解决方案。

答案的起点：

我认为

getScore（）

方法应该属于服务而不是域对象

味觉问题

这是我的服务

服务的输出可以是DTO或域对象

简言之（在我看来）

• 域对象是“哑”类（只是在这里用对象映射数据）
• DAO在这里获取数据（就是这样）
• DTO可以用作DAO和服务之间的中介
• 服务在这里执行相关操作（使用dao），例如计算分数

允许从下到上使用，即服务可以使用DAO，但不能反过来使用，以减少更改的可能性（例如：DB backend change=>DAOs updated，仅此而已）

---

=>社区维基

你好，我想知道你的答案，但我还是有点困惑：DAO=访问数据，DO=表示数据，所以不是同一类IMHOAlan，我已经阅读了这篇文章，我同意作者的观点，即贫血模型带来了程序式设计，但这并不是我问题的重点：假设您将所有可以使用的逻辑都放在域对象中，并且仅将服务用于无法轻松还原为特定事务的事务，我仍然不确定将逻辑放入其中以将其自身组装为DAO（顺便说一下，DTO）是不是一个好主意，至少当您有多个DAO时是这样。问题是：我必须分离DTO，并且当它们处于一对一关系时也这样做，而我是否可以/应该扩展DTO以添加逻辑？删除前面的注释，它们由于一个错误而混淆。这是问题的正确版本：DTO和DO是同一个对象吗（可能实现不同的接口或让DO扩展DTO），或者我应该避免这种情况，并始终从服务器从DAO接收的DTO重建DO？同样，DTO是工具（包装器），所以DOs和DTO之间不应该有继承关系。例如，假设您需要一个带有分数（按分数排序）的

人员列表，您可以使用一个DTO（我们称之为
ScoredPerson
），其中包含两个字段
Person
，以及一个
score
，并实现
可比