java - 为什么我应该将 repo 级别对象与 Controller /服务级别对象混合？

Question

我从事过许多微服务工作，发现我们没有将 repo 级别对象(mogo 文档、实体)与服务/ Controller 级别请求/响应混合在一起。我想了解更多有关它的信息？1.我们不希望pojo和实体/文档以相同的方式表现？(可能是原因之一)请帮助我理解这样做的原因。

Answer 1

是否需要分离实体(或一般的持久性对象)和公共(public)接口(interface)响应(例如 REST 等)很大程度上取决于您的应用程序设计。

如果您的持久性对象仅包含简单的非敏感数据，则也可以将它们用于公共(public)接口(interface)响应。但这里有一些需要单独对象的场景:

1. 您的持久性对象包含可供外部读取的敏感数据(密码、加密 key 等)。然后，您可以将这些对象转换为其他类型，并剥离该数据以将其隐藏在公共(public)接口(interface)中。

2. 您在持久性对象(实体之间的关系等)中嵌套了引用，这些引用达到非常深的程度，甚至可以形成循环。如果您尝试将它们序列化为传输格式(例如 JSON)，该过程将因循环而失败，或者您的 JSON 对象将会很大。然后，只需包含 ID 或任何内容作为嵌套引用，就可以更轻松地转换对象并删除循环。

在我开发的一些应用程序中，我什至更进一步，选择了三个不同的数据对象层。第一层是持久层，可以是实体、YAML 或 JSON 表示或类似的东西。

由于应用程序使用了很多不同的存储后端，并且支持多个相同的数据，因此我将这些特定对象转换为通用域对象，形成第二层。应用程序本身只对这些域对象起作用，从不触及直接持久化对象。

第三层是装饰器层，我用它来隐藏或简化 REST 接口(interface)上输出的信息。它们用于应对上述两种情况。