代码分析可以提供一些统计数字，这些数字不是决定性因素，但如果您正在查看某些设计缺陷或错误的编码实践，则可以从一开始就很好。 这样的KPI可能是一个类中有多少个方法，或者if / else的级别如何使用......
MVVM程序是否有一些代码指标？
例如，我在上一个项目中注意到的一件事是，每个类听起来都不大，但是有一棵树使得可能的工作流非常复杂： ViewModel Command =＆gt;商业方法=＆gt; ViewModel Properties =＆gt; ViewModel“导航属性”（隐藏/显示/折叠/展开） 注意：我将其称为“导航属性”，因为整个MVVM项目的导航基于MVVM绑定，但将某些VM属性设置为hidden / shown / collapse / expand，GUI将被导航。是否存在一些MVVM可能陷入的特殊设计“陷阱”，以及KPI要观察的内容？
答案 0 :(得分：0)
作为一般习惯，我喜欢运行“计算代码指标”。 （右键单击项目并选择Visual Studio 2010中的计算代码度量标准） 可维护性指数和clyclomatic复杂性分数为您提供KPI的一些指示。
使用MVVM，即使你的“树工作流程”更长，如果做得好，它也会比通过其他机制更简单。我建议大多数时候，MVVM中的树也会更短。
话虽如此，生成大量事件可能会导致您的应用放慢速度，因此最好只在属性更改值时使用“提升属性更改事件”（明确检查它是否有所不同）财产制定者）