ASP.NET + MVC5 入门完整教程三 (下) ---MVC 松耦合

2021-04-23 01:27

阅读：680

标签：重要 send 关心之一测试 container class 实例化 nbsp

建立松耦合组件
MVC 模式最重要的特性之一视他支持关注分离，希望应用程序中的组件尽可能独立，只有很少的几个可控依赖项。在理想的情况下，每个组件都不了解其他组件，而只是通过抽象接口来处理应用程序的其他区域，这就称为“松耦合”，它使得的应用程序更易于测试和修改。

举一个简单的例子：假设正在编写一个名称为“MyEmailSender”组件用来发送邮件，笔者会实现一个接口，他定义了发送邮件所需要的所有 Public 函数，该接口称为 “IEmailSender”(也就是说IEmailSender是一个接口，MyEmailSender是该接口的一个具体实现)。

应用程序中需要发送电子邮件的任何其他组件，如“PasswordResetHelper”的口令重置辅助程序，那么只需要通过引用该接口中的方法便可以发送一份邮件，而在 PasswordResetHelper 和 MyEmailSender 之间没有直接的依赖关系。如下图表示：

技术图片

通过引入 IEmailSender ，保证了 PasswordResetHelper 与 MyEmailSender 之间没有直接的依赖项，这样，编程人员可以完全使用另一个邮件发送程序来替换 MyEmailSender 甚至可以用一个模仿实现以进行测试，而无需对 PasswordResetHelper 做任何修改。关于模仿实现，敬请关注

依赖项注入
接口有助于解除组件耦合，这里人面临一个问题：C#未提供内置方法，以方便地创建实现接口对象，除非以 new 关键字创建一个具体组建的实例。如下代码所示：

public class PasswordResethelper
{
public void ResetPassword()
{
IEmailSender mySender = new MyEmailSender();
//调用接口方法配置email
mySender.SendEmail;
}
}
这种写法破坏了无需修改 PasswordResetHelper 就能替代 MyEmailSender 的目的，这就意味着此刻仅处于组建松耦合的半途，PasswordResetHelper 通过 IEmailSender 接口来配置并发送电子邮件，但是，为了创建实现该接口，必须创建 MyEmailSender 的一个实例，但实际上，事情变更加糟糕，因为 PasswordResetHelper 现在依赖于 MyEmailSender 类以及 IEmailSender 接口，如图所示：
技术图片

现在需要有种方法，他能获得实现某一接口的对象，而不用去直接创建该对象，这一问题的解决方案称为“依赖项注入（Eependency Injection, DI）”,也称为控制反转（Inversion of Control，IoC）。

DI 是一种实现组件解耦的设计模式。

打断和声明依赖项
DI 模式有两个部分，第一个部分是从组件（此例中PasswordResetHelper）中除去对具体类的依赖项。做法：创建一个类构造器，以所需接口的实现作为其参数：

public class PasswordResethelper
{
private IEmailSender emailSender;
public PasswordResetHelper(IEmailSender emailSenderParam)
{
emailSender = emailSenderParam;
}
public void ResetPassword()
{
//调用接口方法配置email
mySender.SendEmail;
}
}
现在可以将 PasswordResetHelper 类的构造器称为对 IEmailSender 接口声明了一个依赖项，就是说，除非接受一个实现 IEmailSender 接口对象，否则不能创建和使用它。在依赖项声明中，PasswordResetHelper 类不在有 MyEmailSender 的任何相关点，它仅仅依赖于 IEmailSender 接口，简单说来，就是 PasswordResetHelper 不在关心如何实现 IEmailSender 接口。

注射依赖项
DI 模式的第二个部分是在创建 PasswordResetHelper 类实例时，注入由其申明的依赖项，故称为依赖项注入。这实际上意味着，对于打算使用的 IEmailSender 接口，需要决定是用哪一个类来实现，通过这个类创建一个对象，并将该对象作为参数传递给 PasswordResetHelper 构造器。

技术图片

这种依赖项实在运行时才被注入到 PasswordResetHelper 中，所以只有在 PasswordResetHelper 类实例化期间才会创建IEmailSender 接口的实现类实例，并将其传递给 PasswordResetHelper 构造器。PasswordResetHelper 与依赖接口的实现类之间不存在编译时的依赖项。
使用依赖项注入容器
解决了依赖项问题，但如何对接口的具体实现进行实例化而无须在应用程序的某个其他地方创建依赖项呢？所以任然需要以下语句：

...
IEmailSender sender = new MyEmailSender();
herper =new PasswordResetHelper(sender);
...

为了解决这个问题，引入“依赖项注入容器（Dependency Injection Container, 简称 DI 容器）”，也称为“IoC 容器”。这是一个组件，他在类（如 PasswordResetHelper）所声明的依赖项和用来解决这些依赖项的类（如 MyEmailSender）之间充当中间角色。

技术图片