如此orm?

关于Hibernate，不用说太多。Hibernate很好很强大也很复杂，入门容易深入难。
在我的使用过程中，最大的麻烦莫过于频繁修改表结构。使得Pojo也得频繁修改。
还有，配置的问题，尽管有了Annotation，但是仍然很麻烦。
关于配置，仁者见仁，智者见智。我的观点是：配置文件是用来描述pojo和db的对应关系的。但却值得商榷：
1。在建立数据库的脚本中，就已经把db的结构描述得很清楚了。
2。建立pojo的同时，又重新把数据库的基本结构描述了一遍。比方说：字段名称(在你的数据库命名和pojo命名统一的情况下)等。
3。用xml或annotation，又再次把用java代码无法描述的东西给描述了一遍。比方说：字段长度，是否为空，pk等。

这样有些重复。能否只有一份描述呢？db是必须的。那么不如就已db的结构作为描述好了。（看到这，请不要讨论系统设计应该以数据为中心还是以对象为中心？这个问题讨论得很多了）。这点，ror做得很好。值得学习。

那么如此orm可否?

public class Entity
{
    protected TableMapping        tlbMapping;          // 与数据表的结构映射关系
    protected Map<String, Object> attrs;               // entity的属性

    protected Set<Class<Entity>>       hasOne;              // 1对1
    protected Set<Class<Entity>>       hasMany;             // 1对多
    protected Set<Class<Entity>>       belongsTo;           // 多对1
    protected Set<Class<Entity>>       hasAndBelongsToMany; // 多对多

    public void setAttr(String attrName, Object value)
    {
        attrs.put(attrName, value);
    }

    public Object getAttr(String attrName)
    {
        return attrs.get(attrName);
    }
    
    /**
     * 重载这个方法，用来设置关系
     */
    public void setRelation()
    {
        // 在这里手动的设置关系，1对1，1对多。。。
        hasOne(...);
        belongsTo(...);
        ...
    }

    protected void hasOne(Class<Entity>... clazzs)
    {
        for (Class<Entity> clazz : clazzs)
            hasOne.add(clazz);
    }

    protected void belongsTo(Class<Entity>... clazzs)
    {
        for (Class<Entity> clazz : clazzs)
            belongsTo.add(clazz);
    }

    protected void hasAndBelongsToMany(Class<Entity>... clazzs)
    {
        for (Class<Entity> clazz : clazzs)
            hasAndBelongsToMany.add(clazz);
    }
}

public class User extends Entity
{
}

当系统启动的时候，自动的读取表结构信息，存放到tlbMapping中。这样子，就把Entity变成了一个动态的bean。
优点是，修改数据库结构，不需要修改Entity代码。缺点是：失去了编译检测性。
至于这种以失去编译检测的代价提高编码的速度，我认为还是值得的。只需要：
1。遵循好的编码习惯和规范。主要在命名上。
2。对于数据的结构描述能有一份完整的文档。
3。良好的测试。
应该能够能够有较高的代码质量保证。如此后，简化了很多。

然后，利用学hibernate利用antlr或者javacc自己写一个hql。或者干脆直接摘出hibernate的hql，并且进行修改。从而保证多数据库的支持。（这个地方不仅需要code能力，还需要编译原理的知识，对我这个半路出家的，有点没把握）

然后就是cache等等部分，这个可以先不考虑。主要先能把上面的hql部分搞定。

这样子的orm，或者应该叫mrm(map-relation-mapping)，应该还是能够比较快速的上手。我想如果应用于中小应用，后期的维护成本也应该不大。到了大型的应用上，维护是一个问题。这就回到了上面的“我认为还是值得的。只需要：1。......”这个地方了。

---------------------------------
问题来了。如此orm是否需要？或者我仅仅需要一个能解析db结构。然后通过freemarker生成pojo以及annation这样一个工具？

各位同学，不知道有没有好的建议。
至于说直接ror就不必了。毕竟工作用java，只能说业余用ror了。

问题是其实应该用对象生成数据库。Hibernate本来就不是为面向数据库准备的。它的适用范围是从对象构建程序。

hibernate是以对象为中心，不过事实是在开发中，有多少人是以对象为中心进行开发的。我想大部分还是以数据为中心吧。

-------------
郁闷一下。为什么没有人回帖呢？难道大家目前的开发效率都足够快，这个东西根本就没有必要？

小鸟。
工作用的jpa，也遇到了lz的问题，频繁的更改表结构。然后再生成类。烦得要死。
关注

刚刚过了一遍Rails的 ActiveRecord::Base的源代码。原来它也没有用什么词法分析器。纯粹就是在拼sql。它实现得也挺好。过于复杂的东西，那就请自己写sql吧。既然如此。那我也可以这样子。也就不用再研究antlr或javacc之类的了。

灵活的话ibatis 变化频繁的考虑用Map映射。没必要非搞的和hibernate一样。
用hibernate就必须用OO的设计分析方式自顶向下分析。

还是看场景吧。

关系数据库本来就和对象模型有区别的。

对于中小型的，没有遗留数据的项目，我都是用模型来生成ddl脚本，可以自己写一段代码来自动生成。

可以考虑使用代码自动生成工具

按理来说数据结构定好就不应该再修改了，前期花大量时间考虑数据结构分析业务需求是很重要的，考虑周全的数据结构是不再需要修修改改的，所以楼主这种经常改动表结构的问题不应该发生

很容易发生的。在现代敏捷开发中，数据结构因为需求的变化不断变化还是很常见的。所以现在推荐的设计都是通过对象自动生成数据库结构。只要类对象改了，那么数据库结构也自动变更。