Apache Fesod 读取端的事件驱动架构
抽丝剥茧：Apache Fesod 读取端的事件驱动架构
1. 入口：一个优雅的门面 (Facade)
简约而不简单
哪怕系统内部再复杂，给用户的入口必须足够简单。Fesod 采用了经典的Facade 模式（外观模式）。
所有的读取操作都从FesodSheet.read()开始。
// 你的代码FesodSheet.read(file,DemoData.class,listener).sheet().doRead();这就好比你去餐厅点菜，你只需要跟服务员（Facade）说“来份宫保鸡丁”，你不需要知道后厨的采购员、切菜工、炒菜师傅（Internal Classes）是怎么配合的。
核心类关系
让我们透视一下这个“门面”背后的指挥系统：
从图中可以看到，ExcelReader只是个传话筒，真正的指挥官是ExcelAnalyser，而真正的干活主力是ExcelReadExecutor。
2. 流程拆解：一次doRead()的奇幻漂流
当你按下回车调用doRead()时，数据在 Fesod 内部经历了一场接力赛。这场比赛可以分为三个阶段。
第一阶段：智能调度 (Dispatcher)
谁在干活？ExcelAnalyserImpl
职责：看人下菜碟（路由选择）。
核心逻辑：
Excel 有两种格式：古老的.xls(BIFF8) 和现代的.xlsx(OOXML ZIP)。ExcelAnalyserImpl不会盲目解析，它会先偷看文件的前几个字节（Magic Number）或者尝试用 POI 的POIFSFileSystem去探测。
- 如果是
.xls-> 实例化XlsSaxAnalyser。 - 如果是
.xlsx-> 实例化XlsxSaxAnalyser。 - 如果是
.csv-> 实例化CsvExcelReadExecutor。
这就像老司机，听一下发动机声音就知道该挂什么档。
第二阶段：SAX 解析 (Parsing)
谁在干活？XlsxSaxAnalyser(继承自 DefaultHandler)
职责：把 XML 变成事件流。
核心逻辑：
这是最“硬核”的部分。Excel 的.xlsx本质上是一堆 XML 文件的压缩包。
Fesod 直接利用 SAX 解析器去读sharedStrings.xml（存字典）和sheet1.xml（存数据）。
它只关心三个事件：
- StartElement(
<c r="A1">): 哟，一个新的单元格来了，记下它的坐标。 - Characters(
123): 读到了内容，把它存到临时变量里。 - EndElement(
</row>): 一行结束了！赶紧把这行数据打包，准备发货。
这种流式处理 (Streaming)意味着，无论你的 Excel 有 100 万行还是 1000 万行，Fesod 内存里永远只有“当前这一行”的数据。
第三阶段：转换与回调 (Converting & Callback)
谁在干活？Converter体系 和ReadListener
职责：把“生数据”变成“熟对象”。
核心逻辑：
SAX 读出来的都是 String。但你的 Java Bean 里写的是Date、Double。
这时analysisContext里的转换器登场了。它会自动匹配：
- “这个格子是日期格式，内容是 44567？那我把它转成
2022-01-06。” - “这个格子是数字？转成
Double。”
转换完成后，完整的 Java 对象被构建出来，通过listener.invoke(data)回调给用户的代码。用户处理完这行数据（比如存库），Fesod 就会擦除这行对象的引用，等待 GC 回收。
时序图全景：
3. 技术高光：状态的艺术
AnalysisContext (背包客)
在这个复杂的链条中，如何保证状态不丢？
Fesod 设计了一个Context (上下文)对象。它就像一个“背包”，随着流程在各个节点间传递。
ReadSheetHolder背在包里：当前解析的是哪个 Sheet？ReadWorkbookHolder背在包里：全局配置是什么？AnalysisContextImpl甚至还维护了当前的行号。
这种设计让各个模块（Analyser, Executor, Converter）都变成了无状态的单例（或者轻量级对象），所有的状态都收敛在 Context 里。这不仅线程安全，而且极易扩展。
4. 总结
Fesod 的读取架构是一次极其标准的事件驱动 (Event-Driven)实践。
- 它用Dispatcher屏蔽了底层差异。
- 它用SAX解决了内存瓶颈。
- 它用Context串联了复杂流程。
当你下一次看着控制台的日志一行行快速滚动，且内存曲线平稳如直线时，请记住：这背后是无数个 XML 事件正在精密地起舞。