我最近才开始使用 MVC 方法,所以我想这对你们大师来说是一个简单的方法:
我在哪里设置访问控制?
- 在视图中?除了模板中的开关和标志之外,我不想有任何逻辑,所以这听起来像是最不可行的选择
- 在模型中?每个业务对象是否应该根据谁的要求来决定它将显示哪些关于自身的数据?
- 在控制器中?这就是我现在拥有的地方,但它很难保持业务规则的一致性
或者还有其他选择吗?
我最近才开始使用 MVC 方法,所以我想这对你们大师来说是一个简单的方法:
我在哪里设置访问控制?
或者还有其他选择吗?
这将取决于您使用的框架,并且语言将决定您可以使用的许多工具。
从高层次上讲,您应该在入口点配置访问安全性。并且您应该仔细检查每个级别的访问安全性,这些级别可能被认为是自主的或从应用程序的多个部分重用(谁知道是否由使用您的逻辑层的同事的门户检查了安全性?等等)。要担心的另一件事是数据安全性,它属于尽可能接近您的数据(所以,对上面的#2 是的,但要理解它是分开的)。
这类似于我喜欢谈论的应用程序逻辑和域逻辑之间的区别。如果有任何特定于特定应用程序的逻辑(Web 应用程序与 Windows 服务相比,或其他),则该逻辑应仅在该应用程序中定义。如果某些逻辑跨越了应用程序之间的边界(在应用程序之间可重用),那么它就有资格作为域逻辑并且应该在您的模型中定义。您的应用程序可以使用域逻辑,但它们不应该拥有它。
对于模型(又名数据)安全性,模型将“控制”访问,而控制器将“促进”访问。这提供了独立于控制器的模型的重用,并最小化(如果不是否定)跨使用模型的不同控制器所需的通用代码复制。
例如汽车、司机和钥匙。(分别为模型、控制器、API)。凭借非常小的接口(密钥 == API),模型允许或拒绝每个 API 的控制器访问(密钥卡)。允许不同类型的访问(代客钥匙、所有者钥匙、所有者 FOB)。使用代客钥匙界面,控制器将无法访问模型的某些数据/功能,例如手套箱、行李箱和油箱。这本质上是模型通过识别和分类具有非常小的 API/命令表面积的控制器来实现的基于角色的访问。
这意味着模型可以被其他控制器(具有不同驱动程序的汽车)使用,这些控制器只需要基本的身份验证就可以访问模型的数据(汽车的功能和车厢)。