MVVM 基于绑定和命令。我知道 , 和 commands 的绑定IsEnabled可以IsReadOnly帮助Visibility实现CanExecute将权限考虑在内的 GUI。
然而，我对这种方法有些怀疑。
第一个是需要伴随 VM 的每个涉及 ACL 逻辑的属性CanRead| CanWrite可以绑定到相应控件的属性。这意味着绑定的大量基础结构编码和 XAML 类型。解释原因的动态工具提示也可以添加到列表中。
第二个是 XAML 中的错误输入会破坏安全性，尤其是在读取权限方面：控制将保持可见。在大多数（不是所有）情况下，这个问题可以通过业务逻辑层解决，该层将属性保留为默认值。但是在“返回的路上”（VM->BL）系统必须只关心允许的属性。
安全被称为横切关注点。我了解具有拦截功能的 AOP 或 DI 如何帮助提高 BL 级别的安全性，但我没有关于在 MVVM 设计模式的上下文中为 GUI 实现所有这些东西的好主意。
请您分享您解决此问题的经验。
我所做的是在 ViewModel 级别创建“字段”的概念。这些字段本质上是“模型的每个属性的属性”的抽象。
例如，“Order”视图模型中的字段“OrderNumber”将其 ReadOnly 属性设置为 True，并且“帐户”视图模型中的字段“名称”将其必需属性设置为 true（这更像是业务逻辑而不是一种安全性，但无论如何我将这些东西封装在字段中）。
然后，我在一个特殊的类中为 XAML 使用创建了几个附加属性，以及一个特殊的容器（“字段编辑器”），它的默认样式有一堆指向 VM 中这些字段的绑定。例如，当“IsReadOnly”属性发生更改时，容器（实际上是一个 ContentControl）会沿着其可视子项向下移动，并将任何 TextBox、ComboBox 等设置为只读状态（使用巨大的 switch 语句，因为您可能想要为不同的控件设置不同的属性）。
根据您的应用程序，这可能会有些困难，但我通常使用 Prism 模块解决此类问题。显然，如果您不使用 Prism，这将毫无帮助。
例如，如果用户只有对某些数据的只读访问权限，我会在负责的模块中加载一个完全不同的视图。或者，如果他们无权访问，则该模块不会加载任何内容。这样，您可以为只读和读写访问编写单独的视图。
我想你可以走得更远，也可以换掉 ViewModel，但我不需要这样做。
需要注意的是，我的应用程序使用用户的 Windows 凭据（以及我们公司 AD 中的成员角色）进行身份验证，因此可以在启动时进行处理。如果您有不同的登录/认证系统，您可能需要修改引导程序以在加载模块之前等待登录。
在我看来，MVVM其实是解决你刚刚解决的问题的好方法。由于 MVVM 实际上是将 UI 与代码分离的问题，因此您可以真正在 UI（视图）中做“任何”您喜欢的事情，并将所有逻辑放置到模型中。这是控制中的特权和“流”之类的逻辑。
这样，编码器（通常设计不佳）可以创建控件的逻辑。比如用户什么时候可以保存、删除、打开，以及检查权限和设计师不需要知道的东西。设计者（通常不能很好地编码）可以决定用户如何使用控件。就像应该从按钮、上下文菜单或工具栏进行保存一样。模型/逻辑甚至可以放置在设计人员看不到的自己的 DLL 中，并且只使用可用的可用属性。
责任完全由编码人员承担，并置于模型中。
对我来说，MVVM 不是“基于绑定和命令”。绑定和命令可以很好地用于非 MVVM 编码方式。但我知道这可能会让人感到困惑，因为 MVVM 促使程序员比平时更多地使用命令和绑定。但事实并非如此。这是关于分离逻辑和 UI，所以像你解释的问题可能会以最好的方式解决:-)
这至少是我对 MVVM 以及权限和访问控制的想法。
希望我没有完全误解你的问题。
根据我的观点和经验，UI 永远不应该用于强制安全，而只是根据您的业务逻辑 (BL) 向用户展示他们能做什么和不能做什么。这可以防止 XAML 拼写错误导致违规的问题，此外，有大约十亿个实用程序和黑客可以分析/使 UI 执行用户希望它执行的操作。
例如： http:
//newtipstrik.wordpress.com/2012/02/06/win-enabler/
http://snoopwpf.codeplex.com/
总之，是的，您的 UI 应该只“了解”安全上下文，而不是实现它的全部或部分。