对于记录器,安全性,配置等基础设施项目,如果这些事情真的被注入到需要它们的每个类中,或者应该将它们注入服务定位器,然后类可以使用服务定位器来解决依赖关系(或者一些其他机制
所有具有10个参数ctors的类通过DI来满足依赖性,这看起来非常荒谬.它的代码闻到了IMO.我可以理解存储库或服务代理/连接器之类的东西,但不能记录日志.
这一切都取决于您在基础架构和其余代码之间划分界限的位置.您认为数据库连接是基础架构吗？我不.属性注入是一种代码味道,因为它隐藏了依赖关系,并且在构造函数完成时类未正确初始化.仅用它来解决循环依赖关系.
对于非常具体的日志记录,我使用单例来获取记录器.
Normaly I would agree with you on AOP, but I’m not a fan of runtime AOP frameworks and the team doesn’t understand AOP concepts. They barely understand IoC concepts
您可能会发现我的IoC introduction很有用.