Caliburn.Micro - 包裹模型还是直接暴露它？答案

【问题标题】：Caliburn.Micro - Wrap Model or expose it directly?Caliburn.Micro - 包裹模型还是直接暴露它？
【发布时间】：2017-01-16 11:23:40
【问题描述】：

我目前面临着 MVVM 中讨论最多的问题之一：我的 WPF 应用程序中有一个复杂的模型，我不确定如何将其数据显示到视图。

根据 StackOverflow 上的许多答案以及this article 有两种方法：

到目前为止，我的理解是，从理论的角度来看，第一种方法更好，而第二种方法是应该避免的快速捷径。

在我之前链接的same article中，作者写道：

在审查来自 Caliburn 框架的示例应用程序时，他们使用选项 2 实现了 VM。

我查看了 Caliburn.Micro 文档，不幸的是它只使用了一个没有真实模型的简单 ViewModel，所以我不知道如何验证这个声明。

作者说的对吗？由于我使用的是 Caliburn.Micro，我应该使用第二种方法而不是第一种方法，以便更“符合”框架实现吗？

【问题讨论】：

【解决方案1】：

由于我使用的是 Caliburn.Micro，我应该使用第二种方法而不是第一种方法，以便更“符合”框架实现吗？

没有。 Caliburn.Micro 只是一个 MVVM 库。如何实现实际的 MVVM 模式完全取决于您。

我同意@Marek Dzikiewicz 的观点，即您应该将模型包装在可以实现 INotifyPropertyChanged 接口并提供任何其他 UI 特定功能的视图模型类中。此代码不属于业务对象。您可以在此处参考我的回答以获取更多信息：

显然，如果模型类确实是一个 UI 特定类，它没有在任何其他应用程序中使用并且不包含在服务器端使用的任何业务逻辑，您可以修改这个类并直接绑定到它。但它毕竟是一种（子）视图模型。

【讨论】：

我问过the similar question。如果您需要在 WPF 和 MVC 中实现类似的 UI 屏幕并且您想共享用户输入验证逻辑，那么拥有（子）视图模型可能会很有用？作为客户端特定的子视图模型，可以直接将视图作为模型属性公开。值得麻烦吗？ INotifyDataErrorInfo 和 INotifyPropertyChanged 的实现可能对 MVC 没有用处。我想我最初的问题并不清楚（它被否决了:)）。可以重复关闭吗？

【解决方案2】：

通常最好公开视图模型，因为这允许您添加其他属性来控制数据的显示方式（例如格式化或连接数据）。但是，如果您不需要，直接公开模型类并没有错。

【讨论】：