【咨询】关于代码生成部分的未来规划

[SIGEER2222]

关于代码生成部分的未来规划

感谢开源！我在研究这个项目时，对代码生成部分特别感兴趣，目前我自己也有一些独立的生成器项目在使用，想借此机会交流一下这个功能的未来规划。

我有几个具体问题想探讨：

1. 项目未来希望将代码生成部分打造成什么样子？是主要面向开发者，还是也考虑普通用户的使用场景？
2. 是否计划支持用户自定义模板？比如允许用户根据需求调整生成逻辑或输出格式？
3. 当前的生成逻辑看起来像是基于字符串拼接，未来会考虑引入工作流机制吗？比如让多个生成器协同工作，形成更复杂的生成管道？

如果有相关文档或计划可以参考，也麻烦指个方向，谢谢！

[aishang2015]

@SIGEER2222 感谢关注，BlazorAdmin主要是用于开发公司的一些项目。代码生成的功能主要是根据ef实体来生成基础的表格和编辑功能。此项目的生成逻辑不会再进行大的更改，仅以优化为主。

关于更复杂的代码生成器，我之前编写过一个工具，我来说一下写这个工具的一些思路。工具可以创建若干【生成器】，一个生成器中包含若干的【模型】，【变量】，【模板】，【流程图】。模型中主要是定义数据结构，支持嵌套结构。变量可以定义一组变量，是键值对形式的，键名可以作为模型的输入。模板主要是代码模板，程序设计了一些模板变量，可以转化模型或变量中的值。在流程图中可以创建各种流程图，通过连接模型，变量，模板，以及其他节点来构筑一个流。通过执行流可以让代码生成到指定的地方。

技术选型方面，流程图组件用的是JsPlumb的社区版。模板引擎使用的是Liquid，对应C#的实现是fluid，模板编辑器使用了monaco，工具整体使用WPF + WebView2 + Blazor进行了开发。

这个工具完成度不是太高，我又比较懒，仅仅实现了一些基本流程。主要是偏向于脚手架生成，复杂的一些业务流程，感觉上如果凭借工具实现，反而不如去直接写了。而且一旦代码被手工修改了，工具就没法继续使用了，否则会覆盖掉手动修改的代码。

[SIGEER2222]

@aishang2015 感谢你宝贵的经验

我最初是为了减少样板代码，编写生成器确实是个枯燥的体力活，但是如果大家能一起玩一定很有趣。秉持着这样的理念我在寻求一个优于SourceGenerator的生成器——SG不能跨项目和嵌套，写起来也很费劲，饱受诟病。

此间我翻了两本书，《Code Generation in Action (Jack Herrington)》和《领域特定语言 (（英）MartinFowler》，受到了一些启发。我认为基于模板语言的生成器固然强大，但是也会增加一定的学习成本，为之编写编辑器会有很大的助力，不过会消耗作者太多精力。所以我仍旧采用字符串拼接和替换为主，并写了简单的格式化函数——虽然面对Blazor很无力。

流程图的构建很好也很有必要，不过优先级没有那么高，我认为可以根据生成器的运行顺序自动生成出来。

至于关键的问题——能否修改生成的代码，两本书中都倾向于不能修改，如果某个GeneratedCode需要作出调整，可以再写一个简单的替换文本的函数——我认为可以写在业务项目而不是生成器中，生成器可以使用roslyn读取和运行这个函数——当然目前还在探索阶段。当然如果替换量比较大，说明并不适合生成，生成器可以当一个简单的脚手架来用。

可惜因为当前项目很忙，我没有太多时间和精力，暂且意淫一下，建个文件夹先，有空时我们再用代码交流。