关于系统性能的思考

哈哈，老哥上班时间满充足的。

1 正好还没看到这里哈。

2 缓存的有很多种，但是我这里的主要意思还是业务对象model缓存。

3 我和朋友现在自己接的一个项目打算实战一下分布式缓存，虽然钱少，但是主要是锻炼哈（台湾客户满扣的呵呵），还有那个单例模式，确实是的，单例是相对于类加载器的，我在我的另外一篇帖子里也说了这个问题。如果在采用EJB的情况下，web容器和ejb容器的类加载器体系很容易造成单例实例非单例。

6 java确实不太适合做富模型，但是就是我在实战中采用富模型的情况下，使用hibernate导致很多sql，并且hibernate要想往一个one-to-many的集合中增加数据，首先要取出所有的数据才能增加，这点不知道你有什么好的办法，我的解决方法目前都是设计到many一端数据太多的情况下，直接用jdbc操作了。

7 我其实没有自己制作ORM大轮子，重复发明轮子我也没有那个能力也不想。采用SSH开发，对于无状态的操作当然没有并发问题，但是一旦模型放到缓存中就有并发问题了，真正的业务模型对象是有状态的，并且状态很多，不变量约束有很多状态构成，这个时候就要求严格的面相对象的设计，封装非常重要。其实我所说的仅仅是利用已经有的轮子（开源缓存系统）和良好的面相对象设计来设计系统而已。

对，jdon中的那个帖子也是我发的。

看来楼主Hibernate实战经验不够啊。

Hibernate因为过于灵活，用法可以千奇百怪的，我只写一些个人观点：
1.因为关系型数据库的关系，不要过于幻想把Hibernate封装成完全OO的框架，只把他当成一个非常非常高级的SQL生成器是最好的方式，我是这么认为的。也就是说，你编程的时候，大脑中就是一条条sql，当然在我脑中是hql，我比较熟了（QBC、QBE、QBDC我都很熟）。

2.从细节上来讲，我不赞成配置一对多，基于使用EntityDao（单dao设计，这个EntityDao可以直接使用，也可以继承之后实例化），一句话就能轻易查询一对多的信息，没必要配置在映射配置中，我一般只在映射配置中放多对一的信息，其他的几乎都不使用，偶尔用用多对多（极少）。只要EntityDao设计的好，或者再做个父类，一般性的service编程（不需要DAO编程），已经很简单了，虽然是面向sql的编程，带一点点OO的样子。利用Hibernate的update和delete命令，完全可以自己封装出，既高效，又还算OO的操作方式。

其实数据库中并没有一对多的关系，硬是要那么操作，当然容易造成性能问题。以你说的一对多添加的例子，假设是小组中加个同学吧。
StudentService.java:

    public void insert(String groupId, Student student) {//假设ID是String的，之所以把这个参数单独传进来，往下看就知道了
        student.setGroup(new Group(groupId));//假设Group有这个构造函数
        studentDao.insert(student);
    }

这段代码其实是以同学为主导思想的，那个groupId这所以这样，主要目的是便于复用，只需要传一个groupId就行了，不会担心发生什么性能问题，这个方法确保只触发一条insert sql，而且还能减少web层编程的复杂度，web层对于小组信息只要获取一个groupId即可。（当然这里还隐含了“小组-同学”管理页面UI的设计问题，不同的UI操作方式对后台方法的需求也不太一样）

3.然后在POJO和VO（或者叫DTO）的选择上是2-8原则，大部分的业务操作，CRUD，pojo足够了，少部分的特殊操作，如复杂查询，则用VO来传递信息到web层。

4.从我对Hibernate的了解成来说，我认为你现在想解决的问题，hibernate的作者也想解决，但是因为关系数据库的问题，在实际实践中，碰到了很多阻力（所以Hibernate对处理某一种问题，往往提供了N多种的解决办法，这既是它的优点也是它的缺点，学习成本高啊），必须要自己掌握平衡点，做选择，例如一对多的思维方式用不用，二级缓存用不用、saveOrUpdate用不用，merge方法是否真的有必要等等。

hibernate对于对象状态的控制和对象图的控制其实已经还算不错了，不管你是否承认是否造轮子，我认为你很难做的封装能比Hibernate更好。

我借此帖提出自己的疑惑。

在域模型中，缓存技术很重要，但是，我一直有一个不明白的地方，因为领域模型中一个Aggregate的生命周期基本上要靠Factory和Repository来控制，特别是后者。

那么，就是说，一个Aggregate的不论是根还是子对象更改之后，需要真正提交更新的时候是要通过Repository对一个Aggregate从头到尾完全遍历来进行具体的更新操作。所以，这时候使用Application的缓存，有一个问题就是，当多个线程同时修改同一个Aggregate的时候，如何做到线程安全，或者说，如何提供线程锁？

就如同LZ所说，如果对Value Object进行锁是很好，也是DDD作者提倡，但是，问题是加在那里？

我一直不太知道这两个问题的解决方法。有人告诉我对每一个线程创建一个新的Aggregate（缓存的话，应该是克隆），但是，这样子就是说，一个系统中会存在大量的拥有相同全局ID的Aggregate根对象，这是不是违反了DDD的基本原则呢？因为DDD书中明确标明，区别Entity的方法在于Identity而不是内存中的Reference（就是指针地址）。

同意楼上的观点，当系统有几十万甚至几百万代码的时候，不能指望所有的代码性能都是非常优化，并且协同工作时也是最优的。
这时用好hibernate不仅不会有多余的sql，而且比自己写的jdbc代码少很多倍的sql访问。hibernate的一级cache机制做得非常好的，很有用

兄台讲的和  jforum 好类似。