Application.Resources 用于存储应用程序数据答案

【问题标题】：Application.Resources for storing application dataApplication.Resources 用于存储应用程序数据
【发布时间】：2010-09-14 18:28:44
【问题描述】：

我只是好奇这是一种好的做法还是坏的做法，或者最喜欢的做法是什么。

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

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

【问题讨论】：

标签： c# .net wpf

【解决方案1】：

我实现了一个应用程序视图模型 (AVM) 对象。任何需要全局暴露给应用程序视图的东西都被实现为应用程序视图模型中的一个属性，这样我就可以通过绑定来访问它。这提供了一个很好的一致访问方法，让我可测试，实现属性更改通知，给我一个放置应用程序范围命令的地方，所有你期望使用视图模型的东西。

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

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

我一般不会在资源字典中放入不是在 XAML 中创建的任何内容。我可以想到很多对这条一般规则的有效例外，但它们还没有出现在我的程序中。

【讨论】：

哦，我真的很喜欢这个，这听起来很棒，我喜欢 AVM 从对象的角度给出了应用程序的良好根表示，从而使理解应用程序设计的起点显而易见
您是否实现了 AVM 也绑定到的 ApplicationModel？
当然，如果需要的话。很多是需要能够在 Expression Blend 中使用 VM 对象的驱动因素 - 您基本上希望能够实例化视图模型中的所有对象，而不必实例化任何域对象并改用模拟域对象。但这一切都取决于 Expression Blend 对您的开发工作流程的重要性。

【解决方案2】：

在以下情况下将内容放入 App.xaml 可能会成为问题：

您开始将应用程序分支到单独的程序集中，因为程序集无法“看到”app.xaml 设计时 - 您只能在运行时找到错误。
您有一个用于指向您的资源的魔术字符串，它很容易拼写错误 - 或者更糟糕的是，意外重复。
以后很难找到任何给定资源的使用位置以及是否可以安全地更改它（'UpdateFrequency 是为了什么......'）
您希望它是可配置的 - app.config 文件的 AppSettings 部分更适合此类设置。

这本质上与使用全局静态变量进行设置的问题相同。

编辑：我更喜欢在 App.Xaml 中拥有的东西是：

全局样式和数据模板 - 换句话说 - 用于覆盖“标准”设置的视觉呈现的东西 - 所以它们通常没有 x:Key 标记，而是 TargetType="{x:Type SomeType}"

希望这会有所帮助！

【讨论】：

【解决方案3】：

这对于跨应用程序共享的内容确实有意义 - “不要重复自己”。我还建议拥有一个合并应用程序资源的项目特定资源。控件应该引用它而不是应用程序资源。

这使得项目中的控件更加独立。

我还建议将资源分成逻辑组并合并它们，而不是“一个大桶”。

【讨论】：

最好不要在设计时集中资源，而是在编译时合并它们！你能举例说明这是如何做到的吗？