MVC中代码分析规则集CA1506的最佳解决方案是什么（我不想压制）

Question

我正在使用MVC3。运行代码分析时出现以下错误。

  

CA1506：Microsoft.Maintainability：'MyController'与94结合使用   来自25个不同命名空间的不同类型。重写或重构这个   class减少类耦合或考虑移动的方法   一些类的方法对于其他一些类型的方法是紧密的   加上。高于95的类耦合表示差   可维护性，95到80之间的类别耦合表示中等   可维护性，低于80的类耦合表明良好   可维护性。

这是一个控制器类。

我是否知道减少控制器的类耦合的最佳解决方案是什么？

Answer 1

正如@musefan所提到的那样，你需要重构它。我刚刚看了一个我正在使用的项目中的控制器，我认为它处于缺乏凝聚力和需要重构的边界线上，并且它与大约40种类型相结合。

再看看它所服务的系统的控制器和区域，看看你是否可以把它分成更少，更有凝聚力的类。

修改

关于为Word，PDF和Excel提供导出功能的Controller，我认为这意味着你的Controller中有逻辑，它知道组合Word导出，PDF导出和Excel导出的细节，包括某些方面你抽象出来的三种格式之间的共同点（页眉和页脚）。

如果我已经正确理解了这一点，那么您可以考虑的一个重构是将与页眉，页脚，结构和格式相关的所有逻辑移动到接口后面的不同类中，并让您的Controller引用该接口而不是引用管理这些方面的各种类。这会将从控制器到各种类的耦合移动到其接口后面的新文档处理类中，并且可能将耦合类的数量降低到低于FxCop可接受的级别。

Answer 2

听起来你的控制器太重了。我不知道这一定意味着你需要将功能分成多个控制器。相反，我怀疑这意味着你已经用很多逻辑加载了你的控制器。人们倾向于避免这种情况有几个原因，其中最重要的是它使控制器更难以测试。更重要的是，通常表明通常位于可重复使用的业务层中的逻辑已经流入您的控制器层。鉴于控制器是特定于mvc的，因此您将业务层耦合到一个与表示层无关的层。

因此，我的建议是仔细查看您的控制器，看看您是否可以进行战略性重构。将业务逻辑移动到新的业务逻辑层（服务层），我怀疑这自然会解决这个问题。

Answer 3

您应该按照Jimmy Bogard在此视频中说明的那样对您的控制器进行节食：http://www.viddler.com/v/b568679c

与来自25个不同命名空间的94种不同类型的耦合似乎绝对是噩梦。我甚至无法想象你的控制器是怎样的。

记住：添加类并将责任分成类很便宜。将所有代码放在一个类中是维护的噩梦。它起初可能看起来很便宜，但相信我，它会很快变得像地狱一样。