hibernate、ibatis、freyja的价值

hibernate：面向对象查询语言 HQL

ibatis：集中管理SQL+动态SQL

freyja：缓存


freyja开始于一个游戏项目，因为本身没有游戏经验，把之前的那一套带进了游戏，结果很不理想。

观察的一段时间之后，我发现目前对java的一些框架有这么一个看法：

“ 高效率的用JDBC，开发快就ORM。”

让我不明白的是ORM也不过JDBC的封装，用了一些反射进行结果集映射。这个差距就有这么大？再者ORM提高开发效率是显而易见的，问题是怎么去解决效率问题。自然是处理缓存，怎么处理?像hibernate、ibatis一样一旦update就把所有缓存clean？

就如blog上记载的，一步一步的观察、发现，freyja对缓存的处理能力越来越强大。由此一来就能打造出一款高性能ORM框架。

 

 

凡是都有代价的，你想提高一倍效率就要付出一倍其他东西。但是到现在看来我对freyja最大的感触就是不需要去改动业务代码，我所做的仅仅是把hibernate给删了。然后整个游戏的性能带来了巨大的提升。做到了用户大部分操作不需要再和数据库打交道，直接内存操作。

 

 

至于开发效率，毫无疑问会让人想到hibernate。hibernate的HQL应该能给大家带来不少方便。尤其是实体关联，能查询出一个就能把其他的实体一并加载进来。

虽然HQL有这个便利，但是我觉得HQL是不需要的。配置好实体关系之后，实体与实体之间就能形成一个网络。我们只需要SQL+实体关联就行。至于关联操作其实也不推介，个人认为对实体操作都要做到自己控制。于是在freyja里面仅仅提供了一个@many注解来方便查询。

freyja的jdbc操作都是由springJdbcTemplate完成。springJdbcTemplate不是一个ORM框架，但是通过freyja的改造之后，springJdbcTemplate在映射部分就没问题了。

 

hibernate、ibatis > springJdbcTemplate ！

 

ORM和JdbcTemplate之类的关键区别在于SQL解析。

 

freyja与hibernate、ibatis不同之处在于freyja在完成了ORM框架的基本解析工作之后重点发展缓存去了。ORM天生就能够操作缓存，freyja就是看出了这种天然的能力才会大力往缓存方向进攻。虽然说暂时对联表查询没有太好的办法，但是只是我希望freyja能够把单表CURD变为纯内存操作。让freyja变为游戏类java 主打ORM框架，致力于快速开发和高效缓存支持。

 

freyja对SQL有这么一个原则：虽然不能为SQL提供缓存，但结果集映射是必须的。

坚持这个原则以防止freyja对SQL的支持不够好。也就是说fryeja再不济，也不过是执行了一句没有缓存的SQL查询。

 

 

待续。。。