6

我发现在很多情况下,在我的 WPF-MVVM 应用程序中对模型使用单例或静态类似乎(至少在表面上)是有意义的。大多数情况下,这是因为我的大部分模型都需要在整个应用程序中访问。制作我的模型static是满足此要求的一种简单方法。

然而,我很矛盾,因为这个星球上的每个人似乎都讨厌单身人士。所以我想知道我没有更好的方法,或者我做错了什么?

4

3 回答 3

5

单例有几个问题。我将在下面概述它们,然后提出一些替代解决方案。我不是那种“永远不要使用单身人士,或者你是个垃圾编码员”的人,因为我相信他们确实有自己的用途。但这些用途很少见。

  1. 线程安全。如果你有一个全局静态单例,那么它必须是线程安全的,因为任何东西都可以随时访问它。这是额外的开销。

  2. 单例的单元测试更加困难。

  3. 它是全局变量的廉价替代品(我的意思是,这就是一天结束时的单例,尽管它可能有方法和其他奇特的东西)。

看,这并不是说 Singleton 本身就是“可怕的可憎”,而是它是许多新程序员要处理的第一个设计模式,它的“便利性掩盖了它的”陷阱(只需在上面加上一些齿轮,称之为蒸汽朋克)。

在您的情况下,您指的是模型,这些始终是“实例”,因为它们自然地反映了数据。也许您担心获得这些实例的成本。相信我,它们应该可以忽略不计(显然是数据访问设计)。

那么,替代品呢?将模型传递到需要它的地方。这使单元测试更容易,并允许您快速更换该模型的基础知识。这也意味着您可能想查看接口 - 这些表示合同。然后,您可以创建实现这些接口的具体对象,瞧——您的代码很容易进行单元测试和修改。

在单例世界中,对该单例的一次更改可能会从根本上破坏代码库中的所有内容。不是什么好事。

于 2013-06-04T19:03:57.470 回答
2

我认为这个问题的公认解决方案是使用依赖注入。通过依赖注入,您可以将模型定义为常规的非静态类,然后在需要时让控制容器反转“注入”模型的实例。

wpftutorial.net 上有一个很好的教程,展示了如何在 WPF 中进行依赖注入:http ://wpftutorial.net/ReferenceArchitecture.html

于 2013-06-04T19:02:43.073 回答
2

我使用的唯一静态类是 MessageBroker,因为我在整个应用程序中都需要相同的实例。

但即便如此,也很有可能使用 Unity(或其他依赖注入/容器)来管理您只需要其中一个的类的实例。

这允许您在需要时注入不同的版本(例如在单元测试期间)

顺便说一句:静态与单例不同。但我不会在这里讨论。只需在 stackoverflow 上搜索更多有趣的问题 :)

于 2013-06-04T19:04:24.193 回答