对于使用couchbase的解决方案，这是一种合理的.NET自定义角色提供程序方法吗

本文关键字：NET 自定义 角色 方法 程序 一种 解决方案 couchbase 于使用 | 更新日期: 2023-09-27 18:26:41

我目前正在考虑为couchbase构建一个.NET角色提供程序，以便在项目中使用。我希望在两种文档类型中对此进行建模。

第一种文档类型是应用程序中所有可用角色的简单列表。这使得它很容易支持Add、Delete、GetAllRoles等。此文档将为每个应用程序提供一个固定的密钥，因此为"applicationname_roles"，因此从代码的角度来看它是众所周知的，并且可以快速检索。

第二个文档将用户映射到一个角色，例如

{"类型"："角色提供者.用户角色"，"user"："user1"，"角色"："角色1"，"应用程序"："app1"}

此文档类型的密钥的格式为"applicationname_roles_username_rolename"，这使得测试用户是否处于特定角色的最常见操作变得简单而快速。

为了支持.NET角色提供程序的GetRolesForUser或GetUsersInRole方法，我正在使用窗体.的视图进行研究

function (doc, meta) {
if(meta.type != 'json')
{
    return;
}
if (doc.type == "roleprovider.user-role")
{
    if(doc.application && doc.user && doc.role)
    {
      emit([doc.application, "user:" + doc.user, doc.role]);
      emit([doc.application, "role:" + doc.role, doc.user]);
    }
}}

因此，对于每个用户到角色的映射，我们会将2行发射到视图中。第一个允许我们在视图中查询用户所扮演的角色。第二个允许我们查询用户所担任的角色。.NET提供程序只需根据其查询GetRolesForUser或GetUsersInRole是否为"user:"或"role:"加前缀，即可筛选出所需内容。

所以现在的问题是，这一切似乎都相当琐碎和合乎逻辑，然而这是我第一次与Couchbase合作，并想知道我是否因此陷入了任何陷阱？一个明显的替代方法是使用2个视图，但在我的阅读中，我看到它提到了最好减少设计文档的数量以及这些文档中的视图数量，请参阅Perry Krug在每桶沙发视图讨论中的回答，他在讨论中提到了试图"从一个索引中生成多个不同的查询"。所以基本上，我想知道我上面描述的方法是在为佩里的话开处方，还是我只是在欺骗自己，最终会给自己带来痛苦。

谢谢你的指点。

对于使用couchbase的解决方案，这是一种合理的.NET自定义角色提供程序方法吗

（注意：复活一个古老的问题，因为它还没有得到回答，可能会引起其他人的兴趣。）

你的方法总体上是合理的。但是，除非您实际遇到性能问题，否则在这种情况下，我会坚持每个查询类型一个视图。虽然将多个查询合并到一个视图中会减少Couchbase构建视图所需的工作量，但它会增加每个查询的成本，因为它必须扫描两倍大的索引。如果你不同时使用许多其他视图，我会将这些视图分开。事实上，我甚至会把它们放在不同的设计文档中，这样Couchbase就会通过不同的索引器线程同时处理它们。对于还不存在的性能问题，没有必要过早地进行优化；首先使用简单的解决方案，然后在必要时进行优化。

如果查询读取确实遇到性能问题，则可能需要考虑从视图转向基于键/值的方法。具体来说，为每个应用程序用户和应用程序角色对存储一个单独的文档，并将角色列表附加到前者，将用户列表附加到后者。这意味着您最终基本上自己维护索引，但这将使读取延迟提高一个数量级。看看这篇关于使用追加操作维护集合的博客。

是的，我确实看到了讽刺的一面，在一段话中反对过早优化，而在下一段话则建议进行性能优化。因此，我想强调的是，您应该首先测试视图方法是否为您提供了可接受的性能——对于大多数合理的应用程序来说，它确实会提供性能——如果确实如此，请坚持下去，因为它要简单得多。如果你发现自己毕竟需要更好的性能，那么就开始考虑第二种选择。

相关文章：