0

我的团队有一些关于更新实体数据以及如何最好地处理它的讨论。这是一个安全框架，所以这里有一些限制和想法。

  1. DB 中的每个表都有一个作为 guid 的 PK，这是我们的多节点集群解决方案所必需的。我们的想法是我们不想通过 API 将实体上的这个暴露给客户，因为它可以做两件事，
    1. 为他们提供工作所需的更多信息，并为黑客提供有关系统的更多信息。
    2. 支持噩梦是客户端以某种方式硬编码到此 ID，如果我们需要更改 PK 的客户端会受到影响。

解决方案是公开项目的自然键，例如具有唯一名称的角色对象和领域，一起保证唯一性但是更新这些值中的任何一个都是挑战，因为您需要指定要更新的旧值和新值，或者传递两个原始对象和新对象中的对象，因此我们可以找到要更新的对象。有点乱，

另一种方法是制作一个备用密钥并将其公开给客户，他们可以随心所欲地使用它，我们不在乎，因为它与我们的 PK 无关。

现在似乎每个人都只是使用 PK 作为实体的 ID，没有任何问题，不知道如何说服我们的老兵团队从过去的编程时代开始。

另一个问题是如何支持部分更新，问题是您拥有具有 10 个属性、4 个集合等的实体......具有名称+领域组合并指定要更新的属性而不是下拉整个对象更改 1 字段，发回更新。我说延迟加载集合，但不确定部分更新是否有意义。

想法？

谢谢！

4

3 回答 3

1

我的安全框架方法是这样的：

  • 为数据库中的任何内容提供一个内部 ID（身份列、序列，无论您的数据库支持什么。Hibernate 中的“本机生成的 id 列”）。最终，您将需要它，并且进行改造需要做很多工作。

  • 如果您需要将 ID 交给用户，生成一个随机数，检查它是否尚未使用，将其连接到内部 ID，然后将其交给用户。永远不要分发内部 ID，也不要使用破解者可以猜到的 ID。

至于部分更新，只有当你有很多具有很多属性的对象时它们才开始有意义。对于 10 个属性，我会说“过早优化”。

于 2009-05-28T07:24:21.950 回答
0

如果您需要向客户端公开 id，请使用自然键。实现起来并不容易，但这是正确的方法。

您能否提供有关这些部分更新的更多详细信息？我没明白。：/

于 2009-05-28T06:59:22.923 回答
0

在每个表上使用 GUID 作为主键听起来像是自找麻烦。除非我真的误解了你，否则我没有在任何地方看到这种方法。为什么不向每个用户颁发一个 UID 并使用该 UID？

This approach is most common across all companies. The UID is not PII so you are okay legally as was as from a security point of view.

于 2009-05-28T07:52:34.360 回答