依赖注入的基础
我们都知道DI,,他是一种开发模式。他是将服务可被应用程序任何位置的代码使用,当某个代码组件(如一个类)需要引用某些外部代码(一个服务)时。都有两种选择
1:直接在调用代码种创建服务组件的一个新实例。
2:收到该服务的一个有效实例。
比如一个操作是记录操作记录。那么看以下代码。业务逻辑和记录操作紧密耦合
public void Home() { var log=new Logger(); log.Log("Waring"); }
如果该类移动到其他位置,那么必须也要移动所有引用和依赖,如果有数据库操作。那么使用的地方都要有数据库连接,
如果解耦
private readonly ILogger _logger; public HomeController(ILogger logger) { _logger = logger; } public void Home() { var log=new Logger(); log.Log("Waring"); }
将其抽象为ILogger 接口,通过构造函数注入。
当然如果过度使用依赖注入,那么会有这样。依赖的有其他的依赖。以此类推。
可以使用DI框架。同时也叫IOC框架
var logger=SomeFrameworkIoC.Resolve(typeof(ILogger));
Service Locator模式
松耦合调用外部依赖,并非只有依赖注入。还有Service Locator。它能够创建与指定抽象类型匹配的实例。DI和它的关键区别在于,DI要求相应地设计外围代码;构造方法与其他方法的签名可能会发生变化。而它保守。 可读性差一点。当庞大的现有代码库种重构依赖时,它是一个理想选择。
如下:
public void Perform() { var logger=HttpContext.RequestService.GetService<ILogger>(); }
这是RequestService对象在HTTP上下文中扮演了Service Locator角色。
当然依赖注入的生命周期。大家想必都有所了解。我这里简单说一下