数据库模型重用API模型的设计规则

Question

我们有一个REST后端，它使用模型类来封装API调用的数据。此时，我们使用相同的模型类将数据映射到DB中。

在将数据从API域复制到DB域中时，这种方法存在一些问题：

• 它引入了安全风险，因为您需要显式地屏蔽不允许直接从API在DB中设置的关闭字段，这很容易忘记。
• API模型类是使用特定于DB域的成员“轮询”的，这些成员不应该在API上得到服务。
• 在不更改(意外) API模型的情况下，重构DB层变得更加困难。

另一方面，复制时有：

• 返回(大)列表的问题。
• 要忘记将(新的)属性从API域复制到DB域中，反之亦然。

我想知道是否有一条设计规则能说明这一点。

Answer 1

那么，您可以做的是将业务实体(写入数据库的模型)与数据传输对象(即使用DTO模式)分开。所以你最终得到的是：

1. DTO，它仅是您的容器，也就是来自其他部分的数据。
2. 读取传入数据、对其进行一些操作并将其转换为实体的业务逻辑，这些实体将通过DAOs或以其他方式在数据库中被写入/读取。
3. 表示数据库模型的模型实体。

通过这种方式，至少可以实现关注点的分离(安全性、api更改、数据传输)。

现在，这是因为生活中的一切(啤酒:)都有其负面影响:例如，您得到了重复的代码(您必须从dto中的db实体复制模型)，这可能会造成一些开销。

希望这能有所帮助。不知道您使用的是哪种语言，但在java中有一个例子：http://www.oracle.com/technetwork/java/transferobject-139757.html