我有一个应用程序，有两种截然不同的模式，(设置和运行计时器)。
该应用程序允许用户对一个片段进行多因素输入，一旦用户想要计时器启动，应用程序切换到运行片段以显示有关其运行计时器及其设置的信息。我为此设计了一个MVVM架构，用我自己的类扩展ViewModel，我的共享视图模型有两种明显不同类型的逻辑，设置逻辑(检查，解析和修改不适当的用户输入)，和运行计时器逻辑(从用户输入管理所有的逻辑，数据和运行计时器的状态)。
我的共享视图模型类并不小，因为检查用户输入的所有排列的过程是复杂的。我想知道这是一个坏主意，把所有这些逻辑到一个视图模型类?设置部分被设计得很简单，所有的设置状态都被保存(所以用户设置计时器的10-20秒似乎是合适的)，而计时器被设计成允许运行几个小时，主要是在屏幕关闭的情况下。 我是否应该将视图模型逻辑拆分为两个不同的视图模型类，以使运行计时器更有效地利用内存?我看到了一个清晰的关注点分离，一旦我有我的房间数据库设计和编程，只有运行计时器将数据保存到数据库。我想保持片段类尽可能轻量级。如果这是一个明智的设计选择，我需要小心两种状态之间的内存泄漏，否则就会破坏目的。
编辑以区分ViewModel对象和Shared ViewModel idea
正如a_local_nobody所说，如何设计你的应用并分配责任是由你来决定的。
如果你在寻找我们对你的哲学疑问的看法，我不得不说，尽管共享视图模型的概念非常广泛，但我不是一个大粉丝。
在我的项目中，最常见和合乎逻辑的事情是每个ViewModel管理单个视图的逻辑。我总是将共享视图模型视为规则的例外，因为滥用它们通常会导致代码非常紧密耦合，非常难以测试并且具有意想不到的副作用.