模型、服务或其他地方的方法？答案

【问题标题】：Method in model, service, or elsewhere?模型、服务或其他地方的方法？
【发布时间】：2023-03-31 05:38:02
【问题描述】：

我有一个User 模型。可以审查用户。因此，我还有一个代表用户评论的Review 模型。随着评论，用户的评分被保存。

假设我要创建一个方法，根据用户的所有评论获取用户的评分，例如getRating() 方法。我会在User 模型上创建此方法吗？或者您会创建一个审查管理服务类并将该方法包含在该类中吗？

将getRating() 方法添加到User 模型感觉是一件合乎逻辑的事情，但另一方面事情可能会在某一时刻失控，给我留下一个巨大的User 模型类。

（这是一个简化的示例，实际上评论可以来自多个来源）。

（PS 我已经阅读了一些关于此的帖子和文章，但我找不到满意的答案）。

【问题讨论】：

【解决方案1】：

您不应拥有“User 模型”和“Review 模型”。 MVC 中的模型是您的整个核心应用程序，它包含使您的应用程序工作的所有数据结构、服务、数据库适配器和辅助材料。你应该拥有的是这样的：

一个User 业务对象和一个Review 业务对象，纯粹定义数据结构
UserRepository 或 UserDAO 或 UserORM 或您用来与数据库交互的任何其他范例，它将数据库中的数据转换为 User 对象或从 User 对象转换； Review 相同
UserService 用于处理与用户相关的任务，例如通过数据库接口存储和检索它们，Review 也是如此，或者可能是一些不同名称的服务一起负责两者

并非所有都必须 1:1 映射；一个业务对象实例可以映射到多个数据库表，由相应的*Repository/*DAO/whatever 负责处理，并且其中的多个可以组合成一个服务，从而使有用的事情发生。

检索某些特定数据的操作属于服务。

【讨论】：

我感谢一个很好的解释和简洁的答案，它可以帮助用户对模型层有正确的看法。
同意，但我发现很难删除数据库作为模型的概念。这绝对是编程技能的另一层。
@TimMorton 一旦你尝试过，它实际上会让你的代码变得简单得多，因为每个单独的部分都更简单（如果做得好的话），因为你不再将多个职责混入一个类......跨度>
@deceze 我没有向这些 cmets 发送垃圾邮件，而是发布了一个希望您感兴趣的问题：stackoverflow.com/questions/45120733/…

【解决方案2】：

为什么不将getRating() 添加到Review 模型中。该方法将接受 User 对象或用户 ID，具体取决于方法中的逻辑。用户模型不知道评论。不过我的想法。

【讨论】：

感谢您的回复！这是因为我的例子被简化了。实际上，评论可以来自多个来源，因此不仅链接到Review 模型/数据库记录。
最好创建一个评论服务来处理复杂的逻辑。服务的方法可以接受处理逻辑所需的相关对象。
虽然它唯一需要它的对象是 User 模型。这就是为什么将这些方法从 User 模型转移到服务类感觉如此奇怪的原因——它们只需要有关用户的信息，不如将它们保留在 User 模型中？
我明白你的意思。保留在用户模型中更简单，但实际上由于评论可能是从另一个模型/表或其他来源获取的，我仍然会坚持使用服务。如果该方法将来需要更多对象怎么办？它可能会变得一团糟。
嗯，我也明白你的意思:)。我认为，除非其他人提供另一种见解的答案，否则我会暂时将这些方法保留在 User 模型中，如果需要，我会将它们转移到服务中。