生成方案

本框架的代码生成方案和其他任何框架都不同，是一种全新的思路，通过统一的数据库注释格式，实现代码生成。

其他框架无论是PHP系列、JAVA或GO等，他们的思路都是单独配置思路，比如通过命令行传参，给不同的字段设置不同的组件，好一点的搞了一套可视化拖拽表单组建，再好一点的，疯狂的完善和增强可视化操作，似乎要做一个Dreamweaver一样。
为什么作者要把这种做法成为单独配置呢？有什么缺点吗？
因为这个过程，把设计表结构和生成代码作为两个独立的环节去设计了。我们使用熟练掌握的数据库工具设计了表结构，然后再去按照框架的规则再去配置一遍代码生成的规则。这种做法可能对大多数开发者来说，这是自然而然的。
但是作者在使用这些框架的时候（fastadmin、原版easyadmin、若依、若依plus、jeecg等），发现这个体验非常的鸡肋，即便的配置方式极其的强大，作者也感觉是在浪费时间。作为开发者，在设计表结构的时候，每个字段的落地形式（组件类型）就已经思考过了，结果准备开发生成代码了，还要再把这些心路历程再经历一遍，似乎没什么意义。
另一方面，如果这些框架提供的配置效果不好，也很头疼。对于命令行配置的方式，如果没有提供特别完善的文档，上手会非常难受。而对于可视化操作，这要求框架在这方面进行大量的工作，才能做出一个稍微好用一点的面板。但即便做出来了，他们的交互模式也是千篇一律，左侧是组建列表，中间是组件预览，右侧是组件配置。但是配置的时候，可能又有大量的弹框和输入表单，而且页面上给配置“分配”的空间太小了，用起来并不舒服，如果不小心刷新了页面，内容也会丢失，这种做法要求框架付出大量的精力，但似乎并不值得。
还有一点，对于枚举、关联关系等类型，我们要在数据库中记录好他们对应的意义，比如1代表进行中，2代表失败等等。设计表的时候我们已经完善了注释，设计的时候又要再录入一遍，而且如果开发过程中想要调整，又得去数据库改一边，还要再在生成代码代码环节配置一遍，在配置生成代码时，还要把每个字段（即便这个字段没有改动）再操作一遍。

后来作者easyadmin的生成方案后，非常感兴趣，只需要在设计表的时候，写一下表注释就可以了。不过当时easyadmin也支持通过命令行配置，本框架中已经完全移除了这种思路。

但本框架继续沿用了easyadmin的方案，并且明确了整个方案的思路，在这个思路上继续增强和发扬，我们称为数据库注释组件。你只需要在字段注释中，按照框架预设的组建规则填写，生成时对应的组件。
作为开发者，只需要安心设计表结构就行了，唯一要注意的就是按照一个简单的语法去写表注释。这样除了避免了前面谈到的一些情况，同时，也把数据库和业务仅仅结合在一起，比如一旦我们调整了枚举类型，只需要修改注释就可以了，剩下的就是执行一下命令。
很多开发者，注释里只有3个状态，但开发时代码已调整了很多状态了，也不去更新数据库，使用本框架的模式时，我们推荐先修改数据库的注释，然后使用命令重新生成代码，再把对应的更新复制到正式代码中。