c# - MVVM Light 的“黄金”实现

Question

问题可以总结为：在 UWP 上使用 MVVM Light 开发清晰的应用程序的最佳方式是什么？也许我错过了，但我没有找到样本或类似的东西……</p>

我看到了很多讨论和变化： 模型——我是只放数据还是应该创建 e DAL 模型？如果我使用 EF，我需要 2 层（DAL 和模型）吗？

它应该是可观察的吗？加载/保存或填充方法应该在此处还是在 DAL 中？

然后我们进入更高的层次：如果你有一个类中的列表（例如公司 - 员工），那么 List 对象是在模型中还是在 ViewModel 中？

但是，如果我有模型公司和通过 EF 上的 LINQ 收集的公司列表（列表），我该如何将其转换为ObservableCollection<CompanyViewModel>? 我应该做一个循环并添加新对象吗？不是很有效和很好......没有更好的方法吗？

模型会引发 ContentChanged 吗？（在我看来答案是否定的，它应该由视图模型提出）

对于 ViewModel，您是根据视图（主窗体 ViewModel、TreeView ViewModel）还是数据（CompanyViewModel）映射视图模型？或两者兼而有之（在这种情况下为什么？）？

所有的 ViewModel 都应该是可观察的，所以所有的动作都应该在此处或下方引发内容更改？

我已经看到了所有可能的答案，所以这就是我要问的原因：; 哪个是“黄金”方式？“最佳实践”？我知道几乎所有这些都“可以工作”，但我的目标是了解“最好的”（= 更高效，从设计角度来看更干净，等等......）。

标签： c#entity-frameworkmvvmuwpmvvm-light

Answer 1

在将数据源中的更改传播到 UI 的情况下，您建议的循环和添加新对象的解决方案并不像听起来那么糟糕。如果您的数据源包含允许您仅过滤实际更改的“上次更改”属性，则您只能获取更改的数据。否则，无论如何您都必须查询全部项目数，因此对数据进行另一个循环不会改变复杂性（仍然与项目数成线性关系）。如果您有某种 ID，则可以检查是否存在此类 ID，ObservableCollection然后添加它。

对于您的第二个问题，根据我的经验，您构建和划分视图模型的方式是个人喜好，并且可能因情况而异。我通常有一个页面的视图模型，然后还创建视图模型来包装数据模型（例如列表项等）。但是，如果视图模型变得更加复杂，我通常会对其进行分区并创建负责 UI 特定区域的视图模型。然后可以将这些作为页面本身的视图模型的属性进行访问 - 这样您就可以正确分离关注点。