源設計就單純完成了把服務轉發到特定的服務模塊,一定程度上解耦了業務流程
但是我們實際開發過程中會面臨服務轉發后還有一些列關聯的服務
舉個例子
你調用了發送郵件的服務,接下來會面臨扣費的服務,扣費之后會自動生成一個消費流水
你看上去只做了一件事兒,但是實際上是一套業務流程流水線
我看見Jeffcky大佬博客的一篇文章《EntityFramework Core進行讀寫分離最佳實踐方式,了解一下(二)?》
看見了DiagnosticSource的發布訂閱,隨即折騰了一番,完成了我心目中的轉發服務新版本
新增了一個自動發布的基類
public abstract class AbstractPublishService : IForwardService { private DiagnosticSource source; public AbstractPublishService() { var key = GetType().FullName; source = new DiagnosticListener(key); } public virtual async Task<object> PublishAsync(object param) { var response = await ExecuteAsync(param); source.Write("Publish", response); return response; } public abstract Task<object> ExecuteAsync(object param); }
原本調用執行服務的部分修改為
if (service is AbstractPublishService publishService) { return await publishService.PublishAsync(entry); } else { return await service.ExecuteAsync(entry); }
入口調用的時候注冊一下訂閱
var subscribe = new SubscribeService(); subscribe.AddService<MaillService, OrderService>((response) => { if (response is bool checkResponse) { if (checkResponse) { return new OrderModel { Title = "Subscribe and Create Order", PayMoney = 1, CreateTime = DateTime.Now }; } } return null; }); DiagnosticListener.AllListeners.Subscribe(subscribe);
把原本發送郵件的例子MaillServer的繼承接口改為基類AbstractPublishService
我們的訂單服務部分代碼如下
public class OrderService : IForwardService { [ParamType(typeof(OrderModel))] public Task<object> ExecuteAsync(object param) { var orderParam = param as OrderModel; Console.WriteLine($"Title:{orderParam.Title} Money:{orderParam.PayMoney} CreateTime:{orderParam.CreateTime}"); return Task.FromResult<object>(true); } } public class OrderModel { public string Title { get; set; } public decimal PayMoney { get; set; } public DateTime CreateTime { get; set; } }
和之前一樣,調用一下發送郵件接口

這個服務之后會自動調用訂單服務
如果我們希望 發送郵件->扣費->訂單生成
那么實現一個扣費的服務即可,服務繼承AbstractPublishService
扣費的下一級流程為生成訂單即可
地址附上:
