作为契约一部分的静态方法
本文关键字：静态方法 一部分 契约 | 更新日期: 2023-09-27 18:11:00
我正在实现一个web应用程序中模型访问控制的基础设施。库有一个上下文类，控制器(可能还有视图)使用它来确定当前用户是否有权访问某个对象。为了使相关信息接近目标对象，我决定将访问检查请求从上下文对象传递给模型本身。
为模型对象修改实现这种机制几乎是微不足道的。声明一个接口，例如:ICheckModifyAccess;在你的模型中实现它。删除检查也是如此。在这两种情况下，都可以询问模型的实例是否可以修改或删除它们。
不幸的是，对于read和create操作不是这样的。这些操作要求我向模型类询问问题。因此，使用接口来实现这一点是不可能的。
我最终创建了一个属性CheckCreateAccessAttribute，然后使用这个属性将一个静态函数标记为接口函数。然后，在我的上下文对象中，我可以使用反射来检查这样一个标记的函数是否存在，它是否与我期望的签名匹配，并最终调用它。如果有区别，创建访问检查的方法是public bool CanCreate<TObj>();。支持访问控制的典型模型将向类中添加如下内容:
[CheckCreateAccess]
public static bool CanCreate()
{
return true;
}
我的c#还不是很流利，我总觉得我做错了什么。你能建议一个更优雅的选择吗?特别是，你能摆脱对TObj的反射检查吗?
听起来你在对象类中合并了关注点，而不是将它们分开。
"将相关信息保持在目标对象附近"的诱惑可能导致您使用这种结构。
也许您可以在单独的类中处理权限，参见本文的示例。
我认为你不应该问某个特定的用户你是否可以修改他(除非修改权是针对具体实体的)。只需创建一个处理权限的类(或使用适当的现有类)。
这将消除对静态类和反射的需求。
如果你要有很多类型，每个类型都有自定义规则(即代码)，你可以有一个通用的抽象类型(接口或抽象类)，它能够检查一种类型的规则和一些存储库来检索特定的实例。