项目简介
本项目是基于 .NET Framework 框架的Winform项目, 实现一键发布博客到各个平台(如WordPress站点、博客园等)的功能
项目结构与定位
Core 项目
这是整个解决方案的核心层,主要负责定义跨模块的通用契约。
- Core 只暴露 事件系统相关的内容,比如:
- IEvent 接口(所有事件的基类接口)
- EventBus(事件的统一发布与订阅中心)
-
一些基础的事件类型定义(如 AddPublishConfigEvent
) -
Core 不包含业务逻辑实现,保证可以被 UI 层、服务层等模块安全依赖。
事件总线(EventBus)
- 采用 发布-订阅模式(Pub/Sub)实现解耦,用于UI项目与Core项目。
- 提供方法:
// 订阅事件
public void SubscribeEvent<TEvent>(Action<TEvent> handler) where TEvent : IEvent, new();// 发布事件
public void PublishEvent<TEvent>(TEvent _event) where TEvent : IEvent, new();
- 强类型事件:事件处理函数的参数就是泛型类型参数,因此事件类型可以在编译期检查,而不是运行时靠字符串或反射。
事件体系
- IEvent 接口
- 每个事件都实现 IEvent,接口定义了:
public interface IEvent
{bool IsSuccess { get; set; }Exception Exception { get; set; }
}
- 事件示例
AddPublishConfigEvent<T>:
- 作用:传递一个发布配置对象,不带返回结果。
- 泛型 T 代表具体的配置类型,比如 WordPressConfig、CnblogsConfig 等。
- 用途:通知系统“有一个新的平台发布配置被添加”。
问题介绍
项目中所使用的强类型事件发布订阅模式有以下特点:
- 每个事件类既是事件参数,也是事件种类的唯一标识。
- 这样一来,事件在编译期就是类型安全的。
但是,这样就会出现一个问题:
UI 层要把“具体的发布配置对象”传递到 Core 层(通过事件总线),那事件类怎么设计才能优雅地传递类型参数?
两种初始思路
方案一:为每种配置写一个事件类
比如 AddWordPressPublishConfigEvent、AddCNBlogPublishConfigEvent ……
这样做直观,但问题也很明显:
- 要支持更多平台,就得定义更多事件类。
- ApplicationService 也要增加更多处理方法,代码臃肿。
public class AddWordPressPublishConfigEvent { ... }
public class AddCNBlogPublishConfigEvent { ... }
... // 后续适配更多平台需要定义更多事件类// Core层负责接受事件消息的类中
private void OnAddWordPressPublishConfig(AddWordPressConfigEvent _event){ ... }
private void OnAddCNBlogPublishConfig(AddCNBlogPublishConfigEvent _event){ ... }
... // 后续适配更多平台需要定义更多事件处理方法
方案二:事件类改为泛型
设计一个 AddPublishConfigEvent
优点是事件类可以复用,不需要为每个平台重复造轮子。
但问题在于:事件处理方法也得是泛型方法,而且还需要针对不同 T 类型订阅事件,看起来依然繁琐。
// 定义泛型事件类,无需定义大量的事件了
public class AddPublishConfigEvent<T> : IEvent where T : IPublishConfig, new()
{public T PublishConfig {get; set;} // T 类型约束于实现了IPublishConfig接口的类,便于传递配置信息public bool IsSuccess { get; set; }public Exception Exception { get; set; }
}// Core层负责接受事件消息的类中
private void OnAddPublishConfig(AddPublishConfigEvent<WordPressPublishConfig> _event){ ... }
private void OnAddPublishConfig(AddPublishConfigEvent<CNBlogPublishConfig> _event){ ... }
... // 后续适配更多平台仍然需要定义更多事件处理方法
最终解法
为了尽可能地减少后续开发的负担,在权衡了两种方案的维护成本与类型安全后,经过讨论和尝试,我在方案二的基础上进行了修改,选择了 泛型事件类 + 泛型事件处理方法 的组合:
// 泛型事件,直接携带具体的配置对象
// 定义泛型事件类,无需定义大量的事件了
public class AddPublishConfigEvent<T> :IEvent where T : class, IPublishConfig, new()
{public T PublishConfig { get; set; }public bool IsSuccess { get; set; }public Exception Exception { get; set; }
}// Core层负责接受事件消息的类中
// 只需要定义一个方法就兼容所有的平台了
private void OnAddPublishConfig<T>(AddPublishConfigEvent<T> e)where T : class, IPublishConfig, new()
{_publishConfigService.Add<T>(e.PublishConfig);
}
这样带来的好处是:
- 事件类高度复用:只要是配置类,都能用 AddPublishConfigRequestEvent
携带。 - 减少类型转换:不需要先用 IPublishConfig 再强转成具体实现类。
- 编译期安全:方法的参数类型和事件类的泛型参数保持一致。
唯一的缺点是:
- 初始化时仍然需要订阅不同配置类型的事件(例如 WordPressConfig、CNBlogConfig)。
不过这一步只在程序启动时做一次,可以用反射简化,性能不是问题。
总结
这个问题其实本质上是:如何在强类型事件系统中优雅地传递泛型参数。
- 如果走“为每个平台写事件类”的路子,代码会越来越多。
- 如果使用“泛型事件+泛型方法”,则能保证 类型安全、代码复用性高。
最终我采用了第二种方式,并且通过订阅时的反射处理把繁琐步骤封装掉,既解决了类型参数传递的问题,又让事件流保持简洁。