我们有一个 REST 后端，它与模型类一起工作，以便封装 API 调用的数据。目前，我们正在使用相同的模型类将数据映射到数据库中。
因为它节省了将数据从 API 域复制到数据库域的过程，所以这种方法存在一些问题:
- 它引入了安全风险，因为您需要明确屏蔽不允许直接从 API 中设置在数据库中的字段，这很容易忘记。
- API 模型类被不应通过 API 提供的数据库域特定成员“污染”。
- 在不(意外地)更改 API 模型的情况下重构 DB 层变得更加困难。
另一方面，复制时有:
- 返回(大)列表的问题。
- 忘记将(新)属性从 API 域复制到数据库域，反之亦然。
我想知道是否有设计规则说明了这一点。
最佳答案
那么您可以做的是将您的业务实体(您写入数据库的模型)与数据传输对象(即使用 DTO 模式)分开。所以你最终得到的是:
- DTO 只是您的容器，它是来自其余部分的数据
- 读取传入数据、对其进行一些操作并将其转换为实体的业务逻辑，这些实体将通过 DAO 或其他方式在数据库中写入/读取。
- 代表您的数据库模型的模型实体。
通过这种方式，您至少可以实现关注点分离(安全性、API 更改、数据传输)。
现在这就像生活中的一切(除了啤酒 :))都有它的负面影响: 例如，您得到重复的代码(您必须从 dto 中的数据库实体复制模型)，这可能会产生一些开销。
希望对您有所帮助。 不知道您使用的是什么语言，但这是 java 中的一个示例: http://www.oracle.com/technetwork/java/transferobject-139757.html
关于database - 为 DB 模型重用 API 模型的设计规则，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17485445/