MVVM Light 的“黄金”实现答案

【问题标题】："Golden" implementation for MVVM LightMVVM Light 的“黄金”实现
【发布时间】：2020-03-04 22:31:23
【问题描述】：

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

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

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

然后我们进入上层：如果您在一个类（例如公司 - 员工）中有一个列表，那么 List 对象是在 Model 中还是在 ViewModel 中？

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

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

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

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

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

【问题讨论】：

DAL 是 MVVM 中模型的一部分。您可以注入一个引用 DAL 的视图模型或使用 DAL 从数据库中获取数据的服务。然后由视图模型或客户端服务负责“转换”数据。什么是普通的旧循环“效率不高”？

标签： c# entity-framework mvvm uwp mvvm-light

【解决方案1】：

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

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

【讨论】：