首先，在Web API服务的项目上，添加对Serilog.Extensions.Logging.File的nuget包，使用它能够非常方便地启用基于文件的日志。然后，打开Program.cs文件，添加ConfigureLogging的调用：
public static IWebHost BuildWebHost(string[] args) => WebHost.CreateDefaultBuilder(args) .ConfigureLogging((context, lb) => { lb.AddFile(LogFileName); }) .UseStartup<Startup>() .Build();此处LogFileName为本地文件系统中的日志文件文件名，为了避免权限问题，我将日志写入C:\Users\<user>\appdata\local目录下，因为我的Web API进程是由当前登录用户启动的，所以写在这个目录下不会有权限问题。如果今后我们把Web API host在IIS中，那么启动IIS服务的用户需要对日志所在的目录具有写入的权限，日志文件才能被正确写入，这一点是需要注意的。
好了，现在可以使用日志了，先试试看。在Startup类的构造函数中，加入ILoggerFactory参数，并在构造函数执行时获取ILogger实例，然后在ConfigureServices调用中输出一些内容：
public class Startup { private readonly ILogger logger; public Startup(IConfiguration configuration, ILoggerFactory loggerFactory) { Configuration = configuration; this.logger = loggerFactory.CreateLogger<Startup>(); } public IConfiguration Configuration { get; } public void ConfigureServices(IServiceCollection services) { this.logger.LogInformation("正在对服务进行配置..."); services.AddMvc(); services.AddTransient<IEventHandler, CustomerCreatedEventHandler>(); services.AddTransient<IEventStore>(serviceProvider => new DapperEventStore(Configuration["mssql:connectionString"])); services.AddSingleton<IEventBus, PassThroughEventBus>(); this.logger.LogInformation("服务配置完成，已注册到IoC容器！"); } // 其它方法暂时省略 }现在重新启动服务，然后查看日志文件，发现日志可以被正确输出：
接下来，使用类似的方式，向PassThroughEventBus的构造函数和Dispose方法中加入一些日志输出，在CustomersController的Create方法中、CustomerCreatedEventHandler的构造函数和HandleAsync方法中、DapperEventStore的构造函数和Dispose方法中也加入一些日志输出，以便能够观察当新的客户信息被创建时，Web API的执行过程。限于文章篇幅，就不在此一一贴出各方法中加入日志输出的代码了，大家可以根据本文最后所提供的源代码链接来获取源代码。简单地举个例子吧，比如对于DapperEventStore，我们通过构造函数注入ILogger的实例：
public class DapperEventStore : IEventStore { private readonly string connectionString; private readonly ILogger logger; public DapperEventStore(string connectionString, ILogger<DapperEventStore> logger) { this.connectionString = connectionString; this.logger = logger; logger.LogInformation($"DapperEventStore构造函数调用完成。Hash Code：{this.GetHashCode()}."); } // 其它函数省略 }这样一来，在DapperEventStore的其它方法中，就可以通过logger来输出日志了。
发现问题同样，再次运行Web API，并通过Powershell发起一次创建客户信息的请求，然后打开日志文件，整个程序的执行过程基本上就一目了然了：
从上面的日志内容可以得知，当应用程序正常退出时，由IoC容器托管的PassThroughEventBus和DapperEventStore都能够被正常Dispose，目前看来没什么问题，因为资源可以正常释放。现在让我们重新启动Web API，连续发送两次创建客户信息的请求，再次查看日志，我们得到了下面的内容：
从上面的日志内容可以看到，在Web API的整个运行期间，CustomerCreatedEventHandler仅被构造了一次，而且在每次处理CustomerCreatedEvent事件的时候，都是使用同一个DapperEventStore实例来保存事件数据。也就是说，CustomerCreatedEventHandler和DapperEventStore在整个Web API服务的生命周期中，有且仅有一个实例，它们是Singleton的！然而，在进行系统架构的时候，我们应该尽量保证较短的对象生命周期，以免因为状态的不一致性导致不可回滚的错误出现，这也是架构设计中的一种最佳实践。虽然目前我们的DapperEventStore在程序正常退出的时候能够被Dispose掉，但如果DapperEventStore使用了非托管资源，并且非托管资源并没有很好地管理自己的内存呢？久而久之，DapperEventStore就产生了内存泄漏点，慢慢地，Web API就会出现内存泄漏，系统资源将被耗尽。假如Web API被部署在云中，应用程序监控装置（比如AWS的Cloud Watch）就会持续报警，并强制服务断线，整个系统的可用性就无法得到保障。所以，我们更期望DapperEventStore能够正确地实现C#的Dispose模式，在Dispose方法中合理地释放资源，并且仅在需要使用DapperEventStore时候才去构建它，用完就及时Dispose，以保证资源的合理使用。这也就是为什么我们使用services.AddTransient方法来注册CustomerCreatedEventHandler以及DapperEventStore的原因。