云计算成为现实
本文介绍几个成熟的云计算解决方案，希望更多人抛弃数据库计算模型思想，转向可伸缩的新架构思维。
你数据库那种all in box风格，那么点可怜的计算能力，早就不知被云计算的风潮冲到哪里去了。
http://www.jdon.com/article/34888.html
我一般不喜欢对已过世的人做一些负面评价，所以关于wind13所讲的李小龙前辈过世因由不敢认同。
但是有一点，李小龙前辈所讲的截拳道，本质是抛弃一切繁杂的东西，还原回武术的精髓，没有门派，没有招式。在业务软件里，业务知识才是精髓，而技术实现仅仅是门派招式，这种能实现，那种也能实现，今天这个好，明天那个就会超越，只有掌握业务这个精髓，才能更好的控制手里的招式。
像缓存，谁都会用，但是只有掌握业务需要的那些人，才能自己随心所欲的自己控制缓存的各种招式，而不是让一个hibernate之流提供的缓存模型来用缓存那一点点通用的招式。
面对不同的对手，采取的攻防也不相同，了解对手就是了解业务的过程，只有了解了业务，才能使出更恰当的招式来应对，而不会挑了一个虽厉害但不适用的技术来完成。
像古龙前辈所讲的，功夫就是功夫，杀人的是这一种，救人的也是这一种。这就是所谓的道一法众。业务也就是业务，实现业务的方法却有很多种，但不管怎么实现，离了对业务的理解，再好的办法再好的技术也只是空架子。
了解业务，了解对手，这些是具体要做的事。
我想这与架构思想和程序思维方式有关系，但关系不大。 我们现在讨论的或者说正在积累的能力，其实就是一种见招拆招的能力，也就是无论什么业务需求，因为我有了这样一套思想或方法论，这样就都可以找到正确的方式来应对和实现。
所以希望不要误解对业务理解的重要性，我觉得banq的一种说法是有道理的，好象是说：算法之类的自有数学专家来研究，业务需求方面当然要业务专家来统筹，而软件专家要做的就是组织架构一个灵活、扩展而生命长青的软件。一个软件是需要这些多方面专家来配合实现的，术业有专攻，对业务需求的理解是做具体项目工作时必须的，但并不是我们真正所特长于别人的能力，而软件架构的思想可能才是关键。
假设一个系统，对于业务的理解不很到位，但因为实现的方法很科学，架构具有良好的扩展性和可维护性，那么，业务需求的变化可以尽量去满足和适应，那这个软件专家就是个好的专家，也许因为业务的错误理解导致项目出现一些问题，那我想也是业务专家没有分析到位的原因吧，毕竟软件专家对于特定行业的知识是弱项的。
数学专家、行业专家、软件专家、硬件专家……我们暂且可以形成这样的概念吧。
另外，就是对古人的评说，对今人的评说，都是正常的，人不要怕别人评说，只要不严重到人身攻击或诽谤，都是合理的。只要知道这是沟通的一种方式就可以了，说了出来，别人也就知道是什么意思了，这就有沟通了，有了相互的理解了。
banq兄和cats_tiger的对辩不可谓不精彩！人皆谓之：真理越辩越明！
但是那仅仅是所谓啦！什么是真理？真理就不会变吗？非也……不管是技术还是做人做事，都要本着“识时务
者为俊杰”的原则，这才是“真理”！当然，这仅仅是小弟一面之悟！未必所有人都会赞同！不赞同的也麻烦
别用板锹拍我，我身体太单薄……呵呵~
我很喜欢看人家辩论，因从中可以看到他们的智慧，特别是倾听和表达的智慧！一辩一答，彰显智慧魅力！
不错啊，继续嘛，如果这个论坛真的是风平浪静，天下太平那就真的是没有发展了！现在小弟还看不太懂你们
在说什么（只看热闹了…对不起大家！我惭愧，我有罪！），但是给我一年的时间，我就会参与到你们的
“辩论”之中，在“激辩”中提高自己，启发大众！那岂不是人生中最high high的事了？
呵呵~等我哈！多谢、多谢
Hibernate 不是用来替换数据库的！！EJB 也不是！！！
如果SQL数据库不用了，你用什么做替代？楼主通篇都在胡扯！！
Jacklondon Chen
http://velocityweb.sourceforge.net
>>Hibernate 不是用来替换数据库的！！EJB 也不是！！！
是.他们不是替换数据库的.他们只是对J2EE开发者提供了一种面向对象操作的方案.是屏蔽了数据库.隔离了数据库.不知道你说替换是什么意思?难道认为hibernate or EJB == 数据库?
正因为有了这些面向对象设计的框架.我们可以将软件核心的业务全部体现实现在领域层.哪么系统的移植性可以大大提高.数据库只是对象实现冬眠的工具而已.而并不成为一种软件开发的核心.这样利用HIBERNATE这些持久层框架我们的软件可以移植任意数据库。
当然你可以不选择使用hibernate.或是你自己通过JDBC实现.或利用数据库(存储过程什么的来实现业务运算).但是DB和DB之间是有他自身的特性.当你这个系统如果要迁移DB的话。大维护量的工作可能会让你崩溃.而你不至于要修改你的类似存储过程什么的代码。包括数据访问也有可能要修改楼..就算你在高明一点。不去使用存储过程等等技术.哪么过程式的编码带来的高维护量也是可观的.目前现实情况比较明显.
我完全不知道我这样的想法有什么错,初学J2EE时,我也认为编程序就是SQL语句.但当我用心的啃设计模式和敏捷软件开发在到企业应用设计模式时,我才愕然发现,我是多么的渺小,是多么的垃圾,超级垃圾！
在这些书中它们都在给我传递一个什么才叫面向对象的思想,什么才是对象,它们一一的回答了我.
从上面的帖子不难看出,大家认为数据库不死是因为它是存储技术,而我认为它死了则是在构架或建模的时候数据库是死的,当然项目后期肯定要speciality DBA .
Hibernate她紧紧是屏蔽了数据库具体技术吗?我看未必,如果你是以事务脚本或表模式组织你的代码,我看你根本没有必要使用O/R工具,还不如直接JDBC,何种构架决定何种工具.如果你是面向对象的忠实FANS,那O/R工具是你必选之工具.如果你钟情于领域驱动设计,那么数据库在你面前就是死的.
我是一个在校的大专院校的学生,我无权在里跟各位牛人讲大道理,我只是在想在学校里做好学生.大二了,看着我身边的几位数学知识很不错的同学认为搞.NET JAVA 就是SQL,我不知道我该怎么去说服他们,因为他们数学很牛(在我们学校),所以猛啃数据结构,即而推之他们认为自己很厉害,至少在我们面前,在这些牛人及回帖的各位牛人面前,我完全没说服各位的想法,我只知道时间会证明一切的.
叫我小菜鸟吧,我们有项目经验;叫我专科生吧,我没有好文凭;叫我目光短浅吧…………我不怕,我要继续学习.
删除的那个帖子是我发的，看来JiveJdon3.5还存在BUG，串名了。原文如下：
>在构架或建模的时候数据库是死的,当然项目后期肯定要speciality DBA .
数据库不只是构架时用不到，已经死了，而且到了项目后期也可以抛弃DBA.
这就是我一直强调云计算已经成为现实的原因，我们的软件如果是一个分布式云计算架构，性能提升就不会推迟到项目后期，而是高瞻远瞩的在开始的架构回避了数据库，因为数据库是性能上最不可scalable的。
如果你知道这个系统并发性能很重要，为什么将业务计算依赖数据库计算，这时，引入数据库就是在系统中埋下定时炸弹。正确的做法就是象google那样引入分布式云计算，让多台服务器并行计算处理你的业务，而不是靠数据库调校。
现在看来，数据库调校这事就象小裁缝店一样，靠一两个小裁缝细耕密作；而云计算就是服装工厂，只要设计确定，就可以大量招聘廉价的工人（相当于云计算中廉价的服务器）。这样一对比，你们就知道死抱数据库的人士多么渺小落后甚至愚昧吧！
我终于明白什么叫高瞻远瞩！
banq老师,在java领域中有所成就是不是得去研究下主流框架的源码啊？
串名问题解决了。是限制了SessionContext大小引起的新BUG，对ComponentesSizeInSession生命周期错误延长为全局单例，可见每个对象生命周期时刻都要考虑清楚。
>在java领域中有所成就是不是得去研究下主流框架的源码啊？
有所成就是研究主流框架的使用就可以，不必研究源码，这实际就是模式思维，对任何一个东西，只要掌握应用模式之道，就象用数据库，不必研究数据库源码一样，这句话我说很多遍，这个话题和本主题无关，不多说。
哦,其实我是想询问下在学校里该学些什么,java方面应该以那方面为重点.
>其实我是想询问下在学校里该学些什么,java方面应该以那方面为重点
这个问题和本主题有关吗？看看本站“Java学习标签”。不要再问和本主题无关话题，大家自觉维护主题一致性，才是对阅读者的尊重。
“站的高一点，再高一点”无论作哪一行都需要牢记这一个原则，做软件同样是如此的。
无论到了何年何月我们始终需要一个地方存储数据（但是一定不是象现在主流的样子），但是如何存储不应该是我们关心的核心。我只希望知道对象被创建了，我只希望需要的时候我获得了对象，但是在这期间这个对象怎么了？哪里去了？都不是我希望关心的。但是在现有的主流环境下却是我不得不费心费力的，更糟糕的是在更多的情况下这件事情牵扯了我的系统很大的性能消耗。
我觉得很多人有一个认识上的误区“数据库==现有的关系型数据库”或者“数据库==现有的SQL Server或者oracle”，这样的思想有些狭隘了。数据库就是一个存储数据的地方，可以是主机的内存，可是在网络中的网线和设备。
“关系数据库在企业架构早死了”这是Banq的原文，我想核心的意义也就是这些了。当我们推动一个销售订单在各个业务过程间流转的时候是不是真的需要关心他的每一个属性是如何对应到一张数据表中的某一个字段上？当然不是，我们需要的是这个表单本身，这才是我们的核心。那么为什么我们一定需要关系数据库？不要说SQL提供了强大的数据搜索，如果有一种方法可以直接取到订单这个对象那么为什么还需要搜索呢？
楼上讲的很好，是有经验实战的思考。
我在另外一个帖子就谈到我自己的数据库思维和对象思维有时决定了不同设计思路，最后导致一些古怪不可跟踪的BUG出现，看下面这个帖子具体分析，因为纠缠于存储这个细节，最后被其牵着鼻子走，最后导致系统不稳定，各种BUG，这是最可恶的，人非圣贤，但是至少我们必须时常意识到这点并抵制它散发的坏味道：
http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34936&message=23118421#23118421