数据库岂能不亡?---->??
前几天学校asp.net实验室招人,去问了下:主要考一些存储结构、触发器.本想进去锻炼下的,但内心的真是想法让我连报名都不想去了.
在数据库里写存储结构、触发器.无异于面对sql语句编程,java只是一个小丑,对象是被sql强奸了的DTO.将大量的业务逻辑置于存储结构中,乍一看好像是为了提升系统的处理速度,但随着系统变大、访问量提升,最后数据库自己宣布此系统以死,请换个新的系统吧.学生为什吗这么讲,主要因为以下几点:
1、将业务逻辑置于存储结构,无异于将所以的负载集中到数据库中.首先当客户请求到达时,DAO将客户的参数送于数据库的存储结构里执行,然后返回结果.这样的构架只会让数据库疲于奔命.
2、使用Hibernate缓存数据,这好像是缓存,但实际上这些个缓存被击中的几率有多大呢?客户请求到达时,DAO携带着客户的参数让存储结构去数据库执行计算,然后封装成DTO返回给客户.这样的缓存能被击中吗?因为业务逻辑是要送到数据库去计算的,当新的请求或者客户请求参数变动,那么又得重新跑到数据库去计算;为何?因为你针对的是sql编程,你的对象只是一些所谓的DTO而已.这样一来你会觉得,用什么Hibernate啊,它把系统速度拖慢了,还不如直接使用JDBC来的爽呢?
3、如果你认为数据库的缓存已经很强大了,或者你说数据库群集,那我想只有你老大微软.NET才能帮你.关于数据库的坏味道我就不在阐述了,很多高人都已经将的很清楚了.
我为什么会有上面的思考,主要是基于一下几点:
1、我们将业务逻辑放在java代码中,根据DDD思想进行设计,DB只负责对象的重建.如此一来将负载集中在JBOSS等容器中.
2、我认为DDD最大的好处是能减少和数据库的交互.利用聚合等设计模式对领域对象进行建模.起初好像客户每次请求都会加载很多对象,然而由于我们将业务逻辑置于java代码中,当访问量增大,那些经常被访问的对象即可被容器或Hibernate缓存,随着时间的流逝,这种缓存会越来越精确,从而让容器流更多的汗.!
3、当容器跑不动时,简单的增加硬件配置便能让处理能力成倍提升,让对象在几台服务器上跑来跑去,跑累了就在内存里洗个澡,岂不快哉?!
我现在才觉得EJB的设计理念是那么的超前,然而国内却流行"简单就是美",使用spring对EJB的设计理念避而不谈,只讲:企业很少用到EJB的,spring简单实现的东西在EJB那里很复杂.不知道我们的思想是不是离美国人还有很远?
还好,现在有seam了,可以多一些选择,如果我能做主的话就对spring 说消失吧.以上只是学生的一点小想法,如果有理论性的错误,那就请您先去戴双手套,然后捡起砖头猛拍,这样您即拍的爽,手也不会被刮伤.
[该贴被admin于2008-10-29 17:29修改过]