七年磨一剑，Java新开源项目BabyFish

[babyfishchentao]

Hi, 大家好
从2008年8月开始，我利用自己的几乎所有的业余时间，以慢工出细活的方式，开发了一个Java的开源框架，不久前收个版本终于完成并发布到了github，项目地址为：https://github.com/babyfish-ct/babyfish

中文快速手册：在项目主页上找到tutorial_zh_CN.docx（注意：不是应英文的tutorial.docx），点击进入此文件的页面，然后再点击Raw按钮下载此Word文档

开源协议：LPGL3，完全免费，无论自由软件还是商业收费软件，均可免费可用。

框架分为两个部分：

(1) Java 部分：
(a) ObjectModel4Java：让Java支持超级智能的数据结构，这是本框架的初衷。
(b) Unstable Collection Elements：让Java集合框架中的Hash结构和红黑树结构突破困扰所有编程语言的元素数据必须稳定的魔咒。

(2) JPA/Hibernate部分
(a) ObjectModel4JPA，扩展ObjectModel4Java，进一步简化用户代码，替换Hibernate的所有延迟功能，使JPA实体对象也具备ObjectModel4Java的所有能力。
(b) QueryPath: 这是一个非常实际的功能，本框架的性价比之王，无论是对大型的分布式项目还是对超级简单的三层架构学习项目，都能在开发体验和程序性能两方面带来质变的飞跃，从此告别org.hibernate.LazyInitializationException。
(c) DistinctLimitQuery: 当使用Oracle数据库时，此功能可以解决Hibernate分页查询在某些情况下会出现的一个可怕的性能缺陷。

[zm_meng]

表示我现在还是个菜，看不太懂。

[走在冷风中_南山南]

看了半天发现是个ORM框架。。。居然还是和hibernate集成的 话说hibernate早就被主流抛弃了

[qazwsxhai]

不错~,顶起.

[执笔记忆的空白]

首先，很感谢楼主的分享，赞一个 然后我有个疑问： (a) ObjectModel4Java：让Java支持超级智能的数据结构，这是本框架的初衷。 ObjectModel4Java 是什么东东，超智能数据结构是只model层次封装么？

[「已注销」]

没看懂是什么。。。。。。

[babyfishchentao]

Hi guys 所谓ObjectModel4Java，的确是数据模型，但并不是简单的封装，而是由用户编写少量的的声明式代码，BabyFish在运行时刻生成字节码来实现所有你想要的一切强大能力，一改以前数据对象的C语言结构体风格的现状（一些私有字段加一些毫无意义的getter和setter其实就是结构体，毫无功能，其实就是拿着Java语言写C结构体），动态字节码自动实现的数据结构，能在其对象属性或对象之间的关系被用户修改时，自动侦测这些用户修改行为而自动地进行一系列连锁反应式的修改和调整，改变相关的其他数据部分以保持整个数据结构的高度一致性，其功能究竟能强大到什么地步，我的中文文档一开头就有一个图文并茂的关于ObjectModel4Java例子，虽然是冰山一角，但管中窥豹足矣。 数据结构和算法永远是计算机程序设计的核心，这也是BabyFish框架集中处理数据结构问题的原因，数据结构作为理论基础，它可以影响的领域太多了，当然，第一个版本时间有限，我仅仅深度影响了ORM/Hibernate领域，以后版本会有越来越多的领域被影响。所以，BabyFish并不是ORM的附属物，而是一次数据结构、集合框架和算法的升级，例如：不稳定集合元素（Unstable Collection Elements)就是一个迄今为止没有在任何语言的集合框架中出现的新算法和新思想，虽然它们都能感觉到这个问题不解决会很痛。总之我更愿意看到首个版本被视为集合框架以及数据结构的算法创新，而不是ORM的附属物：） 在下个版本中，BabyFish会和基于另外一个开源项目TeaVM结合（TeaVM: https://github.com/konsoletyper/teavm，将Java字节码反编译成Javascript，开源说是5年前我因对GWT超级不爽所以非常想做但的确没时间去做的东西，本框架版本完成后，我发现居然国外有一帮高手做了TeaVM，他们提前做了和我想法完全一致的东西，下个版本工作量大减），将会推出ObjectModel4Javascript，在浏览器里支持智能数据结构，再基于此更高开发效率、更高运行效率的方式干掉AngularJS2.0和ReactJS，把Web前端的市场从Javascript开发人员中抢回来。 毕竟我的第一个版本是把智能数据结构用于了ORM领域，所以我发表一下我个人对ORM的看法。 ORM的好坏，有两个纠结点，一个RDMBS（关系型数据）是否合理；二是在关系型数据库上是否ORM是好处多还是坏处多。 （1）RDBMS是否合理，现在有很多NoSQL, 如MongoDB, Google Big Table等，但NoSQL不是Not SQL，而是Not Only SQL，No SQL以牺牲关系性数据库最重要的能力（事务）为代价，寻求海量数据的支持；如果你说从事的领域是互联网方向中没有事务需求的部分，那么你能从No SQL中找到海量数据的支撑，因为对大数据分析和数据挖掘行业而言，100%精确的确没意义；但对于从事金融领域工作的人而言，数据时不能出半点差错的，事务本身就是核心需求之一，对于这些领域而言，在业界有新的突破之前，非用RDMBS不可。当然，最理想的的目标是，要是有一款既能向No SQL一样支持海量数据又能向RDBMS事务一样不出半点差错的数据库，该有多好啊；遗憾的是，在这个领域内，连理论层面都还没有找到突破口，更不要说实际产品了。所以我认为RDBMS和NoSQL并不彼此针对，只是一个目前技术水平无法统一的矛盾的两个极端而已。当然，Neo4j数据库很有趣，因为它更像是介于二者之间的折中产品，大家有兴趣可以了解一下。 （2）ORM好处多还是坏处多问题，类似于Java和.NET谁好谁坏的问题，是一个长达十年的口水仗，横竖都会被骂的事，本不愿讨论。但我还是鼓起勇气，用我的视角，讨论一下我对ORM的感受。 我见过接触过很多技术人员，大致有两种 (a) 狂热的OO粉丝，把设计模式奉为圣经，恨不得一口气把大量数据全部读取成内存中对象再来细粒度的调情式处理，一般是经验不是太丰富的技术人员，一旦ORM被它们使用，生成的SQL的惨不忍赌，一个SQL经验丰富的人的一句优化后的复杂SQL代码500毫秒可以完成的数据处理，它用ORM写的程序却要折腾到几分钟才能完成，这也国内有部分公司谈ORM色变的原因。 (b) 有资深DBA工作经验或数据优化背景的人，他们可能很早就那个N多数据库产品专家认证，对数据库内部的IO存储机制、执行计划、SQL优化器、甚至是特定厂商的硬件设备的不同搭配形成的排列组合对数据库性能的影响都了然于胸的人，这帮人专注于数据优化领域，却忽视了全局的视角、系统的可扩展性、可维护性和变更效率。恨不得一个系统所有的复杂业务都是天书一般的存储过程来完成，其它编程语言全部死光光。 在极其理想的情况下，优秀的数据层开发人员应该同时开发实力和数据库能力，上能调教架构师，下能调教DBA。当然，由于大环境问题，这种后端开发的神级开发人员出现在中国的几率极低。但是，作为经验少一些的普通开发人员，一个人的精力有限，怎么办呢？很简单，相对于DBA全盘运维全套数据库而言，开发人员需要用到的数据库知识真就是九牛一毛而已，鉴于此，把你要用到这个很小的一部分学得不比高级的DBA差不算太难。然后，你再深入学习ORM，彻底征服它，让它绝对听话，达到你想让诱导它生成什么SQL它就会生成什么SQL的境界，这样你就能诱导ORM去生成高性能的SQL语句，甚至比数据库专家手工写得SQL性能高，因为你是用机器去优化SQL，而他是靠体力去去优化SQL，水平一样的情况下，他必然干不过你。 听起来很理想，只要人员专业，一方面，对数据库足够了解以明白该执行什么样的SQL；另一方面，对ORM足够了解以让它足够听话，说生成什么SQL就会生成什么SQL，这样就可以为业务层提供一流的数据层API了，性能超高，功能超强，扩展性超强，极其OO以符合上层技术的思维，等等。虽然整个项目是不是垃圾项目不知道，但至少数据层不会沦为垃圾项目了。但事实上，公司必然有自己的成本控制策略，社会人才储备也有固定比例的梯队结构，现实中这种团队太难建立。的确，ORM目前的智能度还不足以让经验一般的开发者随便乱玩也能保证SQL的性能，而要智能到这个地步工程过于浩大，以至于目前没有任何一个ORM团队能接受这种成本，所以这是一个循序渐进的发展过程，希望在这方面有深入研究的同学一起向ORM（不限Hibernate)的Team提出宝贵的改进意见和想法。相信它终归会越来智能。

[Java_er]

不知所云啊 能具体点嘛

[FalloutBird]

不错不错，学习了

[liukang1832]

研究一下，感觉LZ说的还是蛮有道理的

[君莫傲]

Hibernate虽说现在已经被MyBatis一点点的取代，但潮流中已经将Hibernate作为时代的引领者了！

[且活且珍惜]

潜水很久了，赞一下

[九点搬书匠]

看看啊

[鱼头506]

可以免费下载使用的 不错哦

[lizzie910]

学习一下，谢谢

[cattpon]

不错不错~加油！