Android MVVM 设计 - 我应该将我的视图模型 class 一分为二吗？
Android MVVM design - should i split my viewmodel class in two?
我的应用有 2 种截然不同的模式（设置和 运行 定时器）。
该应用允许用户在一个片段上进行多因素输入，一旦用户希望启动计时器，该应用就会切换到 运行ning 片段以显示有关其 运行ning 计时器的信息它的设置。
我为此设计了一个 MVVM 架构，我自己的 class 扩展了 ViewModel，我的共享视图模型有两种截然不同的逻辑类型，设置逻辑（检查、解析和修改不适当的用户输入）和 运行ning 计时器逻辑（根据用户输入管理 运行ning 计时器的所有逻辑、数据和状态）。
我的共享视图模型 class 并不小，因为检查用户输入的所有排列的过程很复杂。我想知道将所有这些逻辑放入一个视图模型 class 是不是一个坏主意？设置部分设计得很简单，所有设置状态都被保存（因此用户设置定时器的 10-20 秒似乎是合适的），而定时器被设计为允许 运行 几个小时，主要是屏幕关闭。
我是否应该将视图模型逻辑拆分为两个不同的视图模型 classes 以使 运行ning 计时器的内存效率更高？
我清楚地看到了关注点，一旦我设计和编程了我的 Room 数据库，只有 运行ning 计时器会将数据保存到数据库中。我想让片段 classes 尽可能轻量级。如果这是一个明智的设计选择，我需要小心两种状态之间的内存泄漏，否则我的目的就落空了。
编辑以区分 ViewModel 对象和共享视图模型想法
正如a_local_nobody所说，如何设计应用程序和分配责任由您决定。
如果您正在寻找我们对您的哲学疑惑的看法，我不得不说，尽管 Shared ViewModels 的概念非常普遍，但我不是忠实粉丝。
在我的项目中，最常见和合乎逻辑的事情是每个 ViewModel 管理单个视图的逻辑。我总是将 Shared ViewModels 视为规则的例外，因为 滥用它们通常会导致代码耦合非常紧密，非常难以测试并产生意想不到的副作用 .
我的应用有 2 种截然不同的模式（设置和 运行 定时器）。
该应用允许用户在一个片段上进行多因素输入，一旦用户希望启动计时器，该应用就会切换到 运行ning 片段以显示有关其 运行ning 计时器的信息它的设置。
我为此设计了一个 MVVM 架构，我自己的 class 扩展了 ViewModel，我的共享视图模型有两种截然不同的逻辑类型，设置逻辑（检查、解析和修改不适当的用户输入）和 运行ning 计时器逻辑（根据用户输入管理 运行ning 计时器的所有逻辑、数据和状态）。
我的共享视图模型 class 并不小，因为检查用户输入的所有排列的过程很复杂。我想知道将所有这些逻辑放入一个视图模型 class 是不是一个坏主意？设置部分设计得很简单，所有设置状态都被保存（因此用户设置定时器的 10-20 秒似乎是合适的），而定时器被设计为允许 运行 几个小时，主要是屏幕关闭。 我是否应该将视图模型逻辑拆分为两个不同的视图模型 classes 以使 运行ning 计时器的内存效率更高？
我清楚地看到了关注点，一旦我设计和编程了我的 Room 数据库，只有 运行ning 计时器会将数据保存到数据库中。我想让片段 classes 尽可能轻量级。如果这是一个明智的设计选择，我需要小心两种状态之间的内存泄漏，否则我的目的就落空了。
编辑以区分 ViewModel 对象和共享视图模型想法
正如a_local_nobody所说，如何设计应用程序和分配责任由您决定。
如果您正在寻找我们对您的哲学疑惑的看法，我不得不说，尽管 Shared ViewModels 的概念非常普遍，但我不是忠实粉丝。
在我的项目中，最常见和合乎逻辑的事情是每个 ViewModel 管理单个视图的逻辑。我总是将 Shared ViewModels 视为规则的例外，因为 滥用它们通常会导致代码耦合非常紧密，非常难以测试并产生意想不到的副作用 .