c# - Application.Resources 用于存储应用程序数据

Question

我只是好奇这是好事还是坏事，或者最好的做法是什么。

我所指的做法是，由于我是 WPF 的新手，所以我发现将字符串、xdocuments 和域对象放入 app.xaml 中的 Application.Resources 非常方便且有用当整个应用程序需要它们的数据时，以及为了通过 x:key 进行静态资源绑定(bind)的简单性。

好吗？坏的？为什么？我应该怎么做？请不要链接到大型 MVVM 教程等，只是寻找有关此特定实践的简明答案，如果 MVVM 有答案，我很高兴听到它是什么，我只是不想阅读 6 页教程或博客以了解..

Answer 1

我实现了一个应用程序 View 模型 (AVM) 对象。任何需要全局暴露给应用程序 View 的东西都作为应用程序 View 模型中的一个属性实现，这样我就可以通过绑定(bind)来访问它。这形成了一个很好的一致访问方法，使我具有可测试性，实现了属性更改通知，为我提供了放置应用程序范围命令的地方，以及您希望使用 View 模型获得的所有内容。

每个顶级窗口的数据上下文都设置为应用程序 View 模型的实例。所以我根本不需要弄乱资源字典或记住键值。起初听起来可能有点奇怪——为什么两个窗口会使用相同的 View 模型？ - 但如果您想在应用程序生成的每个窗口上放置相同的 File/Exit 命令，这实际上是合乎逻辑的。在这种情况下，窗口的数据上下文设置为 AVM，然后它包含一个面板，其数据上下文设置为 AVM 上的一个属性，该属性是该窗口的实际上下文。只要你给你的窗口元素一个名字，绑定(bind)到 AVM 上的对象是微不足道的 - {Binding ElementName=TheWindow, Path=DataContext.TheProperty} - 或者你可以将 AVM 作为属性公开 subview 模型。

AVM 模式与任何一个对象到规则它们的模式一样存在相同的陷阱 - 例如创造一个拥有 200 个不相关属性的蹒跚野兽。解决方案是相同的:将这些属性聚合到服务类中。

我通常不会将不是在 XAML 中创建的任何内容放入资源字典中。我可以想出很多这个一般规则的有效异常(exception)，但它们还没有出现在我的程序中。