如此orm?

不敢苟同,如果客户能和我们"按理"的话,我们一定比"提前进入了社会主义"还有幸福了

这里的protected Set<Class<?>> 考虑欠周道。觉得应该用protected Set<Class<Entity>>更为合适。因为一般有关系几乎能肯定是与对应着数据库的某个实体有关系。


tlbMapping 确实打算设计成存放这些数据。但是，可能不会把tlbMapping放到Entity中。这样子，这个entity和db的耦合就太强了。应该会把tlbMapping和entity的关系重新抽出来。让系统启动的时候，自动的加载db和entity之间的关系。

完全相反,现在的系统中既使需求了解的再详细,修改还是会存在,对于这种不能避免的问题,个人认为不应该去考虑如何不让它出现,而应该把注意力放在它出现了要怎么解决..

我是用jpa做的，但实现还是用hibernate。
1.先设计uml类图，然后生成类
2.用annotation标注类
3.根据pojo生成数据库

以后变更的话就先改uml，然后改pojo再重新生成数据库。

当然如果觉得麻烦的话uml这步也可以省去。

hibernate也是可以这样做的

这里应该可以分开来理解设计这个问题吧；
1、关系数据库的概念里面，似乎只能用干涩的一对一、一对多、多对一这样的关系，来抽象现实。而当业务复杂到一定程度的时候，这样的表现会带来很大的理解成本与维护成本；
2、OO出现风靡的原因正是因为OO比面向过程更能够准确、轻松的抽象复杂的现实业务逻辑。
3、关系数据库设计和我们做业务模型应该没有必然的联系吧。Hibernate是个对象关系映射工具，手册上写的很清楚啊，那么如果我们的对象模型和数据模型完全一样，我们干嘛要映射？我认为Hibernate就是一个OO的业务处理方式，而把其中的关系数据库的具体处理逻辑交给Hibernate自身去处理。我们应该站在更高的层面去处理业务逻辑，当然在性能要求较高的地方可能需要人为的干预下，这样所带来的开发成本与维护成本的优势是显而易见的。
4、域模型是Java开发人员做的，而数据库模型是数据库开发人员做的，让数据库以存储我们的域模型为目标做设计而不是跨过域模型去直接面对我们业务来做，这样不就OK ？

Hibernate是面向对象程序设计的，不会数据库都可以用，可以不考虑数据库只管写自己的程序，再根据你写的配置文件和映射文件生成数据库中的表。

如果说围绕数据中心开发，本质上还是围绕在面向过程的开发。目前感觉国内大部分人对于OO的概念的理解也只是停留在概念上的，因此导致我们还是围绕以数据为中心进行开发。你说的这个做法我觉得好像是在做ROM映射工具，这已经违背了面向对象的理念。

楼上的兄弟，你只是从一个技术人员的角度去考虑这个问题。如果有一天，你发现你的业务逻辑是一丢SQL代码的时候你就会明白了。

提一个观点，第一数据是死的，在系统中你不能靠SQL去把数据变活，虽然你可以这么做但是不推荐。第二，对象并不是所谓的ORM映射，并不是数据表的体现。去在开发中体会下OO吧，如果离开了设计模式你也许不能体会对象的重要。

关于面向接口，我不知道你是怎么理解的。像现在大多系统一样接口的滥用已经很普遍了。并不是所有的都要接口，如果开发中碰见一个实现对应一个接口的做法那么我觉得很幼稚，当然你可以打着以后维护方便的旗号进行反驳。我个人认为接口不是这样用的，接口的定义在实际开发中是很困难的，如果你发现你的接口定义很简单那么我认为只有两种情况：1.滥用接口2.考虑不全  以前我在另一个关于接口的贴子里面说了几个关于接口的用法。

最简单的方法，只需要写domain对象，用Xdoclet注释好，通过ant来自动生成hbm映射文件和表。。。

<script type="text/javascript">alert("$@@#@##@#");</script>