我正在使用 MVC3。运行代码分析时出现以下错误。
CA1506:Microsoft.Maintainability:“MyController”与来自 25 个不同命名空间的 94 种不同类型相结合。重写或重构该类的方法以减少其类耦合,或考虑将某些类的方法移至与其紧密耦合的某些其他类型。95 以上的类耦合表示可维护性差,95 到 80 之间的类耦合表示可维护性中等,80 以下的类耦合表示可维护性好。
这是一个控制器类。
我可以知道减少控制器类耦合的最佳解决方案是什么?
我正在使用 MVC3。运行代码分析时出现以下错误。
CA1506:Microsoft.Maintainability:“MyController”与来自 25 个不同命名空间的 94 种不同类型相结合。重写或重构该类的方法以减少其类耦合,或考虑将某些类的方法移至与其紧密耦合的某些其他类型。95 以上的类耦合表示可维护性差,95 到 80 之间的类耦合表示可维护性中等,80 以下的类耦合表示可维护性好。
这是一个控制器类。
我可以知道减少控制器类耦合的最佳解决方案是什么?
正如@musefan 所提到的,听起来你需要重构。我刚刚查看了一个我正在使用的项目中的控制器,我认为它处于缺乏凝聚力和需要重构的边缘,并且它与大约 40 种类型相关联。
再看看控制器和它所服务的系统区域,看看你是否可以把它分成更少、更有凝聚力的类。
编辑
关于您的控制器为 Word、PDF 和 Excel 提供导出功能,我认为这意味着您的控制器中有逻辑,它知道将 Word 导出、PDF 导出和 Excel 导出放在一起的详细信息,包括您抽象出来的三种格式(页眉和页脚)。
如果我正确理解了这一点,您可以考虑的一种重构是将与页眉、页脚、结构和格式相关的所有逻辑移动到接口后面的不同类中,并让您的控制器引用该接口而不是引用各种类管理这些方面。这会将与控制器的各种类的耦合转移到其接口后面的新文档处理类中,并且可能会将耦合类的数量降低到 FxCop 认为可接受的水平以下。
听起来你的控制器太重了。我不知道这一定意味着您需要将功能拆分为多个控制器。相反,我怀疑这意味着您已经为控制器加载了很多逻辑。人们倾向于避免这种情况有几个原因,其中最重要的是它使控制器更难测试。更重要的是,这通常表明通常在可重用业务层中的逻辑已经渗入您的控制器层。鉴于控制器是特定于 mvc 的,因此当涉及到表示层时,您将业务层耦合到一个不可知的层。
因此,我的建议是仔细查看您的控制器,看看您是否可以战略性地重构。将业务逻辑移动到一个新的业务逻辑层(服务层),我怀疑这自然会解决这个问题。
您应该像 Jimmy Bogard 在此视频中说明的那样节食控制器:http: //www.viddler.com/v/b568679c
与来自 25 个不同命名空间的 94 种不同类型进行耦合似乎绝对是噩梦。我什至无法想象你的控制器是什么样子的。
请记住:添加类并将职责分离到类中很便宜。将所有代码放在一个类中是一场维护噩梦。一开始它可能看起来很便宜,但相信我,它很快就会变得像地狱一样。