许多人建议WPF MVVM开发人员不要将Model实例从ViewModel公开给View。要显示来自Model实例集合的信息，请将所有单个项目包装到ViewModel实例中，然后将ViewModels集合暴露给View。
但是，使用MVVM Light，在我看来似乎有两种ViewModel：
MainWindowViewModel或CustomerEditorViewModel）。假设只有一个MainWindow，那就只有一个MainWindowViewModel。CustomerViewModel），并且是模型实例的某种“机械配合”，提供了诸如计算属性（例如DurationfromStartTime和EndTime）之类的附加功能。一个普通的公司有很多Customers，所以会有很多CustomerViewModels。那么如何包装Model实例呢？
一种想法可能是创建包装类ViewModelBase，该包装类源自但不注册并使用实例化它们ViewModelLocator。我认为拥有两个分别称为ViewModel的独立对象不是一个好主意。
另一个想法可能是对第二种类型的ViewModel使用新的基类，可能称为ModelInfo。在单个实例中MainViewModel，将有一个CustomerInfo实例集合，为Customer模型数据提供附加功能。
我倾向于后者，但是由于这似乎是使用MVVM Light的相当普遍的情况，因此我确信必须对此问题有一个通用的解决方案。
更新资料
我找到了MVVM Light的作者Laurent Bugnion的文章。Bugnion在2012年发表的文章中使用了两种不同的初始化ViewModels的方法：
MainViewModel已向进行注册，ViewModelLocator并且没有构造函数参数。因此，它适合于依赖注入，并且可以通过ServiceLocator实例化。FriendViewModel未在中注册，ViewModelLocator并且其构造函数将Model实例作为参数。不能使用ServiceLocator实例化它，而只能通过直接调用构造函数并传递模型实例来实例化。这与我原始问题中提到的差异非常吻合，并且与如何包装模型实例的第一个想法相吻合。
这是我个人7年的MVVM经验。我之所以说是个人的，是因为您会在此主题上发现很多矛盾，尤其是当您参考官方的MSDN定义时
“在我看来，有两种ViewModel”
绝对不是，但这是一个普遍的误解。ViewModel的首要作用是成为View的可测试和可维护的表示形式。正确的抽象就是与视图（而不是模型）的一对一关系。
“许多人建议WPF MVVM开发人员不要将Model实例从ViewModel公开给View。”
是的，这仍然是正确的，因为如果从OOP角度正确实现了模型，则您会将责任和业务逻辑放入其中。因此，您的ViewModel只是INotifiedPropertyChanged，并包装了要从Model中公开的信息以及要在Model中调用的命令。
经典的解释（包括MSDN的解释）是不完整的，因为它假定您可以将一个ViewModel与一个ViewModel与一个Model对齐。因此，您的问题经常被忽略，因为在一个非常CRUD的系统中，您可以轻松地实现这种一对一的关系。具有这种关系的另一种方法是使用CQRS，因为它允许您生成没有任何逻辑的模型，并直接在视图上对齐以进行查询。
但是，正如您已经体验到的（如果您不在CRUD或CQRS系统上工作），在大多数经典实现中，您的ViewModel代表您的View，但需要几个模型才能正常工作（这很自然）。您必须在这些模型中尽可能多地添加业务逻辑。为了管理对不同模型的调用之间的流程，您添加了另一个抽象，可以称为服务。该服务应代表一个业务案例，需要使用多个模型。
您可以这样考虑：您的BusinessService应该独立于基础结构运行。它不在乎是从ViewModel还是从Web App中的Controller调用的。它只是管理某些模型之间的流程以满足业务需求。
让我尝试回顾一下：
ViewModel不应该具有业务逻辑（但是您已经知道了）
ViewModel是View的抽象（而不是Model的抽象，即使在某些情况下，您可以获得一对一的关系）
如果ViewModel需要多个模型来满足业务需求，请使用Service管理不同模型之间的流（按照定义，它成为BusinessService）
这是一个带有代码示例的博客文章，以阐明我的观点：http : //ouarzy.azurewebsites.net/2016/04/14/clarifying-mvvm-with-ddd/
希望能帮助到你。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句