在视图模型之间传递状态答案

【问题标题】：Passing state between view models在视图模型之间传递状态
【发布时间】：2015-04-08 00:17:55
【问题描述】：

只是想知道对于 MVVM、DDD 和其他哲学而言，是否真的就“正确”的方式达成共识。 . .

所以我有一个登录屏幕，由一个 ViewModel LoginViewModel 表示。它可以使用名称和密码。它还通过依赖注入引入了一个LoginService，实现了获取用户名和密码，以及获取Employee对象的逻辑。

我的问题是将这些信息传递给下一个视图模型的“正确”方式是什么？假设它是 AccountSettings，它需要了解登录的员工。我们如何封装它？我有一个 AccountSettingsViewModel，但它是否需要

a) LoginViewModel 的一个实例？ b) LoginService 的一个实例，它保留对已登录员工的引用 c) 全局对象上的共享对象或字段，例如 App 之类的？

提前致谢！

【问题讨论】：

这里只是一个更新 - 这样做是为了让服务相互依赖，但 ViewModel 没有。因此，在上面的示例中，AccountSettingsViewModel 依赖于 AccountService。 AccountService 依赖于 LoginService（保存登录状态）。不完美，但似乎工作正常。

标签： oop mvvm dependency-injection domain-driven-design

【解决方案1】：

我个人在 DDD 或其他方式中的所有视图模型都是简单的数据容器，用于限制从应用程序发送到 UI/视图的数据。我可能会在我的视图模型中包含一些特定于为该视图转换数据的代码。我还认为我的视图模型与我的视图耦合（我之所以提到这一点，是因为我看到 2 个团队将它们放在远离视图的单独项目/程序集中！）。

如果我有任何复制数据或执行操作以获取视图模型所需的数据，这将存在于我的域模型或应用程序层中，可能存在于服务中。我永远不会将服务注入到视图模型中。

【讨论】：

感谢您的反馈。我实际上是在传递服务以将所有逻辑排除在 VM 之外——我还想避免将存储库直接传递给 VM，因此该服务是一种抽象实体之间协调的方法。我猜我的例子中的“服务”是相当开放的——但我也在努力避免有不能充当实体或值对象的愚蠢对象，比如“LoginAccountEmployerCoordinator”之类的东西，它在多个实体之间工作以响应视图事件。许多人也有一个事件源模型，所以也许这就是使事情复杂化的原因。
理想情况下，我认为您的虚拟机应该与您的视图分离 - 视图应该依赖于 ViewModel，但绝不是相反。这使单个视图模型能够支持多个平台 - 例如，用于平板电脑、手机以及 HTML 页面的原生移动设备。
实际上，我见过的视图模型最糟糕的事情是当人们发现重复属性的共性并尝试创建复杂的继承层次结构时。我喜欢保持我的视图模型和消息对象非常平坦。我还看到人们尝试跨视图重用视图模型，因为它们碰巧具有相同的属性以试图安抚 DRY 之神，但没有发现视图不同并且只是偶然地采用相同的属性，机会它们是否会在未来随着时间的推移而单独发展。
嗯——在不同版本（平台）呈现相同应用程序的情况下，您似乎希望重用 ViewModel。你是说你有一个适用于 Android 的 ViewModel，一个适用于 iOS 等等？
有趣的是，我想在这种情况下，如果您要为每个移动操作系统复制完全相同的视图，也许您可以分享它们。