1、背景
最近，一个工作了一个月的同事离职了，所做的东西怼了过来。一看代码，惨不忍睹，一个方法六七百行，啥也不说了吧，实在没法儿说。介绍下业务场景吧，一个公共操作A，业务中各个地方都会做A操作，正常人正常思维应该是把A操作提取出来封装，其他地方调用，可这哥们儿偏偏不这么干，代码到处复制。仔细分析了整个业务之后，发现是一个典型的事件/消息驱动型，或者叫发布/订阅型的业务逻辑。鉴于系统是单体的，所以想到利用进程内发布/订阅的解决方案。记得很久之前，做WPF时候，用过Prism的EventAggregator（是不是暴露年龄了。。。），那玩意儿不知道现在还在不在，支不支持core，目前流行的是MediatR，跟core的集成也好，于是决定采用MediatR。
2.Demo代码
Startup服务注册：
publicvoidConfigureServices(IServiceCollectionservices){services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);services.AddScopedIService1,Service1();services.AddScopedIService2,Service2();services.AddScopedIContext,Context();services.AddMediatR(typeof(SomeEventHandler).Assembly);}
服务1：
publicclassService1:IService1{privatereadonlyILogger_logger;privatereadonlyIMediator_mediator;privatereadonlyIContext_context;privatereadonlyIService2_service2;publicService1(ILoggerService1logger,IMediatormediator,IContextcontext){_logger=logger;_mediator=mediator;_context=context;//_service2=service2;}publicasyncTaskMethod(){_context.CurrentUser="test";//await_service2.Method();//_service2.Method();await_mediator.Publish(newSomeEvent());//_mediator.Publish(newSomeEvent());awaitTask.CompletedTask;}}
可以看到，在服务1的method方法中，发布了SomeEvent事件消息。
服务2代码：
publicclassService2:IService2{privatereadonlyILogger_logger;privatereadonlyIContext_context;publicService2(ILoggerService2logger,IContextcontext){_logger=logger;_context=context;}publicasyncTaskMethod(){_logger.LogDebug("当前用户:{0}",_context.CurrentUser);awaitTask.Delay();//_logger.LogDebug("当前用户:{0}",_context.CurrentUser);_logger.LogDebug("Service2Methodat:{0}",DateTime.Now);}}
解释下，为啥服务2Method方法中，要等待5秒，因为实际项目中，有这么一个操作，把一个压缩程序包传递到远端，然后在远端代码操作IIS创建站点，这玩意儿非常耗时，大概要1分多钟，这里我用5s模拟，意思意思。这个5s至关重要，待会儿会详述。
再看事件订阅Handler：
publicclassSomeEventHandler:INotificationHandlerSomeEvent,IDisposable{privatereadonlyILogger_logger;privatereadonlyIServiceProvider_serviceProvider;privatereadonlyIService2_service2;publicSomeEventHandler(ILoggerSomeEventHandlerlogger,IServiceProviderserviceProvider,IService2service2){_logger=logger;_serviceProvider=serviceProvider;_service2=service2;}publicvoidDispose(){_logger.LogDebug("Handlerdisposedat:{0}",DateTime.Now);}publicasyncTaskHandle(SomeEventnotification,CancellationTokencancellationToken){await_service2.Method();//using(varscope=_serviceProvider.CreateScope())//{//varservice2=scope.ServiceProvider.GetServiceIService2();//awaitservice2.Method();//}}}
然后，我们的入口Action：
[HttpGet("test")]publicasyncTaskActionResultstringTest(){StringBuildersb=newStringBuilder();sb.AppendFormat("开始时间：{0}",DateTime.Now);sb.AppendLine();await_service1.Method();sb.AppendFormat("结束时间：{0}",DateTime.Now);sb.AppendLine();returnsb.ToString();}
至此，Demo要干的事情，脉络应该很清晰了：控制器接收HTTP请求，然后调用Service1的Method，service1的Method又发布消息，消息处理器接收到消息，调用Service2的Method完成后续操作。我们运行起来看下：
上述一切的一切，看似没问题。运行成功没？成功了。对不对？好像也对。有没问题？大大的问题！HTTP从开始到结束，要耗时5s，实际项目中，那是一分钟，这整整一分钟，你要前端挂起等待么一直？理论上，这种耗时的后端操作，合理做法是HTTP迅速响应前端，并返给前端业务ID，前端根据此业务ID长轮询后端查询操作结果状态，直至此操作完成，决不能一直卡死的，否则交互效果不说，超过一定时间，HTTP请求会直接超时的！这就必须动刀子了，将Service2操作后台任务化且不等待。Service1的Method代码调整如下：
publicasyncTaskMethod(){_context.CurrentUser="test";//await_service2.Method();//_service2.Method();//await_mediator.Publish(newSomeEvent());_mediator.Publish(newSomeEvent());awaitTask.CompletedTask;}
见注释前后，改进地方只有一处，发布事件代码去掉了await，这样系统发布事件之后，便不会等待Service2而是继续运行并立刻响应HTTP请求。好，我们再来运行看下效果：
我们看到，系统立即响应了HTTP请求（22:40:15），5s之后，Service2才执行完成（22:40:20）。看似又没问题了。那是不是真的没问题呢？我们注意，Service1和Service2中，都注入了一个Context上下文对象，这个对象是我用来模拟一些Scope类型对象，例如DBContext的，代码如下：
publicclassContext:IContext,IDisposable{privatebool_isDisposed=false;privatestring_currentUser;publicstringCurrentUser{get{if(_isDisposed){thrownewException("Contextdisposed");}return_currentUser;}set{if(_isDisposed){thrownewException("Contextdisposed");}_currentUser=value;}}publicvoidDispose(){_isDisposed=true;}}
里边就一个属性，当前上下文用户，并实现了Dispose模式，并且当前上下文被释放时，对该上下文对象任何操作将引发异常。从上文的Service1及Service2截图中，我们看到了，两个服务均注入了这个context对象，Service1设置，Service2中获取。现在我们将Service2的Method方法稍作调整，如下：
publicasyncTaskMethod(){//_logger.LogDebug("当前用户:{0}",_context.CurrentUser);awaitTask.Delay();_logger.LogDebug("当前用户:{0}",_context.CurrentUser);_logger.LogDebug("Service2Methodat:{0}",DateTime.Now);}
调整只有一处，就是获取当前上下文用户的操作，从5s延时之前，放到了5s延时之后。我们再来看看效果：
无非就是Handle中单独起了一个Scope。我们再看运行效果：
OK，HTTP请求23:02:58响应，Service2Method23:03:03执行完成。至此，问题才算得到解决。
顺便提一下，大家注意看截图，当前用户null，因为scope之后，原来的设置过CurrentUser的context已经释放掉了，新开的scope中注入的context是另外的，所以没任何信息。这里你可能会问了，那我确实需要传递上下文怎么办？答案是，订阅事件，本文中SomeEvent未定义任何信息，如果你需要传递，做对应调整即可，比较简单，也不是重点，不做赘述。
4、总结
感觉，没什么好总结的。扎实，细心，实践，没什么解决不了的。
原文