如果有一个新的数据持久化框架，您希望他能帮你解...

等待中国的orm。。。诞生。

关于配置文件，我想说几句

上次和bruce讨论组件模型时感觉框架（不管是不是持久化框架）只是实现组件模型的一种手段，最主要的目的是数据和操作数据的方式（我还是认为这其实就是算法，只是表述形式不同而已）分开。

在hibernate这边，数据就是PO－－形式上就是数据类。hibernate在运行期动态生成SQL。数据类里只有数据，那怎么和具体的算法（请原谅我使用这个词，因为我想不到别的词来表达）联系起来呢？就是配置文件。
配置文件的作用就是数据与算法的粘合剂。

换句话说，配置文件的复杂度直接取决于所要面对的问题域。如果要解决的问题确实非常复杂，如EJB要解决的分布问题，那不可避免的，这个配置文件会变得很复杂。

hibetnate针对的问题域只是ORM，所以相比之下，配置文件已经比EJB好多了。但是ORM本身也是相当复杂的东西－－我想这跟SQL语句本身的局限性有关，所以配置文件想非常简单我觉得不太可能。老实说，我觉得hibernate做的已经够好的了，理解它的配置文件关键是要理解关系模型和对象模型及它们之间的差异。我觉得如果做到了这点，hibernate的配置文件应该不难理解。我们倒是可以考虑写些小工具来管理这个配置文件的复杂性。



复杂性的问题，我比较相信一句话：追求简单，但不能再简单了。
设计简化复杂性－>工具管理复杂性－>手工管理
这是我心目中的三种方式，具体如何选择就要看费效比了。

虽然可能说的不太好听，但与其去重新做轮子，不如先好好看看现有的轮子。hibernate的优秀，真是要慢慢体会。

呵呵，以前我还站在JDBC这边呢，现在，也转投hibernate阵营了

抱歉，泼冷水了，老大见晾啊^_^

同意， 可以把你的设计思路说出来。 这样通过讨论， 我们也能对o/m有更深的理解。

我的观点和无明是一样的，只不过考虑到自己是管理员的身份，没好意思跳出来泼冷水。对象模型本身的复杂性和多样性决定了你不可能过于简化。当然上面的楼主也提到准备结合sql和ORM来做，比较复杂的地方就直接使用sql。但是我不知道你考虑到没有两种方式混用，在cache数据的时候非常容易出错。就是Hibernate，你把它和JDBC混用都需要非常小心，一不小心，总会出现更新数据不同步的问题。而且我觉得你做出来的ORM局限性会很大，解决不了稍微复杂一点的问题的。

另外也许我对映射文件比较熟悉的缘故吧，我实在不觉得Hibernate的映射文件什么地方复杂，特别是你用Tanghan plugin来生成，实在是很简单的事情。

我倒是希望哪位仁兄作一个基于使用SQL语言的O/R工具，对于一些人来说SQL是他们的第一语言。

提到了配置文件，我说一下的思路。

   传统的O/R所有的数据类都是的字段都是Integer,String等的简单对象，虽然也是对象，但是我们很难对他进行操作，比如动态查询，中我要有选择的取出一些列，那你怎么办，我看到hibernate是使用hsql来表达查询语句，返回的是对象数组（不知是否正确）很不直观，而且使用hsql来生成查询，如果数据类改名也就是对项目进行重构，好像很难保证数据类与hsql保持一致。但是如果我们将数据类的字段定义为我们自己的定义的对象，那么就我们可以对他进行我们想要的处理，可以实现比较复杂的查询。而我们的操作全部是完全的基于对象的，不会出现那种不一致的问题。关于这一点我举两个查询的例子：

public class Student extends Table{//学生基本资料
   public IntField id;
    public StringField name;
    public BooleanField sex;
    public ByteField age;
    public StringField address;
}
public class Resume extends Table{//学生简历
  public intField id;
   public ClobField resume;
}

  上面的使数据类。
下面我们来构造一个静态查询，所谓静态就是在设计期定义好的一个查询类。
  下面的例子是将上面的两个数据类连接成一个数据类。

public class StudentInfo extends query{
   public IntField id;
    public StringField name;
    public BooleanField sex;
    public ByteField age;
    public StringField address;
   public ClobField resume;
   public StudentInfo();{
            Student student= (Student ); SessionFactory.getResourceRef(Student .class);; 
      Resume resume= (Resume );SessionFactory.getResourceRef(Resume .class);; 
      id=student.id; 
      name= student.name; 
      sex= student.sex; 
      age= student.age; 
      address=student.address; 
      resume=resume.resume; 

      select_all();; 
      from(student.inner_jion(resume);.on(student.id.eq(resume.id);););; 
      order_by(student.id.desc(););;//降序排列
   }
}

    下面我们来定义一个动态查询；

    public class Test{
       public void test();{
            Student student= (Student ); SessionFactory.getResourceRef(Student .class);; 
      Resume resume= (Resume );SessionFactory.getResourceRef(Resume .class);; 
    IntField   id=student.id; 
    StringField   name= student.name; 
    BooleanField sex= student.sex; 
    ByteField   age= student.age; 
    StringField   address=student.address; 
    ClobField   resume=resume.resume; 
    Query query = new Query();;
    query.select(id._(name);._(sex);._(age);._(address);,_(resume););;
    query.from(student.inner_jion(resume);.on(student.id.eq(resume.id);););; 
      order_by(student.id.desc(););;//降序排列
    SessionContext sc = SessionFactory.getContext();;
      sc.open(query);;
      while (query.next(););{
         .................
     }
   }
   }

   在我的设计中所有的数据都是以集合的方式来操作，不象hibernate,jdo等以主键为单位单独操作。所以在我目前的设置中批量更新批量删除的效率几乎跟直接调用jdbc一样，中间多的只是一个生成where条件的操作。

下面我说以下为什么我的设计不需要配置文件？
      在上面的例子中我们看到Student类和Resume类的定义除了声明了几个字段外，没有其他的代码，那么他如何与数据库中的表对应呢？
    这里我使用了反射机制，在这个类实例化时，我会查找所有定义的继承自Field类的数据域，实例化该类型并赋值给这些数据域，数据域的名称就是数据库中对应的表的名称。表名默认就是类名。这是在没有配置文件下，而且我们没有对这个字段重命名的情况下采用的默认设置。当然我们也可以在程序中初始化并重命名表名和字段名，下面我举一个例子：

public class Student extends Table{//学生基本资料
   public IntField id;
    public StringField name;
    public BooleanField sex;
    public ByteField age;
    public StringField address;
    public Student();{
      super("Student2004");;//重命名表为Student2004
      id = IntField.create("Studentid");;//重命名学生id为Studentid
}

robbin 提到了cache问题，我目前还没有时间考虑这个问题。在我目前的设计中，所有的数据在内部都是以数组方式存放，对于象int,boolean等简单类型都是以原始类型（不知叫法对不对翻正是指,int,short,boolean之类的类型）存放。对于数组的搜索速度应该效率时最高的，不知道其他的解决方案是怎么存放的。当然还是有很多问题要考虑。

用iBATIS咯，这就是一个基于sql的Mapping工具。

每个字段都用框架特殊的东西?太不爽了,EJB也没有这样的要求,更没有移植性了.而且还要继承父类,完全不是POJO了,比EJB也许更恐怖,那个好歹还只是接口.我没有觉得HQL重构会有问题,我是这样查询:"from " + XXX.class.getName() + " ..." ,即使是字符串,像IDEA是完全可以直接修改的.

不知道效率和JDBC比怎么样,只是复杂程度好像差不多了.我用hibernate的时候查询一般都只会有一行代码:

public List getXxxxxxxxxx(XXX xxx)
{
   return hibernateMgr.getSession().find("xxxxxxxxxxxx");
}

没有配置文件只完成了一些基本的属性控制,好像听说比如delphi的Bold之类的ORM就不用配置,但是其他的hibernate提供的高级的控制和灵活性就没办法达到了.如果把配置的东西写在类里面硬编码,实在是不好,而且复杂的东西可能非常麻烦.如果jdk1.5出来有meta tag应该就不用写映射配置文件了.

个人看法

我们的框架的持久层就是一个 SQL 映射框架，还是基于字符串的，根本就不是什么 ORM。可以直接使用 SQL，非常直观，而且开发效率很高。我们将来准备转向 OLAP，所以没有用 ORM 的概念。因为 OO 完全无法解决分析领域遇到的问题，这个领域有自己的特点和算法（基于 Cube 的一系列算法）。以前 potian 也没有敢肯定 OO 就能解决这一领域的问题（说明他确实是一个很聪明的人）。可能以后我们的框架会与关系数据库绑得更紧（这里有人说了，你是在犯罪！），可以在 JDBC 和 SQL 的层面解决数据库无关性的问题。
世事无绝对，ORM 的框架是否采用也要看你所要解决的业务问题而定。
这里我要提出几个问题供大家思考：如果非 OO 的框架能够很好地解决客户的业务问题，那么这个框架是否值得肯定？它还有没有存在的价值？是否明天就应该判处它的死刑？

我的想法是一个全面的企业级开发框架中可能是混合了多种设计理念的，只要实用，直接拿来用好了。不一定非要强调 100% OO。与数据库直接打交道的框架 100% OO 可能吗？只要大的界面（从外面看上去）是 OO 的就可以了。

为什么大家对 ORM 和 Hibernate 这么热衷？说到底 ORM 还是一个工具，很大程度上减轻了我们做数据库开发的工作量。不过只是一个工具，所以别把这些理论看得那么高深，甚至夸大其辞好象明天银弹就会出现一样。Hibernate 是经过实践考验的，说明它是一个非常好的框架，但是将来肯定还会出现比 Hibernate 更好的框架。
自行开发框架一个很大的问题是无法得到充足的反馈，要想让别人放心用，就只能开源。一个成熟的框架不是开发者自己觉得好就是真正好，还要靠大量使用者的反馈才能逐步成熟（你自己无法预测到所有可能会遇到的复杂问题）。以前独孤木的文章中也说到过这个意思，所以我觉得是蛮难的事情。我们自己的框架是在项目的锤炼中逐渐成熟起来的，我们做过很大的项目，所以对这个框架很有信心。