我正在使用MVVM模式处理WPF项目，我想知道是否可以通过将其公开的属性抽象为单独的类来改进ViewModel的内部结构。
VM的常见做法是在同一个类中包含许多属性：一些用于检索用户输入，一些用于公开命令，另一些用于公开模型，可能还有一些其他属性对于视图模型自己的业务逻辑。更不用说这些属性经常设置并获取为包添加一些批量的实体。这可能会在VM类中迅速变得混乱，并且找到可能变得具有挑战性的方法。
作为解决此问题的一种方法，我正在与我的团队一起探索将VM内的属性分组到不同类别的想法。作为第一种方法，我选择以这种方式对它们进行分组：
ViewData ， UserInputs 和命令，每个都由自己的类表示。然后我将它们作为VM类中的属性引用。
我的意图是这些类只会充当占位符，以释放我的虚拟机中的膨胀并保持其清洁，并仅关注用于处理用户事件的交互逻辑。
这是一个简单的重构，但我得到以下优点：
让我详细说明后者：如果我想将文本框绑定到我的VM的属性，我知道绑定表达式应该以{{1}}开头。如果我需要从我的VM显示一个值，我知道我的绑定入口点将是Userinput.MyVMProperty。绑定intellisense也会变得更好，因为当你知道你的入口点，
建议清单会更小，更集中。这也是另一种方式：当读取XAML控件时，任何以UserInput开头的绑定都必然意味着它是一个应该将数据发送回VM的控件。
我能找到的唯一缺点是，这需要为每个虚拟机创建额外的课程，但我相信为你获得的好处付出的代价是合理的。
请注意，我建议的分组可能不是最好的，但我不介意任何其他分组，只要它解决了庞大虚拟机的问题。
那么，有没有人尝试过类似的模式？你认为这是一个好主意/实践吗？我可以用什么其他好的做法来改进我的虚拟机？
奖金问题：我的团队中的一位开发人员似乎同意这个想法，他建议加倍努力，将分组的类视为VM依赖项，并将它们注入VM中。你怎么看待这个？
答案 0 :(得分：0)
因此，对于每个ViewModel，您需要为每个组创建自己的内部类。您无法使用Interfaces，因为ViewModel具有不同的属性和命令
然后你考虑过每一个＆＃34; groupclass＆＃34;必须＆＃34;知道＆＃34;关于ViewModel的其他群组将正常运作。
在我看来，Class应该是具有最小外部依赖性的坚实逻辑结构。
基于您尝试实现的专业人员，我可以在不改变ViewModel类结构的情况下建议另一种方法
可读性可部分由#regions实现。
或者使用Partial class分隔不同文件中的不同组，
同时将它们保持在一个逻辑结构内
Intellisense可以通过命名便利来改进 - 使用基于组属性的前缀属于。例如UserInputMyName，ViewDataFullName或CommandDelete