那你给个另外的天堂！
――――――――――――――――――――――
没有一定的权威（专制）性，怎么领导这么多的技术叼棍！
纯属忽悠～～～～～～～～～～
cjq1234 ：
你好。
我做了2年的开发了。不过，从2000年开始，就开始研究（或者说学习）java。
我喜欢哲学，喜欢中国古典文学，喜欢史学，虽然自己研究的不是很深，但就如我喜欢java一样，喜欢他们。
(我认为我们中国的文化，实在太深奥了------关于这个我还要写文章,我真不理解为什么,国家不搞我们自己的文化,虽然有些问题,但我们能够选择性的学习)
另外，我觉得编程几年不重要。
为什么这么说？
有句话叫有志不在年高！
这句里也可套用。
搞了很多年，如果搞得不深入，还不如一个入行不是很久，但研究深的。
不知道你同意否？
很感谢你!你让我感觉到写文章写对了.
windjp ：
我觉得一个搞软件的，如果不懂些数学，那是不太完整的。
第一，就软件开发和解决数学问题这两个事情的本身来说，他们是有很多共性的。
比如解决问题的能力，和解决问题的思路。
第二，离开了数学，做设计是要出问题的。
我们都明白，程序是从数学里出来的。
很多问题，如果没搞过数学,很难想象这个问题怎么解决。
数学在程学设计里有着极其重要的地位。
但，程序设计不是纯粹数学。
对象间的关系，一般不需要特别复杂的数学知识----------也许，我没接触到那个领域。
在设计时，重要的是把事物的关系理清。
设计的目的是什么？是为了实现。
什么扩展性 伸缩性等问题，都不是主要的！实现才是主要！
那些都是附带出来的问题。
那么我认为，设计的时候，不能只做设计，
也要考虑一下这个设计方案的可实现性以及其复杂性-----为编码者考虑。
一个好的设计方案，其前提是容易实现的同时，又能满足其他要求，比如压力和可扩展。
当然，有时候，可能会有冲突。那么可以根据重要性，在这些冲突之间找到一个平衡点。
所以，如果不懂数学，也不懂开发，这样的设计者设计出来的方案，我认为很可怕的（如果不是很简单的业务）。
我觉得我还是个菜鸟。
我的话仅仅是一家之言。
如果没有banq的言论，我的那篇文章很难写出来。
如果没我的文章，你的评论说不定也不会那么快出来。
所以，我感谢banq,同时也感谢你。
你提的问题很好，我本身把数学基础作为软设开发者的本能了或者说必备能力，所以在写的时候，没有再拿出来。
J道是垄断专制和个人英雄主义的天堂?
我觉得不太像!
banq的做法可能太过.
如果能开出一个非技术论坛
那就好了.
把非技术性问题都扔过去-------而不删除.
这个建议以前有人提出过,我今天再提一下.
> 数据库也不需要了.用XML文件代替,SQL也不需要了,XPATH,Xqu
> ry就够了,我想从XML构建对象总比从数据库强吧．一开机，把
> ML文件倒进内存，一关机把内存到出到XML文件.如果Flash内?> 足够快，足够便宜，我看内存都不需要了，CPU直接操作文件?> JAVA等高级语言也不需要了，大家只要懂XML,XPATH, XSLT,
> XQUery就够了．大家想一想，刚开始Java多慢那，现在大家都
> 盟俣刃阅懿皇俏侍猓焖倏⒆钪匾绾慰焖俚南煊
> 户的需求才是最重要．什么时候中国出一XML领域的大拿，才?> 在编程史上留下中国人的名字，要不整天看洋人名字多烦啊．
> 业慕崧郏涸诨鞯陌镏拢XML统治下一个时代的编程，程序
> 北涑烧嬲睦读欤蠹腋峡旄男邪桑旰螅岩韵胂螅
> ．欢迎拍砖.
>
>
>
呵呵，n年之后，共产主义到来了，我们不用这般辛苦地工作了，天天泡在网上发贴回贴多好！
无聊的讨论，还是探讨一些实际问题吧。
“一山不容二虎”的说法恐怕有问题：你不用数据库吗？你的数据库不需要优化？你不需要分析那些Entities的存储特性？难道你在Cache中执行SQL？你的MDA工具能够生成正确的Index？
对于一般的OLTP应用，如果数据量比较小（百万以下），数据分布比较平均，那么banq的说法是有道理的，你只需要利用UML进行设计，然后分析出持久类那么数据库就自然生成了。
但是，如果是海量的数据应用，或者是基于OLAP（例如决策分析）的应用，恐怕系统设计再合理也没有用。
>不用数据库吗？你的数据库不需要优化？你不需要分析那些Entities的存储特性？难道你在Cache中执行SQL？你的MDA工具能够生成正确的Index？
数据库是不必用的，数据库当然更不需要优化，字段长度都是256，很少访问数据库，这些优化对于J2EE系统来说只是隔靴饶痒。
O/R mapping组件已经帮助我们实现一些优化和使用存储特性。
你的这些问题就象在问操作系统不重要一样。我想我们关注的角度是不一样的。
这不是无聊问题，而是涉及你是否真的在使用OO思考、设计和编程。
正是"一山不容二虎"，你重视数据库，你的J2EE系统就无法完全OO，你只有忽视数据库，你才有可能完全迈向OO。
Bang老师那具体是怎么体现这中设计思想的了，比如在jdonnewsdemo中
――――――――――――――――
好像体现的不是很明显啊！～
偶是个新来的菜鸟，但有一事不明想请banq老师或是banq老师的老师们来回答--假如有一天真的实现了您的全oo，那有什么实际的意义呢？只是为了一种近乎慈善般的举动把程序员们可能得到的薪水拱手送给那些云扇雾照的mda的布道者们么？对象说道底不还是数据的另一种具备状态的集合表现形式么？从对象的角度来说，也许数据库里存储的不正是最细粒度的若干个“数据”对象么？好象造汽车的会把他的零件库尽可能的细化到最细的粒度螺丝钉一样，企业主们大都喜欢收藏那些最细粒度的生产资料，以及能够代表他们的数据系统，比如BOM,虽然一切都对象化可能更好，但偶觉得这似乎失去了象组装积木一样把最细化的数据能够按照企业千变万化的需求来产生对象的一种乐趣，而如果想把数据象赌神手中的扑克牌一样随心所欲的玩弄于鼓掌之上似乎离不开数据库的支持的，否则在得到了编程角度的愉悦的同时，又将失去另一个持久化存储数据信息方面所带来的好处，所以偶觉得，最多发展到对象数据库成型也就到头了，好象乞丐之王还是乞丐一样，对象数据库也还是数据库，或许有谁能作出什么aspect database来考验数据库理论的坚实，没关系rdbms不是那么轻易会败阵的;-)
至于7*24小时集群任何系统的神话，好象很容易的被911之类的事件或是供电系统的灾难故障来轻易的打破，到那时谁来声明对遇难的对象们的状态信息来负责呢？偶猜也只有做到mid-ware和rdbms后端共同作到高冗余也就得了，可以学习学习garbage collector 的做法规定个亚当夏娃什么的，以尽可能短的时间来完成对象状态到后端rdbms的高速存储，没必要谁来取代谁，银行家们的webservice贷款计算程序和main frame不也是共同存活的很好么，没见到有谁实现了grid就扔掉了超大型主机啊，在现实社会这个大的容器限制的范围内，新的技术的发展似乎并不是什么革命，而更多的时候是与过去的技术的互补与融合。
新来并初发贴，胡说的文字比较多，请banq老师海涵，偶正准备借阅您的那本著作来学习，不知道到时候有没有空能得到您在网络那端的指点;-)
顺路插一句，感觉那些uml fans们有点象那些想用osi模型或是什么atm的系统来取代并同意tcp/ip协议栈和路由器一样，想用mda来统一编程世界，但现实是在网络发展到t级甚至更高速率的今天，甚至连推一个美好的ipv6都很难，于是那些描绘远景的人们的语言似乎兑现的很慢也很有限了，也有更多的人在脚踏实地的做一些新应用的研发了。rfid，wmax或者3g的慢热也似乎与曾经的热忱期待难成正比，但恰好说明了一个问题-作为一种应用的科学和工具，计算机，无论是软件和硬件也好都要服从于用户需求的大局，并不是哪一个学说和理论可左右的。mda推崇的无需写代码的思想和当年的oo理论战胜结构化编程不同之处在于--它是很难实现的一种理想状态。
基于自己的这个想法，于是带着被认为菜到极点也认了的一种心态，来此求教banq老师，到底全oo的好处何在？这方面偶确实是无知的，甚至不知道组合型的catalyst在ooa/d理论中的位置，但偶总觉的全oo有点靠不住,比如象好的erp实施一样最好先做什么bpm，但从程序员的角度来看，谁来完成将企业瞬息万变的市场需求梳理成好的对象结构呢？这里是将来咨询公司可介入的地方么？。但处于技术基础的薄弱，却不知道这种担忧究竟来自于那里。希望得到您的回复
抛开技术论点而言文章写的很有文采哦！哥们学院派出生？学文还是学理啊！俺正写论文了！有你这么好的文采就好了哦！◎哥们给我支两招撒！
我不同意“板桥里人”的观点，J2EE的作用被夸大了。现在仍然有许多应用系统的开发需要数据库，比如银行的业务系统。不可否认，在诸如电子商务这样的应用领域，J2EE显得更加重要，但在涉及到海量数据存储和计算的应用系统中，数据库仍然占据着核心地位。我觉得面对任何一项新兴的技术和理论，我们都应该保持理性的态度，而非狂热的崇拜。J2EE给予我们的是更多的选择和想象空间，而非否定其他技术和理论的理由。
shuiwz有些观点我还是赞同，是有思考深度的。
>到底全oo的好处何在?
这个问题类似设计模式有什么好处，这可能还是对人而言的，对于只掌握过程思维的初学者来说，走向全OO是一个飞跃；对于一个真正全OO的系统，最大的衡量标准是否松耦合？所以不能为了OO而OO，关键是为解耦。
另外根据我的个人经验，从OO分析开始到OO实现，整个分析实现过程比较自然，否则发生 对象和数据库的阻抗问题:mismatch，由于只关注系统两端：数据表和界面；结果使得J2EE系统的中间部分变得混乱而无序，反而丧失了多层结构易于维护和扩展的优势。
这种重数据库和界面的思维编程习惯最初是反应在EJB上，很多人抨击EJB中的实体Bean不是好东西，其实是他的坏思维导致，后来他选择了彻底的O/R Mapping，比如Hibernate，到最后发现Hibernate性能还是很低，为什么呢？难道是这些技术错了吗？是他使用错了，这个观点我已经重申了N多年了。
现在，要彻底改变这些问题，不是靠什么更好的技术，而是要更新思维，变成纯OO，或全OO思维，改变从以前注重系统两端到注重系统的中间部分，从中间件建模开始，将最大力气花在模型建立和中间DTO优化以及性能缓存、Pool等使用决定上。
另外，组合型的目录在OO中是以组合模式来实现，不知回答正确否？
全OO的系统由于实现松耦合，使得系统更善于应付企业变化的需求，经常修改不会影响其他功能，全OO实现了应需而变，为什么IBM敢说出这种话？他敢于放弃PC和笔记本事业，那是因为他找到并且已经完全掌握应需而变的法宝和解决之道。
我虽然不敢和IBM那些大牛相比，但是我也看到并自己实现了一些，应需而变的理想境界真是可以看得见的，我们不能再怀疑全OO了。