【发布时间】：2014-08-11 11:10:33
【问题描述】：
在大多数任意应用程序中，需要在所有可用层之间解决许多横切问题，例如日志记录、消息总线、配置。我注意到，在某些类中，如果使用 IoC 注入模块，它们往往会完全炸毁构造函数。
public class MyService : IService
{
public MyService(ILogger logger, IAppSettings settings, IEventBus eventBus...)
{
}
}
对于构造函数过度注入的常见情况，我倾向于将关注点重构为紧密相关的构建块，因此我在类中获得更少的依赖关系。但是，这对于横切概念是不可能的。
在日志框架中，静态工厂/服务似乎非常流行，例如
// Application root
MyLoggerService.SetFactory(log4NetFactory);
// Somewhere
MyLoggerService.GetLogger("name") // returns Log4NetLogger created by Log4NetFactory.
我的问题是：这种方法适用于各种横切的东西吗？如果代码最终看起来像这样，有什么缺点：
public class MyService : IService
{
private readonly IReallyNeedThat _dependency;
public MyService(IReallyNeedThat dependency)
{
_dependency = dependency;
}
private readonly ILogger _logger = LoggerService.GetLogger("MyService");
private readonly IEventBus _eventBus = EventBusService.GetEventBus();
private readonly IConfiguration _configuration = ConfigurationService.GetConfiguration(Level.Roaming)
private readonly IExceptionHandler _exceptionHandler = ExceptionPolicy.GetHandler();
private readonly ITracer _tracer = TraceManager.GetDebugTracer();
}
【问题讨论】：
-
没有直接关系，但很有趣：stackoverflow.com/questions/1985717/….
-
@MarcelN。确实。这是 IMO 解决依赖/参数过多问题的正确方法。
-
@YuvalItzchakov 很好的例子，但是，正如你在第二个例子中看到的那样，作者将几个领域关注点捆绑到一个外观中，该外观执行特定的领域相关任务。我认为这对横切问题没有意义。我的意思是，在一个类中我需要一个记录器、一个异常处理程序和一个跟踪器，在另一个类中我需要一个记录器、一个跟踪器和一个事件总线。那么外墙会是什么样子呢？ ICoreServicesWithLogger、ICoreServicesWithoutEventBus、ICoreServicesForExceptions？
-
制作多个外观，并根据需要将适当的外观注入到类中。我要做的是将记录器、异常处理程序和跟踪器封装到一个外观服务中（只是因为它们的工作线看起来相似），然后将 that 外观注入另一个外观，其中还包括事件总线.
标签： c# design-patterns dependency-injection factory cross-cutting-concerns