我只是好奇这是一个好还是坏的做法，或者最喜欢的做法是什么。
我所指的实践是，由于我是 WPF 的新手，我发现将字符串、xdocuments 和域对象放入 app.xaml 中的 Application.Resources 中非常方便且有用。当整个应用程序需要它们的数据时，以及为了通过 x:key 进行静态资源绑定(bind)的简单性。
好？坏的？为什么？我该怎么办？请不要链接到大型 MVVM 教程等，只是寻找有关此特定实践的简洁答案，如果 MVVM 有答案，我很高兴听到它是什么，我只是不想阅读 6 页的教程或博客来了解..
最佳答案
我实现了一个应用程序 View 模型 (AVM) 对象。任何需要全局公开给应用程序 View 的内容都会作为应用程序 View 模型中的属性实现，以便我可以通过绑定(bind)来访问它。这形成了一个很好的一致访问方法，使我具有可测试性，实现属性更改通知，为我提供了放置应用程序范围命令的位置，以及您期望使用 View 模型获得的所有内容。
每个顶级窗口的数据上下文都设置为应用程序 View 模型的实例。所以我根本不需要搞乱资源字典或记住关键值。乍一听可能有点奇怪 - 为什么两个窗口会使用相同的 View 模型？ - 但如果您想在应用程序生成的每个窗口上放置相同的 File/Exit 命令，这实际上是合乎逻辑的。在这种情况下，窗口的数据上下文设置为 AVM，然后它包含一个面板，该面板的数据上下文设置为 AVM 上的一个属性，该属性是该窗口的实际上下文。只要为窗口元素指定一个名称，绑定(bind)到 AVM 上的对象就很简单 - {Binding ElementName=TheWindow, Path=DataContext.TheProperty} - 或者您可以将 AVM 公开为 subview 模型。
AVM 模式与任何“one-object-to-rule-them”模式都存在相同的缺陷 - 例如创建一个具有 200 个不相关属性的步履蹒跚的野兽。解决方案是相同的:将这些属性聚合到服务类中。
我通常不会将任何不是在 XAML 中创建的内容放入资源字典中。我可以想到这个一般规则的许多有效异常(exception)，但它们还没有出现在我的程序中。
关于c# - Application.Resources 用于存储应用程序数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3711812/