3

好的，这里还有一点需要思考。

MVVM 声明 Model 与 ViewModel 无关。因此，ViewModel 公开了要绑定的 View 的属性。

Microsoft 代码分析规则告诉我向模型中的公共变量添加一个属性。

警告：CA1051：Microsoft.Design：因为字段“Employee.name”在其声明类型之外是可见的，将其可访问性更改为私有并添加一个与该字段当前具有相同可访问性的属性，以提供对其的访问。

现在它的 2 个重复属性，我宁愿让它干燥，所以我在考虑合并 ViewModel 和 View。这里还有一件事，Model 是一个 POCO，并且不会有 INotifyPropertyChanged，所以让 VM 知道 Model 值的变化是另一个问题。我使用了很多基于 IList 的绑定

会不会有我忽略的未来问题？

编辑：我忘了提，我看了如何正确定义模型到视图模型的关系？, 我们软件中的另一件事是我们有一个单独的实体来填充 IList，它是一个 SERVICE/UTILITY 程序集。EmployeeViewModel 位于一个单独的 VIEW 程序集中。所以我将无法返回 ILIst。

4

2 回答 2

2

不要这样做。我知道这听起来像是你不需要的很多额外的东西，但随着你的应用程序变得越来越复杂，它会得到回报。我发现绑定一个支持属性通知的 ViewModel 是绝对必要的，它可以让我以视图可以轻松使用的方式呈现数据，而无需绑定到模型中的表示 - ViewModel 根据需要在两者之间进行转换.

如果您没有这些层，那么将来对事物的更改，特别是一旦您通过一定程度的复杂性将变得非常困难。

现在，您是否听取微软关于在模型上使用公共属性而不是公共字段的建议取决于您，但是如果您以后需要在 getter 和 setter 中添加一些逻辑，这是一个好习惯。一开始，自动属性可以很好地替代简单的公共字段，这样您就不必在实际需要一个支持字段之前声明一个支持字段。

于 2013-03-19T08:38:21.573 回答
0

这里还有一件事，Model 是 POCO，并且不会有 INotifyPropertyChanged，所以让 VM 知道 Model 值的变化是另一个问题

由于（我假设）模型可以从任何地方更改，您唯一的其他选择是拥有 2 个 INPC - 一个用于 Model-ViewModel，一个用于 ViewModel-View。

我个人不喜欢这种做法。太多的流程和重构问题（除非您使用反射 - 这是更多的代码和查找，但高度可维护）只需尝试使用部分类分别物理分离模型和视图模型。例如 Employee.cs 和 Employee.ViewModel.cs。并将它们分组 - 看起来更好

模型需要是可移植的，INPC与可移植类库很好，因此您可以跨各种目标重用代码

于 2013-03-23T04:37:14.267 回答