MVVM程序复杂性的代码度量KPI

代码分析可以给出一些统计数字，这些数字不是决定性的，但如果您看到一些设计缺陷或糟糕的编码实践，那么从一开始就很好。 这样的KPI可能是一个类中有多少个方法，或者if/else的级别如何使用

MVVM程序是否有一些代码度量

例如，我在上一个项目中注意到的一件事是，每个类听起来不大，但有一个树使得可能的工作流非常复杂： ViewModel命令=>Business Method=>ViewModel属性=>ViewModel“导航属性”（隐藏/显示/折叠/展开） 注意：我称之为“导航属性”，因为整个MVVM项目的导航是基于MVVM绑定的，但是将一些VM属性设置为隐藏/显示/折叠/扩展，GUI是导航的

---

是否存在MVVM可能会陷入的一些特殊设计“陷阱”，以及需要关注的KPI？

作为一种习惯，我喜欢运行“计算代码度量”。 （右键单击项目并选择visual studio 2010中的计算代码度量） 可维护性指数和CLycomatic复杂度分数为您提供了一些KPI指标

使用MVVM，即使您的“树工作流”更长，但如果操作正确，也会比通过其他机制更简单。我建议在大多数情况下，MVVM中的树也会更短

话虽如此，生成大量事件可能会导致应用程序速度减慢，因此只有在属性值发生更改时才使用“属性更改事件”（在属性设置器中明确检查它是否不同）是一种良好的做法