将视图模型属性分组到不同的类别中是一个好的实践吗?

我正在使用MVVM模式的WPF项目上工作，我想知道我是否可以通过将其暴露的属性抽象为单独的类来改善我的ViewModel的内部结构。

vm通常在同一个类中包含许多属性:一些用于检索用户输入，一些用于公开命令，另一些用于公开模型，可能还有一些其他属性用于视图模型自己的业务逻辑。更不用说这些属性通常具有set和get主体，从而增加了包的体积。这很快就会在VM类中变得混乱，并且找到一个方法可能会变得具有挑战性。

作为解决这个问题的一种方法，我正在与我的团队探索将VM中的属性分组到不同类别的想法。作为第一种方法，我选择这样分组:

ViewData、UserInputs和Commands，每一个都由它自己的类表示。然后我引用它们作为我的VM类中的属性。

我的意图是，这些类将只充当占位符，以释放虚拟机中的膨胀，并保持它的干净，并只关注处理用户事件的交互逻辑。

这是一个简单的重构，但我得到以下优点:

• 更干净和可读的VM。
更容易从XAML绑定，因为您知道入口点是/应该是什么。

让我详细说明后一个:如果我想将文本框绑定到VM的属性，我知道绑定表达式应该以Userinput.MyVMProperty开头。如果我需要显示来自VM的值，我知道绑定的入口点将是ViewData.MyOtherVMProperty。绑定智能感知也会变得更好，因为当你知道你的入口点时建议清单会更小，更集中。这也可以反过来工作:当读取XAML控件时，任何以UserInput开头的绑定都必然意味着它是一个应该将数据发送回VM的控件。

我能找到的唯一缺点是，这将需要为每个VM创建额外的类，但我相信这是为您获得的好处付出的合理代价。

请注意，我建议的分组可能不是最好的，但我不介意任何其他分组，只要它能解决庞大的虚拟机的问题。

那么，有人尝试过类似的模式吗?你认为这是个好主意/好做法吗?我可以使用哪些其他好的实践来改进我的vm ?

附加问题:我团队中的一个开发人员似乎同意这个想法，他建议多走一段路，将分组类视为VM依赖项，并且需要将它们注入VM中。你觉得这个怎么样?