我发现在很多情况下，在我的WPF-MVVM应用程序中使用单例或静态类作为模型似乎(至少表面上)是有意义的。大多数情况下，这是因为我的大多数模型需要在整个应用程序中被访问。把我的模型改成static是一种满足这一要求的简单方法。
然而，我很矛盾，因为这个星球上的每个人似乎都讨厌单身。所以我在想有没有更好的办法，或者我是否做错了什么?
单例有几个问题。我将在下面概述它们，然后提出一些替代解决方案。我不是那种"永远不要使用单例，否则你就是个蹩脚的程序员"的人，因为我相信它们确实有它们的用途。但这些用途很少。
-
线程安全。如果你有一个全局静态单例，那么它必须是线程安全的，因为任何东西都可以在任何时候访问它。
-
这是一个便宜的替代全局变量(我的意思是，这是什么单例是在一天结束时，尽管它可能有方法和其他花哨的东西)。
看，这并不是说Singleton本身是"可怕的令人讨厌的"，而是它是许多新程序员要处理的第一个设计模式，它的"方便"掩盖了它的"陷阱"(只要在它上面加一些东西，就叫它蒸汽朋克)。
在你的例子中，你指的是模型，这些总是"实例"，因为它们自然地反映了数据。也许您担心获取这些实例的成本。相信我，它们应该可以忽略不计(显然是数据访问设计)。
,选择呢?将模型传递到需要它的地方。这使得单元测试更容易，并允许您在一瞬间交换出该模型的基础。这也意味着您可能需要查看接口——它们表示契约。然后，您可以创建实现这些接口的具体对象，瞧，您的代码很容易进行单元测试和修改。
在单例世界中，对该单例的一个更改可能会从根本上破坏代码库中的所有内容。
我认为这个问题公认的解决方案是使用依赖注入。使用依赖注入，您可以将模型定义为常规的非静态类，然后在需要时使用控制反转容器"注入"模型的实例。
在wpftutorial.net上有一个很好的教程，展示了如何在WPF中进行依赖注入:http://wpftutorial.net/ReferenceArchitecture.html
我使用的唯一静态类是MessageBroker，因为我需要在整个应用程序中使用相同的实例。
但即使这样，使用Unity(或其他依赖注入/容器)来管理你只需要其中一个类的实例也是非常可能的。
这允许你在需要的时候注入不同的版本(例如在单元测试期间)
BTW:静态和单例是不一样的。但我在这里不讨论这个。可以在stackoverflow上搜索更多有趣的问题:)