引子：最近本人正搞一个项目，项目中我们用到了struts1.2+hibernate3
由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢，今天我设置下二级缓存 效果不大，我想肯定还有更好的方法，比如Hibernate.initialize 还有迫切连接等方法
请大家多给点意见。
[color=red]
解决思路：[/color]
首先必须明白：性能问题完全取决于你的[color=blue]业务设计问题[/color]，而不是某个具体架构技术的性能。
你的业务设计采取[color=blue]面向数据表分析[/color]，导致关系复杂表和表之间的关系很多，这是你的系统性能问题最本质原因，只有使用DDD重新分析你的系统，才从根本上改观。其他只是一些小修小打的微调，不能根本解决问题。
使用Hibernate前提必须掌握领域建模的方法，也就是Evans DDD，至少了解类关联的意思和本质。
我们以前很多程序员都是基于数据表编程的思路，现在使用了Hibernate这样的ORM，Hibernate替代了数据表，或者说；插在了数据表和程序员之间，程序员就看不见数据表了，程序员必须学会和Hibernate代表的对象打交道，如果还是念念不忘数据表，那么每次用Hibernate，总是要转个弯，就不自然而且不方便。
换句话说：只有程序员真正掌握面向对象的分析设计和编程，才会觉得使用Hiberante等ORM工具是一个最简单的方式，否则，反而觉得数据表JDBC是一个简单的解决方式。所以，可以从是否善用Hibernate看出程序员的OO素质。当然，不是完全使用DDD来设计就能提高性能，还需要依赖自己对缓存的掌握和灵活控制，我的建议是这样：简洁直接的业务建模+缓存优化。
最近一篇谈lazy 的文章，提供参考：
Lazy Loading is Easy: Implementing a Rich Domain Model
http://today.java.net/pub/a/today/2006/07/13/lazy-loading-is-easy.html
其中有一句：
First off: why would you want to do lazy loading? The most important reason is to be able to have a clean domain model.
为什么你需要赖加载？最重要的是必须有一个干净的域模型Domain Model！这篇文章就是谈如何实现一个胖模型。
有些人主动或被动把SQL搞得很复杂,这本身就背离了OR MAPPING的初衷,也背离了持久曾的实质.
好的DB设计不会有复杂的SQl代码,基本就是简单的CRUD语句,在它上层再用一层Service实现复杂的业务机制.当然,这必须在领域对象已经清晰的情况下. 另外在用户闲置时间做一些数据处理工作也是很好的,等用户登录后直接就呈现给他,不用被动的等待命令再行动.
这个世界上的软件并不永远只有CRUD这种操作，统计/分析/报表等等同样是必不可少的，如果捆绑上hibernate，就如j10a所说，绝对会在性能上走向死亡。
通常我会在项目中同时使用hibernate和jdbc，当然，会有自己的封装。
单纯做ORM，我倒是觉得itabis是个更好的选择。
如果不能掌握Domain Model的设计方式，使用ORM是比较艰难的。不如No ORM，看看TSS前段时间讨论的：No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715
非常有意思，当初Hibernate刚出来时，有人和我争辩：NO EJB,NO EntityBean，大肆指责EJB实体Bean使用复杂，推崇Hibernate，如今还是同样的轮子，说明主要问题是我们建模方式不对，
因为从数据表建模的思路转变到对象建模思路，我也有过这样的经历，以前设计系统时都是从数据库建模开始，这样的问题是如果你采用对象的方式编码的话，很多问题都出来了，结果项目的代码也被改动的的很多，而且维护也很麻烦。现在我如果从头设计一个系统，我往往先是业务对象建模，业务对象先运行起来，在用代理模式或装饰模式给业务对象增加防问数据库的能力。这样代码改动量虽然没见得减少，但改动的范围缩小了，控制在几个类之间，而且便于维护。
由于关系复杂表和表之间的关系很多，在很多地方把lazy都设置false，所以导致数据一加载很慢，而且查询一条数据更是非常的慢，今天我设置下二级缓存 效果不大，我想肯定还有更好的方法，比如Hibernate.initialize 还有迫切连接等方法
请大家多给点意见。
[color=red]
解决思路：[/color]
首先必须明白：性能问题完全取决于你的[color=blue]业务设计问题[/color]，而不是某个具体架构技术的性能。
你的业务设计采取[color=blue]面向数据表分析[/color]，导致关系复杂表和表之间的关系很多，这是你的系统性能问题最本质原因，只有使用DDD重新分析你的系统，才从根本上改观。其他只是一些小修小打的微调，不能根本解决问题。
使用Hibernate前提必须掌握领域建模的方法，也就是Evans DDD，至少了解类关联的意思和本质。
我们以前很多程序员都是基于数据表编程的思路，现在使用了Hibernate这样的ORM，Hibernate替代了数据表，或者说；插在了数据表和程序员之间，程序员就看不见数据表了，程序员必须学会和Hibernate代表的对象打交道，如果还是念念不忘数据表，那么每次用Hibernate，总是要转个弯，就不自然而且不方便。
换句话说：只有程序员真正掌握面向对象的分析设计和编程，才会觉得使用Hiberante等ORM工具是一个最简单的方式，否则，反而觉得数据表JDBC是一个简单的解决方式。所以，可以从是否善用Hibernate看出程序员的OO素质。当然，不是完全使用DDD来设计就能提高性能，还需要依赖自己对缓存的掌握和灵活控制，我的建议是这样：简洁直接的业务建模+缓存优化。
最近一篇谈lazy 的文章，提供参考：
Lazy Loading is Easy: Implementing a Rich Domain Model
http://today.java.net/pub/a/today/2006/07/13/lazy-loading-is-easy.html
其中有一句：
First off: why would you want to do lazy loading? The most important reason is to be able to have a clean domain model.
为什么你需要赖加载？最重要的是必须有一个干净的域模型Domain Model！这篇文章就是谈如何实现一个胖模型。
有些人主动或被动把SQL搞得很复杂,这本身就背离了OR MAPPING的初衷,也背离了持久曾的实质.
好的DB设计不会有复杂的SQl代码,基本就是简单的CRUD语句,在它上层再用一层Service实现复杂的业务机制.当然,这必须在领域对象已经清晰的情况下. 另外在用户闲置时间做一些数据处理工作也是很好的,等用户登录后直接就呈现给他,不用被动的等待命令再行动.
这个世界上的软件并不永远只有CRUD这种操作，统计/分析/报表等等同样是必不可少的，如果捆绑上hibernate，就如j10a所说，绝对会在性能上走向死亡。
通常我会在项目中同时使用hibernate和jdbc，当然，会有自己的封装。
单纯做ORM，我倒是觉得itabis是个更好的选择。
如果不能掌握Domain Model的设计方式，使用ORM是比较艰难的。不如No ORM，看看TSS前段时间讨论的：No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715
非常有意思，当初Hibernate刚出来时，有人和我争辩：NO EJB,NO EntityBean，大肆指责EJB实体Bean使用复杂，推崇Hibernate，如今还是同样的轮子，说明主要问题是我们建模方式不对，
因为从数据表建模的思路转变到对象建模思路，我也有过这样的经历，以前设计系统时都是从数据库建模开始，这样的问题是如果你采用对象的方式编码的话，很多问题都出来了，结果项目的代码也被改动的的很多，而且维护也很麻烦。现在我如果从头设计一个系统，我往往先是业务对象建模，业务对象先运行起来，在用代理模式或装饰模式给业务对象增加防问数据库的能力。这样代码改动量虽然没见得减少，但改动的范围缩小了，控制在几个类之间，而且便于维护。
扫一扫
177
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
