依赖注入和单元测试——使用静态帮助方法还是私有实例方法

Question

依赖注入和单元测试——使用静态帮助方法还是私有实例方法

4

从单元测试和依赖注入的角度来看，涉及到帮助方法时，通常采用什么标准？

下面是我的示例情况：

public class GoodiesController : Controller
{
   private IMyContext _context;

   public GoodiesController(IMyContext context)
   {
      _context = context
   }

   public async Task<IAction> GetThoseGoodies()
   { 
       if(YouLikeThemThisWay(Request.Path))
        {
           var result = await _context.GoGetThemThisWay()
        } else { }
    }

我的问题是，如果我可能会有一些类似 YouLikeThemThisWay 的方法，我是更适合将YouLikeThemThisWay(string path)作为某个类的静态帮助器还是私有实例方法呢？

- rethabile

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Carson · Accepted Answer

这真的取决于您的YouLikeThemThisWay(string path)方法所做的事情。我在使用静态方法时遵循以下规则：

它是否需要非基元依赖项？如果是，请勿使用静态方法。
它是否会影响应用程序的状态？如果是，请勿使用静态方法。
它是否扩展了您无法在内部访问的类或类型的功能（例如BCL类或原语）？如果是，请使用静态扩展！
它是否会影响单元测试-使它们更加困难-如果我无法模拟该例程？如果不是，则将其设置为静态！
它是否将被多个类型或类使用？如果是，则更适合设置为静态！
该例程是否执行某种IO操作，例如调用数据库或文件系统？如果是，则不要将其设置为静态。

基本上，易于测试且不影响状态的小助手函数通常可以设置为静态。如果涉及状态，该例程需要您通常注入的依赖项，或者该例程正在进行IO或IPC调用，则不要将其设置为静态。

依赖关系问题的一个警告是，从技术上讲，您可以使用方法注入来处理依赖关系，但我喜欢保持简单。您的方法可能可以设置为静态。

重用在静态中也是一个重要因素。如果该例程仅在一个类中使用，则将其设置为静态可能没有意义。我的大多数静态方法都存在于易于访问任何地方的帮助程序类中。

编辑：请注意，我通常需要五个规则中的大多数或全部来支持静态，以便我甚至考虑使某些内容静态。