我需要将一些基于角色的内容(几部分生成一个对象)从数据库带到服务层。对每个内容片段的访问将取决于用户具有的角色。如果用户角色无权访问某个片段，则该片段将为空。这不是一个巨大的应用程序，只是一个基于角色公开一些内容的 Web 服务方法。
我可以通过三种方式做到这一点。
1) 根据用户角色，对每条内容进行数据库调用。
优点 - 角色在代码中进行管理，从而有助于业务逻辑(？)保留在代码中。只带回需要的数据。
缺点 - 多个数据库调用。添加新角色时需要修改代码。 (除非使用了一些非常复杂的业务逻辑。)
2) 进行一次数据库调用并将所有内容片段作为单独的结果集返回。循环遍历集合并根据用户角色获取片段。
优点 - 单个数据库调用。角色在代码中进行管理。
缺点 - 需要为新角色修改代码。尽管可能不需要，但会带回额外的数据。那些不需要的查询会增加几秒钟。
3) 将角色发送到数据库并根据角色访问权限获取每个片段。
优点 - 单个数据库调用。只带回需要的东西。无需为新角色更改代码，因为只需更改存储过程。
缺点 - 数据库中的业务逻辑？
在我看来#3 > #2 > #1。 (覆盖 > 表示优于)
有没有人对哪种方法可能更好有任何见解？
更新 - 根据一些评论，下面是更多详细信息。
用户角色是从另一个系统获得的。 #3 理想情况下将它传递给数据库，粗略地说，对于数据库，返回数据，如 user_role =“admin”，获取所有片段，对于“编辑器”获取内容片段 1,3 和 55。同样，这是不是在数据库中完成角色管理的大型应用程序。它是一种为多家公司公开某些数据的 Web 服务方法。
我们显然不能使用此模型来管理应用程序中的角色。但是对于这种情况下的方法级访问控制，我相信#3 是最好的方法。由于角色来自另一个系统而不是内容所在的系统，因此控制对不同内容片段的访问的逻辑必须位于某个地方。在这种特定情况下，数据库看起来是拥有可维护、可扩展、麻烦较少的解决方案的正确位置。也许，甚至在内容数据库中创建一个查找表来保存角色和内容片段访问，以提供“数据”和“逻辑”分离的感觉，而不是让 udf 来执行逻辑。
如果没有人能想到针对#3 的有效案例，我想我会继续。
最佳答案
我总是会选择选项 3 并在数据库本身中执行它。
出于多种原因，最好在最接近实际数据本身的地方处理安全问题。这么看:比起折腾一个数据库模型，多加一个不同语言的应用更常见。发生这种情况时，您的所有角色处理代码都必须重复。
或者假设应用程序在黑客攻击期间被完全绕过。数据库仍应加强其安全性。
最后，尽管人们喜欢将“业务逻辑”与他们的数据分开，但现实情况是，如果没有所说的逻辑，大多数数据就毫无意义。无论如何，进一步的“安全逻辑”与常规的“业务逻辑”不同。它在那里保护您和您的客户。但那是我的 0.02 美元。
看看你的其他选择:
2) 您发送回客户端的数据过多。这在安全性和性能上都是不行不行的。如果您的应用不是发出数据请求的应用怎么办？如果您的应用程序中有一个小错误，向用户显示了太多内容怎么办？
1 和 2) 两者都需要重新部署，即使是轻微的逻辑更改(例如修复上面的神秘错误)。这可能不是所希望的。就个人而言，我更喜欢对存储过程进行微调，而不是重新部署代码。在一个足够大的项目中，可能很难确切地知道所有正在部署的是什么，而且通常有更高的潜在问题。
更新
根据您的附加信息，我仍然建议坚持使用 #3。
关于c# - 从数据库中检索基于角色的内容片段的选项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7079724/