我目前正在构建一个wpf应用程序，其中 View 模型调用单例逻辑类中的函数以获取其模型或修改现有模型...逻辑类负责创建模型并通知相关的 View 模型变化。现在我的问题是我做得正确还是有更好的方法？因为似乎没有人以同样的方式做这件事 - 而且我是 wpf 的新手，我不想一开始就全错。
我的应用程序从数据库获取某些对象并将它们显示在图表上，有一个 View 模型负责显示数据，其余的则接收用户输入以修改数据。
最佳答案
我对目前给你的一些意见有不同的看法。在我个人看来，每个 View 应该有一个 View 模型。公平地说，我提出这个观点的唯一依据就是它的效果如何。在我看来，利用 MVVM 模式的优点在于它的简单性...只需将所有数据属性和功能放入其相关 View 所需的每个 View 模型中即可。
我不同意 @SebastianEdelmeier 关于使用依赖注入(inject)而不是单例类的评论。依赖注入(inject)实际上只不过是通过构造函数将接口(interface)数据传递给类。虽然我并不反对依赖注入(inject)，但应该注意的是，即使是 MSDN 依赖注入(inject)页面也被标记为退役内容。
我有许多 ...Manager 类(其他人可能称它们为服务类)，它们都是单例类...它们需要这样，这样我才能确保只有一个实例每个。它们对单元测试绝对没有任何问题，因为它们都是接口(interface)的，并且我提供了 ...MockManger 类。
不过，我确实接受 @SebastianEdelmeier 的观点，即实际 ...Manager 类中的代码测试起来比较棘手，但它大多只是将文件保存到硬盘驱动器或发送一个文件的基本代码。电子邮件。这是一种经过微软彻底测试的代码，甚至不需要(单元)测试。即便如此，测试它们还是是可能的。
但是，这些服务类都做了一些独特的事情，需要引用 View 模型无法访问的特定 dll 或资源...因此它们为 View 模型提供了一些 View 模型无法提供的服务他们自己。听起来有点像您已将功能放入 Singleton 类中，这些功能可以(并且可能应该)位于您的 View 模型中。我建议不要这样做。
想想 View 模型为 View 提供了一切......数据、功能、对服务功能的访问等。使用服务类的唯一原因是向 View 模型提供一些服务 View 模型无法提供自身。如果该功能不属于此类别，并且您的 View 模型可以为自己提供该功能，那么它应该。
在我看来，主要的异常(exception)之一是，如果您有某种遵循存储库模式的Repository类... View 模型可以创建新的类实例，但使用存储库模式可以减少代码重复...这可能就是您的 Singleton 类的用途，在这种情况下，这很好。
您会看到有人投票结束您的问题。这是因为您发布了一个相当主观的问题，该问题可能有许多不同的答案，但没有单一的正确答案。您可能会发现您的问题因此被关闭甚至删除。虽然我理解您提出此类问题的原因，但您将来确实应该尽量避免此类问题。
关于c# - MVVM？ mvvmc？还是我做错了？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20514502/