hibernate的正向工程与逆向工程有感

首先，梳理一下字面意思。

hibernate的正向：编写好实体类，然后通过hibernate自动生成数据库的数据表。

hibernate的反向：编写好数据库表，然后通过插件等工具生成实体类代码

中间是通过hibernate配置建立桥梁：hibernate的配置分为两种一种是注解的形式，一种是xml的形式。【注解和xml的配置方式的区别对比】

（目前公司采用的实体类和数据库协同的方式有两种：

一种是手动建表，手动建实体类

【缺点】

手动建立，同步（手动容易出错，一旦出错就意味着是无畏的时间消耗）

【优点】

可以记住一些实施的细节（不具备竞争力）

另一种是通过powerdesigner进行模型设计，然后用代码生成器生成实体类，同时也生成数据库表。）

【还没实操过】【等实操后，再行补充】

 

首先看项目的需求：如果是单次确定性项目是可以用正向生成的方式。但是如果此次项目想要作为可复用的项目构件那么就会出现使用hibernate的正常生成严重依赖java作为中间语言，如果有一天项目想做一个其他语言的移植版本，要么无法摆脱java的hibernate，继续沿用，继续作为正向导出的工具，要么就是移植一次性正向生成数据库表，放弃java的hibernate，过后只有依然两种（正向、逆向两种选择，但这种情况已经是有了数据表的前提条件了，一种原有的java代码正向生成的逻辑进行复刻，但是这样子是有风险的，一方面看原有积累的代码的规模，只要不是机器批量自动，手动容易引发新的错误，另一方面所有的复刻的另一个语言版本的类hibernate的正向生成工具是否依然跟hibernate原来的生成逻辑是否一样，交付得到是SQL是否等效。并且这个我们是否能够得到完整的脚本。原来的实体要调整怎么才能进行有效调整。而且java实体并不具备很好的视图功能，有别于powerDesigner。另一种就是进行逆向。至此，利用排除法，会有移植需求的情况下，从长远来说正向生成不是一个很好的选择。）

那如果是一直都是使用java的情况下呢？就得一直沿用hibernate？正向生成没写hibernate配置的情况下很难对生成的数据库表进行精细化的控制，除非我们手动编写hibernate的映射配置文件，那么就要求我们熟悉hibernate的配置编写，这个配置编写只是适用于hibernate，不具备通用性，一旦切换成mybatis等其他ORM就得重新进行学习。从这点的考虑来看，手动编写只是熟悉hibernate使用的实施细节，是无法迁移的。是不是手动编写容易引入错误？不手动操作没办法进行精细化控制？那么我个人的选择就出来了我选择逆向生成实体。

参考资料：MyBatis和Hibernate相比，优势在哪里？

https://www.zhihu.com/question/21104468

 

正向生成：是符合oo的，贴合程序员的思维，不需要专业的DBA，但是也确实是有点理想化了。就像瀑布模型一样，但这个的话前期要做很多的准备工作，后期又不能有什么超过前期准备之外的调整。更像是屠龙之技，却又被束之高阁。能够真正驾驭的人毕竟是少数的，对于大多数人来说它就变得不是太实用。不过很小的项目倒是我们能够企及的（这样对逆向来说，也不是太难吧），但是由于开发效率可能想沿用原先的构件，那可能就是出于混合杂糅的形式存在了。新代码用正向，旧代码走老路（先前用什么就是什么），新旧代码最好是独立的，避免太高的耦合度，除非旧代码也是采取通用形式的正向生成。这样久了，可能就出现上一段所说的规模扩大移植问题。没有移植需求，也会跟hibernate形成高度的依赖绑定。

【以下属于胡言乱语】{

过度设计。为了设计而设计。

技术选型，其实是一种折中。一种现实跟理想的妥协。不是最强大的才是最好的，合适的才是。兼具一定的拓展性（如果在未来预期不会有出现拓展的需求（单次项目），不需要做太多的冗余措施）

看项目的周期了【短期，简单粗暴；中期，适当选型；长期，适当选型，持续迭代，不求一步到位，但求逐步到位】

}

 

题外话：

以上纯属瞎比比，yy一下，不要太当回事。如果不妥，望网友不吝留言评价，指导。