SmtpClient 的文档现已改成:“废弃(“SmtpClient 及其相关类型设计很差,我们强烈建议使用 https://github.com/jstedfast/MailKit 和 https://github.com/jstedfast/MimeKit 替代。”)”。这是 Microsoft 有史以来第二次将一个.NET 类正式标为被开源软件库替代。
MailKit 和 MimeKit 的创建者是 Jeffrey Stedfast,InfoQ 曾在 2014 年采访过他。在当时,它们已被认为是.NET 上最全面的 MIME 和电子邮件库。
Newtonsoft 的 JSON.NET 是被 Microsoft 接受的首个重要开源库。JSON.NET 已在 ASP.NET Web API 中广泛使用,并被正式推荐为 Web API 使用的序列化类,通常可替代 JavaScriptSerializer 类。但是不同于 SmtpClient 的是,没有任何一个序列化类因此被标记为废弃。
SmtpClient 的主要问题在于连接生命周期管理混乱。由于连接 SMTP 服务器是一个非常耗时的操作,尤其是需要做认证时,因此每个 SmtpClient 对象都维护了一个内部连接池。
这是一个非常奇葩的设计。以典型的数据库连接为例,当在 SqlClient 命名空间中调用 Dispose 方法时,底层的连接会返回到连接池中。当新建一个 SqlClient 时,需要检查连接池中是否已具有连接串相同的活跃连接。
使用 SmtpClient 时,调用 Dispose 方法会关闭所有连接并清空对象的连接池。这意味着不能通过常规的“using”语句调用该方法。
你可能会想到,“那么我可以持续维护一个类似于 HttpClient 的共享实例”。但这也行不通。因为不同于在 HttpClient 中,Send 和 SendAsync 方法并非是线程安全的。除非你引入了自定义的同步模式,否则不能以这种方式使用 SmtpClient。事实上, SmtpClient 的文档中已给出了警告:
SmtpClient 无法判定一个应用何时能完成,何时应被清除。
相比之下, MailKit 的 SMTP 客户端表示的是一个到单个服务器的简单连接。它消除了由内部连接池所导致的复杂性。如果使用 MailKit 连接对象只需创建应用特定的连接池,这的确简化了操作。
虽然活跃的 MailKit 软件缺陷数非常少,但在对异步操作的真正支持上,它的确还存在着问题。要对已有软件库中添加异步操作,一般方法是拷贝全部方法并稍作修改以支持异步操作。在一些简单的应用中,这并非难事。但是对于邮件客户端这样的复杂应用,这会导致一场噩梦。当前MailKit 只是简单地调用了同步代码路径和阻塞线程,模拟了对异步操作的支持。
解决异步问题的方案现在仍未确定,一个正在考虑的方案是使用 AsyncRewriter 工具。它是一个基于 Roslyn 的工具,已被 PostgreSQL 团队用于将其同步代码转换为等价的异步代码。
评论