我目前正在构建一个wpf应用程序，其中视图模型在单例逻辑类中调用函数以获取其模型或修改现有模型...逻辑类负责创建模型并通知相关的视图模型变化。现在我的问题是我正确地做到了还是有更好的方法来做到这一点？因为似乎没有其他人以同样的方式这样做 - 而且我是wpf的新手并且我不想开始全部错误。
我的应用程序从数据库获取某些对象并将其显示在图形上，有一个视图模型负责显示数据，其余视图模型接收用户输入以修改数据。
答案 0 :(得分：2)
我对迄今为止给你的一些意见持不同看法。在我个人看来，每个视图应该有一个视图模型。公平地说，我所有的观点都是它的运作方式。我看到它的方式，利用MVVM模式的好处在于它的简单性......只需将所有数据属性和功能放入其相关视图所需的每个视图模型中。
我不同意@SebastianEdelmeier关于使用Dependency Injection而不是Singleton类的评论。依赖注入实际上并不比通过构造函数将接口数据传递给类更多。虽然我不反对依赖注入，但应该注意的是，即使MSDN依赖注入页面也被标记为Retired Content。
我有许多...Manager类（其他人可能称之为服务类），这些类都是Singleton类......它们需要确保每个只有一个实例。它们完全没有单元测试的问题，因为它们都是接口的，我提供了...MockManger类。
但我接受@ SebastianEdelmeier的观点，即实际的...Manager类中的代码更难以测试，但它主要是将文件保存到硬盘驱动器或发送电子邮件的基本代码。这种代码经过Microsoft的全面测试，甚至不需要（单元）测试。即便如此， 也可以测试它们。
但是，这些服务类都做了一些独特的事情，需要引用视图模型无权访问的特定dll或资源...因此它们为视图模型无法提供的视图模型提供了一些服务本身。这听起来有点像你已经将功能放入你的Singleton类中，可以（也可能应该）在你的视图模型中。我会反对这种做法。
考虑视图模型为视图提供所有内容...数据，功能，对服务功能的访问等。使用服务类的唯一原因是为视图模型提供一些服务视图模型无法提供自己。如果该功能不属于此类别，并且您的视图模型可以为自己提供，那么它应该。
在我看来，其中一个主要的例外情况是，如果您在Repository模式之后有某种Repository类...视图模型可以创建新的类实例，但是使用存储库模式可以减少代码重复...可能就是你的Singleton类所用的那种情况，这很好。
你会看到有人投票决定关闭你的问题。这是因为你发布了一个相当主观的问题，这个问题可能有很多不同的答案，但没有一个正确答案。由于这个原因，您可能会发现您的问题已被关闭甚至删除。虽然我理解你发布这样一个问题的原因，但你真的应该在将来尝试避免这些类型的问题。
答案 1 :(得分：-1)
您已经遇到过MVVM问题＃1 - 有很多不同的方法，MVVM是一种模式，而不是框架。
细节：viewmodel是进行自己的更改通知的人（使用INotifyPropertyChanged），这是其核心任务之一。我会将更改通知保留在业务逻辑之外，这是一个依赖于视图的问题，并且没有功能。
关于单身人士，我只建议你开发你的类没有单例实现，并有一个依赖注入容器（如Ninject）将它们解析为单例。否则你最终会得到很多难以测试的代码（以及大量的冗余）。静态的东西可以测试，但是当涉及到嘲弄时，它们会变得非常讨厌。