Question

从单元测试和依赖注入的角度来看，在辅助方法方面通常采用什么规范？

以下是我的示例情况：

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(string path)作为某个类中的静态助手还是作为私有实例方法？假设我可能有几个YouLikeThemThisWay？

Answer 1

这实际上取决于您的YouLikeThemThisWay(string path)方法的功能。我使用静态方法的规则如下：

是否需要非原始依赖？如果是这样，请不要使用静态。
它会影响应用程序的状态吗？如果是这样，请不要使用静态。
它是否扩展了您无法在内部访问的类或类型的功能（IE BCL类或主要内容）？如果是这样，请使用静态扩展名！
它是否会影响单元测试 - 如果让它们变得更加困难 - 如果我不能模拟例程？如果不是，那就让它静止！
是否会被多种类型或类别使用？如果是这样，它使它成为更好的静态候选者！
例程是否执行某种IO，例如调用数据库或文件系统？如果是这样，我就不会让它变得静止。

基本上，小助手功能很容易测试，不会影响状态，或者通常可以制作静态。如果涉及到状态，则例程需要您通常会注入的依赖项，或者例程正在进行IO或IPC调用，然后不要使其静态。

依赖性问题的一个警告是技术上你可以使用方法注入来处理依赖项，但我喜欢保持简单。你的方法可能是静态的。

重用也是静力学中的一个重要因素。如果例程只在一个类中使用，那么静态化可能毫无意义。我的大多数静态方法都存在于可以在任何地方轻松访问的辅助类中。

编辑：请注意，我通常要求这五条规则中的大部分或全部都支持静态，以便我甚至考虑制作静态的东西。

依赖注入和单元测试 - 静态辅助方法或私有实例方法

1 个答案: