solon
solon copied to clipboard
noear
【欢迎讨论】关于 ActionExecuteHandler 和 Render 的命名（要不要改）讨论
最近有用户疑问 ActionExecuteHandler 和 RenderFactory 分别是干什么的？因为历史的原因，三言两语也讲不清。
但确实容易让人晕乎，不知所然。
1、ActionExecuteHandler（动作执行器接口，负责读取）
这个接口 “早期” 是输入 Context 和 Method 就输出执行结果。。。后来，体系内增加了“路由拦截器”对执行参数的二次确认，就改为：输出 Method 需要的参数。。。（原来是完整的执行，后来改为解析（或读取）出参数。。。意义上也大有变化）
介绍：
- 功能：将 Context 的请求数据，转换为 Method 调用需要的参数
- 类比：后来发现，它相当于 Spring HttpMessageConverter 的读部分（但不完全是）
区别：
- HttpMessageConverter 只对
@RequestBody的注解作处理 - ActionExecuteHandler 对整个 Method 的参数做处理（比如把 json 分解到每个参数上）
2、Render（渲染接口，负接输出）
这个名字早期从 jFinal 借鉴来而，负责格式化输出。RenderFactory 是 Render 的创建工厂。“早期” 一些序列化框架的适配，在使用前需要固化配置，所以设计了 RenderFactory 去固化配置。。。（不断优化后，已经不需要提前固化配置了。但出于兼容考虑一直保留 RenderFactory）
介绍：
- 功能：将模板渲染（或数据序列化）后写入 Context 的响应接口
- 类比：相当于 Spring HttpMessageConverter 的写部分（但不完全是）
3、相比较于 HttpMessageConverter （的思考）
现在看来，两者合起来很像 HttpMessageConverter 的功能。。。最近有想过把它们合起来（会支持兼容过渡），比如叫 EntityConverter，或 ContextConverter （我们是多元处理，所以不能 Http 开头）
合起来后，“终端用户”在微调时，会更单一、更清晰（之前要管两个：ExecuteHandler 和 RenderFactory）。
- 比如加个写的配置（或转换器），或读的配置（或转换器）
但 “终端用户” 要定制话，会变复杂。
- 比如定制一个新的 JsonRender，几行代码就写完了（默认只需要实现一个接口）。
- 如果定制 JsonEntityConverter，如果涉及读取转换，会复杂很多（当然是可以关闭的）。
讨论：
- 现有名字要不要优化？改为什么名为好？
- 要不要合并？如果合并，叫什么名为好？
- 或者别的想法？
附：ActionExecuteHandler 和 Render 的需求：
- 如果是模板，是没有解析参数的内容（合的话，可以关掉读的能力）。即需要 Render 能力
- 如果表单数据，只会有解析参数的处理（合的话，可以关掉写的能力）。即只需要 ActionExecuteHandler 能力
- 如果是格式数据，内部都会有序列化对象，提供序列化与反序列化的支持
