数据库字段变更，运行一下生成器自动搞定，然后对其 model 的 getter、setter 有依赖的地方 eclipse idea 会显示出要修改的地方，重构很便捷

jfinal 选择以数据库为基础，往上去搭建，数据结构是基础，相对稳定。如果从 model 出发，反向生成 sql 去修改数据库会很麻烦，例如你的改表结构的 sql 控制字段的长度、类型这都要额外写代码，因为仅有 model 中的属性，你生成 sql 的时候是无法知道字段长度的

因此，你还要为 model 属性添加注解，用来指示建表、改表结构 sql 的生成，而 jfinal 的以数据库为出发来得到 model 会便捷省事很多，也更稳固，不容易出问题，我个人不是太信任用 sql 去改表结构这种搞法的

你自己可以试试实现一个从 model 出发，去改表结构、生成表的功能，一定会比 jfinal 现在的设计要麻烦得多

@JFinal 如果getter,setter依赖的地方倒是比较容易找到，就是SQL语句中有表字段名的地方就不容易找到了。

@JFinal 我觉得不一定要用SQL去改变表结构或者生成表，我感觉缺少的是一个数据库字段和实体对象属性的对应关系，导致写增删改查的时候会需要直接写数据库字段，而不是用实体的属性。

@whoismy8023 hibernate 的 HQL 就是在 HQL 中使用实体属性，而非使用的字段名，付出的代价是极大的，例如需要发明 HQL，不仅徒增学习成本，而且带来了非常大的麻烦

增删改查，通常增删改是不需要写数据表字段的，你试一下 model.save()，model.update()、model.delete() 就知道这三个方法完全不需要知道字段名

只有查询才与表字段有关，hibernate 的坑在此就不在赘述了。你感觉缺少了数据库字段和实体对象属性的对应关系，这个关系并不缺少， jfinal 通过反射数据库表在系统启动时就自动建立了，如果你是希望用注解或者 XML 去配置这种对应关系，那就严重违备了 jfinal 的极简设计风格

hibernate 时代就是利用 xml 或 annotation 建立了实体属性与表字段的关系，其缺点在此就不在赘述了

加个映射，会多很多开发的工作量。当然，后期修改可能会减少工作量。但也只是可能。因为项目完成后变字段，变结构的情况真的不多(可能增字段会相对多些)。所以说，这东西有利有弊，有时觉得总的工作量其实没多少变化。我用了五年的hibernate，烦的就是做映射（当然，自动建表还是不错的），还有子查询，特别是做复杂的报表就更烦了。要建个视图也要再做映射。
而JFINAL，个人觉得CRUD会感觉轻松些。
总之，个人觉得凡事都是有利有弊的。
个人愚见。

@ihss23 @JFinal 这些我倒是也知道，只是总是觉得少了点什么

@whoismy8023 追求极简的设计，一开始会有觉得少了点的感觉，但少即是多，灵活去组合各种核心功能就能实现非常灵活自由的功能