【问题标题】:How to Force DI style如何强制 DI 风格
【发布时间】:2015-03-18 11:45:08
【问题描述】:

我们正在构建一个 ASP.NET MVC 5 Web 应用程序。 我们可以使用 IoC 容器来解决服务依赖关系,但新的/无知的开发人员仍然可以在需要时创建服务类的实例,而不是使用 DI 框架来解决它。

是否有任何方法(Visual Studio 中的代码规则配置)或工具 来阻止(通过给出警告或错误)开发人员使用“new”关键字创建服务类的实例。 谢谢。

【问题讨论】:

  • 这对我来说似乎是一种自我挫败的目标。为此,您必须教您的“新/无知”开发人员使用该工具来验证其代码的质量。或者你可以让它在他们提交代码时自动检查代码?教您的开发人员改用 IoC 并为他们提供这样做的理由和动机不是更好吗?
  • 我理解您的观点...但我认为最好有防呆系统。此外,我相信爱因斯坦所说的“两件事是无限的:宇宙和人类的愚蠢”(包括我)。
  • 你使用 Resharper 吗?如果是这样,您可以将其配置为对此发出警告。
  • 如果你能设计一个万无一失的系统那就太好了——我只是不确定这是否可行。在最坏的情况下,错误的安全感可能只会让事情变得更糟。换句话说:如果您无知的程序员想做一些愚蠢的事情,他们可能会忽略您提供的任何警告,并继续前进。也就是说,当然,除非您解释使用 IoC 的必要性和好处,否则他们有正确的动机。 PS:如果我没记错的话,爱因斯坦对宇宙是不确定的
  • @Kjartan 你是对的。谢谢。

标签: c# asp.net-mvc oop design-patterns dependency-injection


【解决方案1】:

您不能强迫使用工具的开发人员这样做。他们总会想办法绕过你的“愚蠢”工具。相反,你应该以身作则,教导他们,训练他们。进行代码审查并解释为什么您所建议的方法是可行的。

【讨论】:

  • 显然,我们必须为令人敬畏的事物进行教学和训练。但有时可能会犯愚蠢的错误。所以要避免这些......有没有办法在 Visual Studio 中使用或不使用第三方工具来显示至少警告?
  • @PraveenPrajapati:永远记得首选Individuals and interactions over processes and tools。如果你不能让团队服从,工具将无济于事。而且由于您的要求似乎特别是“没有第三方工具”,因此唯一的解决方案是:进行代码审查。
  • 当然...同意你的看法 :-) 有工具很好...(否则为什么有这么多工具并推荐给工匠?)
  • @Steven。我不同意。您可以使用工具来指导并最终符合要求。但是,我同意这些工具只能做这么多。
  • DO CODE REVIEWS 本身应该是一个答案......这是一个过程问题,而不是工具问题。
【解决方案2】:

使用 Resharper 代码检查。添加自定义模式以查找您要警告开发人员的事情。然后,所有开发者都可以共享这些设置。

示例:https://www.jetbrains.com/resharper/webhelp80/Reference__Add_Edit_Highlighting_Pattern.html

我想您需要定义要注入的类型,然后将它们添加到您的模式中。

【讨论】:

  • 这很有趣。您能否举例说明在这种情况下可能对 OP 有用的自定义模式?
  • 我认为这说起来容易做起来难(尽管我完全不熟悉这个 R# 功能)。通常,您要检查“某些类型的类”是否不是作为单例的引用,而是使用它们的接口注入到构造函数中。这里的问题实际上是如何定义那些“某些类型的类”以及如何检测它们是引用并直接更新而不是通过它们的接口注入。我不确定模板模式是否足够灵活,可以进行这种深入分析。
  • 我同意大卫,确实值得深思。
【解决方案3】:

如果您有天真/无知的开发人员,那么糟糕的代码就会溜进您的项目。您应该更改您的流程,以便在错误代码进入您的存储库之前需要进行代码审查。

请注意,这里的“无知”并不意味着愚蠢或糟糕的开发人员。这只是意味着那些不知道有更好的方法来做某事的人。一旦你教给他们更好的方法,并且他们知道这是对他们的期望,就会削弱他们的无知。

你可以做的事情:

  1. 让所有初级开发人员必须提交拉取请求才能提交更改。然后,高级/首席开发人员必须审核更改并接受或拒绝更改请求。

  2. 将您的接口放在一个命名空间下,将服务实现放在不同的命名空间下。在审查时,扫描服务命名空间的文件,如果在不应该使用的任何地方使用它,则拒绝拉取请求。

  3. 每当您发现违反您要强制执行的规则的行为已进入您的存储库时,请运行 BLAME 以找出是哪个开发人员引入了错误代码。和那个人谈谈。找出他们为什么这样做,而不是你喜欢的方式。向他们展示为什么最好按照自己的方式去做。

  4. 对您的代码进行单元测试。有时,当服务实现被硬编码到被测方法中而不是模拟服务的接口时,使测试通过可能会更加困难。

我喜欢@David Osborne's R# idea,但开发人员始终可以暂停 R#,或完全关闭它。归根结底,这是一个过程问题。 I agree with @Steven 你应该以身作则,教导和培训。通过分享你的知识来建立你的团队,不要因为做错事而惩罚他们而拖累他们。

【讨论】:

    【解决方案4】:

    我得到了一个更好的页面来解释如何在 ReSharper 中创建自定义代码检查https://www.jetbrains.com/resharper/webhelp80/Code_Inspection__Creating_Custom_Inspections_and_QuickFixes.html

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-12-03
      • 1970-01-01
      • 2016-03-20
      • 2010-09-28
      • 1970-01-01
      • 1970-01-01
      • 2021-12-02
      相关资源
      最近更新 更多