ORM已经是过去的事情

在当今分布式缓存以及关系数据库颠覆者Key-value Store大势之下，关系数据库已经Over，无疑建立在关系数据库和对象之间的映射ORM框架也成为过去式，最近Stephan Schmidt发表的博客ORMs are a thing of the past再次引起轩然大波。昨天博文Hibernate has Problems, but where is the Alternative?提出了思考，不用Hibernate有替代者吗？其实我的回答就是key-value数据库如Memcached或Terracotta。

1.ORM的问题之一是：其产生的SQL语句是可怕的，以至于产生性能问题，迫使不少程序员关注调试其产生的SQL语句，但是不得其道，不过这还是因为程序员关注点错误，我一再在Jdon强调，使用Hibernate就是屏蔽数据库，关注领域模型对象，要通过OO思维去编程。因为SQL好学而且很多所谓计算机软件教育都是从SQL而不是对象（其实OO不需要学习）开始教育，结果本不需要学习的被误导到错误的思维，回不过来了。可悲啊，这就是走弯路。

2.抛出LazyInitializationExceptions是非常痛苦的，这个在本站大量关于Open Session In View的讨论，OSIV其实是个反模式，是为了弥补其LazyInitializationExceptions而推出的补救措施。

3.这是我个人意见，领域模型和ORM所要冬眠的实体有时并不是一回事，当你进行DDD编程时，你看到你的领域模型中大量Annotation标注的数据表名称，这对领域模型大师们一直梦想的无计算机软件的模型概念是多么沉重的打击啊。

为了使Hibernate更加具有伸缩性，现在普遍是使用Ehcache作为Hibernate二级缓存，而Ehcache被tearracotta收购，所以，使用Terracotta作为Hibernate二级缓存进行分布式缓存计算是一个方向并且成熟。关于Terracotta+Hibernate+Ehcache整合的一个问题，而Terracotta本身有缓存的持久化，实际就是一个Key-value存储数据库，当然你可以使用其他key-value数据，见标签key-value讨论。

我总感觉企业级的软件归根结底就是保存有用数据，保存数据就需要增，删，改，查，由于SQL是过程式的，复用性很小。所以在SQL上边增加一个面向对象的语言，目的就是为了减少工作量，说白了就是为了省事，数据如何去存储，数据库也好，key-value也好，都是增删改查的操作，一种技术从兴起到成熟是需要很长时间的。数据库的存储方法已经非常成熟了，key-value要想一下推翻数据库肯定是不可能的，也不符合自然规律，所以现在说hibernate已经是过去了还尚早，key-value就没有自身的问题了吗？只是用的人少还没有暴露出来而已，我曾经也是一个一直追求新技术的人，但是用来用去才发现没有全部符合要求的，多多少少都会存在问题。
我现在反而感觉使用什么技术倒是次要的了，关键是软件怎么样才能增加，修改的方便，用户体验的要好，怎样才能删除的准确，查询的快捷才是重点，至于数据如何保存，我觉的随便，将现实中的业务通过软件表达并且能够优于现实这才是软件的真谛，一定要清楚软件是用来干什么的。
举个例子，如果不用键盘而用语音来录入数据这将是多么美妙的一件事。。。。。。。
[该贴被zzxsky1986于2009-10-20 17:22修改过]

>>key-value要想一下推翻数据库肯定是不可能的，也不符合自然规律，

呵呵，这个还真有可能，再说key-value更自然。

ORM至少还要用好几年，说过时还是早了点。可能你说这个技术过时了吧。我认为在企业应用中，四五年中hibernate还是不会消失的。
看了你很多帖子，我认为这个论坛太不适合新手了，只有那些做设计的人来这里才适合。做开发的只会被误导。
在合适的时间干合适的事情，做为开发人员，就不应该在这里浪费时间了。个人看法。。。
[该贴被lei55022033于2009-10-20 23:21修改过]

我很欣赏bang的在软件艺术上的探索，对你的理论也很感兴趣（我的很多新的知识都来自jdon），但是感觉bang是个理想主义者。我认为在软件行业没有什么好的技术什么不好的技术，只有适用的技术。大多数软件公司我想也不会追逐最新的技术，他们考虑的因素很多。bang一直说的关系型数据库已死,我有一个疑问是我们系统里面有大量的报表，涉及的表很多。如果不用关系型数据库那用什么？

“数据库已死 http://www.jdon.com/artichect/dbdead.htm”，你自已说的。
Key-value Store就不属于数据库了？我还一直以为你早就意识到：设计的角度来看，DB已死。

07，08时有了JPA, 也有了云计算, 基于JPA的Model，其存储方式可以是普通的关系型数据库，可以是XML格式的文本，也可以是亚马逊(比方)的云计算所提供的存储服务（其底层就是Key-value Store)。

从设计的角度来说，既然不会关心某一个table是什么，同理，也不会去关心某一种Key Value是什么。设计者的眼中只会有OO。

>Key-value Store就不属于数据库了？我还一直以为你早就意识到：设计的角度来看，DB已死。

Key-Value实质就是缓存，只不过由Key-value自己去持久缓存数据，所以，严格来说是以内存缓存为主的分布式方案，至于为什么加上数据库尾巴，当然因为它也是数据库功效，但不是关系数据库，而我们所说数据库基本是关系数据库的代名词。

不在名词上计较，关键是眼中只有OO，对象是否会丢失这些事情应该由软件架构来保证，而软件又要委托硬件磁盘才能保证不丢失一样，这些都不关我们程序员的事情。

关系数据只是一种表现形式，不要被这个遮住了视野。
软件的核心是业务过程和业务对象，数据只是依附于其中用以完成业务过程。数据是可变的，业务过程是不变的。

我觉得楼上对于软件开发的理解有一些偏差。
软件面对的是业务过程，所以需要实现的也是过程。
但是对于企业而言，更加重要的是数据
一个企业，随着业务的发展，业务过程会不断的推陈出新
但是不能业务的推陈出新而放弃原来的客户，系统也不能因为升级而放弃过去的数据。
这是一个连贯性的东西。
所以当你做程序的时候，其实你面对的真正长期存在的或者应当尽可能多考虑的应当是客户的数据。什么是变的，什么是不变的，应当不断看到。
至于那些危言耸听的说法，付之一笑好了。

抽象只是门软件艺术，艺术归根是艺术

要想解决大问题，还得靠手段

我支持banq.其它的就不多说了。

为什么有些人做了一辈子软件，水平还是只能写写代码而已，关键是思维不一样，jdon让我们向上思考问题，而很多人思考问题都是一下子向到底了。就好比，为什么公司讲究团队合作，为什么雇佣很多人，而不是给一个人发N个人的工资，让他做N个人做的事情，软件也是一样的，向上考虑，雇佣更多的计算资源来完成更多的事情，而不是单纯的依靠某一个资源来完成。

ORM有时确实有够恶心。