c# - 依赖注入(inject)/SOLID 担忧

Question

我有一个用 C# 编写的 Web API 应用程序。我正在努力确保设计遵循 SOLID 原则。因此，我使用 Unity 将依赖项注入(inject)我的 Controller 。但是我想从 Controller 本身中获取 Controller 执行的操作，因此它们基本上只是调用其他(通常是静态的)对象的方法。例如:

public class MyController : ApiController
{
    private readonly ISomeCrossCuttingInterface _instance;
    private readonly ILog _log;

    public MyController(ISomeCrossCuttingInterface someInterface, ILog log)
    {
        _instance = someInterface;
        _log = log;
    }

    [HttpPost]
    [ActionName("MyAction")]
    public RequestResponse MyAction(MyActionData actionData)
    {
        try
        {
            return MyActionUser(actionData);
        }
        catch (Exception ex)
        {
            _log.Error("MyAction error", ex);
        }
        return ...;
    }

    private RequestResponse MyActionUser(MyActionData actionData)
    {
        var responseObj = StaticClass.SomeMethod(_instance, actionData);
        var responseObj2 = StaticClass2.SomeMethod(_instance, responseObj2);
        return CreateMyActionResponse(responseObj2);
    }

    private RequestResponse CreateMyActionResponse(...)
    {
        ...
    }
}

我感到有些焦虑的是用于执行工作的对象(例如上面的 StaticClass 和 StaticClass2)是否应该实际注入(inject)。目前他们不是。被注入(inject)的对象是那些与横切关注点相关的对象，例如日志记录或数据访问，或者被多个 Controller 使用的对象。那么为什么我不注入(inject)执行工作的对象呢？我认为这些“内部”对象仅用于执行与一个 Controller 相关的特定工作。也就是说， Controller 的功能基本上已经分解为具有单一职责的对象，每个 Controller 都有自己独特的一组对象，可以执行 Controller 需要做的任何事情。然而，这是一个糟糕的设计吗？无论如何都应该注入(inject)所有对象吗？非常感谢任何意见。

Answer 1

使用 SOLID 原则已被广泛接受，它将使您的代码更易于维护、可测试和灵活。如果您使用其中一些原则，总比什么都不使用要好。

试着想一想如果您想以某种方式更改静态类会发生什么。您可以确信更改不会破坏您的 Controller 之一吗？您可以对静态类进行单元测试，对 Controller 进行一些单元测试，但是您需要集成测试来检查它们是否协同工作。如果改为注入(inject)静态类，则可以轻松进行单元测试以检查方法是否被调用、返回正确的结果等。

此外，您并不真的希望您的 Controller 执行此逻辑，它应该很好且精简，因此将所有内容放入服务中并让服务处理逻辑、调用存储库等。然后将服务注入(inject) Controller 。