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