Android MVVM 设计 - 我应该将我的视图模型类一分为二吗？答案

【问题标题】：Android MVVM design - should i split my viewmodel class in two?Android MVVM 设计 - 我应该将我的视图模型类一分为二吗？
【发布时间】：2021-01-31 10:13:32
【问题描述】：

我的应用有 2 种截然不同的模式（设置和运行计时器）。

该应用允许用户在一个片段上进行多因素输入，一旦用户希望启动计时器，该应用就会切换到正在运行的片段以显示有关其正在运行的计时器及其设置的信息。我为此设计了一个 MVVM 架构，我自己的类扩展了ViewModel，我的共享视图模型有两种截然不同的逻辑类型，设置逻辑（检查、解析和修改不适当的用户输入）和运行计时器逻辑（从用户的输入中管理正在运行的计时器的所有逻辑、数据和状态）。

我的共享视图模型类并不小，因为检查用户输入的所有排列的过程很复杂。我想知道将所有这些逻辑放入一个视图模型类中是不是一个坏主意？设置部分设计得很简单，所有设置状态都被保存（因此用户设置计时器的时间为 10-20 秒似乎合适），而计时器被设计为允许运行数小时，主要是在屏幕关闭的情况下。我是否应该将 viewmodel 逻辑拆分为两个不同的 viewmodel 类以使正在运行的计时器更节省内存？

我看到了清晰的关注点，一旦我设计和编程了我的 Room 数据库，只有运行计时器会将数据保存到数据库中。我想让片段类尽可能轻量级。如果这是一个明智的设计选择，那么就需要小心两种状态之间的内存泄漏，否则我就达不到目的了。

经过编辑以区分 ViewModel 对象和共享视图模型理念

【问题讨论】：

归根结底，这完全取决于您。觉得你的班级做得太多了？违反了坚实的原则？然后拆分它。真的不知道还是不在乎？然后不要。我们不能在这里给你一个事实的答案，因为这不是软件设计，你实际上并没有面临运行应用程序的问题
感谢您抽出宝贵时间发表评论，我觉得我违反了“仅使用任何应用程序状态所需的最小内存”的原则 - 所以我决定拆分共享视图模型。
没问题，请不要认为我的评论很粗鲁，因为这不是本意，但在这些情况下，这完全取决于您以及您想要如何设计您的软件，实际上并没有正确或错误的方式事实上
哦，这可不粗鲁，你说的对！我对 android 很陌生，所以我也知道我真的知道的很少，有时一个“未知的未知”会在以后严重地咬你。
这样的问题我总是觉得有点有趣，因为人们喜欢抛开 mvvm 和其他架构，试图遵循最新最好的模式，但你应该始终重视 1）一般逻辑和 2）坚实的架构原则。无论您遵循哪种架构，单一职责应该保持真实，尽管人们也可能将这一点过分。我不再关心这些类型的问题的一个原因，因为软件辩论是一个令人筋疲力尽的话题:)

标签： android viewmodel android-mvvm

【解决方案1】：

正如a_local_nobody 所说，如何设计应用和分配职责由您决定。

如果您正在寻找我们对您的哲学疑虑的意见，我不得不说，虽然Shared ViewModels 的概念非常普遍，但我不是一个忠实的粉丝。

在我的项目中，最常见和合乎逻辑的事情是每个 ViewModel 管理单个视图的逻辑。我总是将共享 ViewModel 视为规则的一个例外，因为滥用它们通常会导致代码耦合非常紧密、非常难以测试并且会产生意想不到的副作用。

【讨论】：

感谢您抽出宝贵时间回答。我会将视图模型分成两部分，每个片段一个。原则上，当它们被限定在它们各自的片段时，它将使内存使用率大大降低。根据关于视图模型的 Lyla Fujiwara 博客文章，您的 cmets 为每个 UI 组件制作一个视图模型似乎是正确的。 link。引用“通常，您将为应用程序中的每个屏幕创建一个 ViewModel 类”