讨论一下设计模式吧？

dlee，方便的话也发一份，对你说的设计方法很是有兴趣。想看看干的，不方便就拉倒
thanks!

猜测 dlee 的公司把javaScript编程推向了极致！
js编程困难多多，不过国内有不少公司把js搞得出神入化
令人赞叹不已,  Dlee 可否介绍一下js的编程技术？

呵呵，不夸张地说我们对 JavaScript 的了解和使用 JavaScript 的水平是国内少有的。
O'Reilly 的《JavaScript 权威指南》是我知道的最好的 JavaScript 专著。
http://www.oreilly.com.cn/catalog/javaScriptTDG4/index.htm

你们的系统前端是否就是依赖 js 呢？
很想请 dlee 介绍一下 js 编程方法，技巧，平台及兼容性方面的东东。
估计在坛的各位没有人在 js 上下过功夫。

对啊，希望dlee等达人说说JavaScript方面的东东。虽然现在JavaScript用的很普遍，但是都是一些简单的应用，很想了解一下实际的应用情况。

我们前端确实只依赖 JavaScript。后端只需要写一些 XML 格式的配置文件就可以了，大部分情况下不需要开发 Java 代码。简单地说就是我们通过 XMLHTTP 和后端 Servlet 的联动，使得前端的 JavaScript 获得了访问数据库的能力。我们的程序员大部分时间是在写 JavaScript，一旦项目框架（页面）搭起来之后修改是很快的，很多时候就是改改后端的 XML 配置文件。可以把我们的中间件看作一种用 JavaScript 实现的 ORM，但是我们比 ORM 做的事情还要多很多。
JavaScript 的编程方法在《JavaScript 权威指南》中已经说的很详细了，只不过我们把 JavaScript 面向对象编程的能力发挥到了极限。
我们目前是只为 IE 开发的，主要是因为 IE 和 Mozilla/Netscape 在事件捕获机制上差异太大，而我们的表示层次控件严重依赖事件处理。不过我们的平台移植到 Mozilla 上也是完全可能的，因为 Mozilla 同样支持 XMLHTTP 的通信方式。

JavaScript 可是个好东西，可惜很多人还不清楚它的潜力。我们的客户使用的都是象 IE 这样的胖客户（我们还没有考虑支持 PDA 这样的瘦客户）。它已经这样胖了，让它歇着不是太可惜了？

我也觉得Javascript这个东西应该好好利用。

Dlee，有空在你的专栏里面写的XMLHTTP的文章share给大家吧。

的确匪夷所思。
可惜不懂什么是XMLHTTP.
DLEE, 可否上传一个XMLHTTP 的 DEMO 小程序？

dlee兄, 其实你们用的这种结构就是一种你们自己定义的模式, 用来解决你们公司一类的问题.
模式不仅仅是四人帮的书上提到的那些.
现在绝大多数人的观点都是, 模式虽好, 但是不能滥用, 用多了, 用过了, 反倒是种倒退. 关键是要看能不能解决具体问题. 在敏捷建模中就要求不滥用模式.
但是模式重要吗?  重要!!  这点我深有体会.  在大型系统的你的技术构架(一种或多种模式的组合)如果做的不好, 那么这个系统很可能失败, 或者说在后期很难优化性能和扩展.
所以我认为在大型系统中技术架构大于任何具体技术的应用.  而在其中就需要谨慎的使用模式.

你说的很对。我是属于折中派，既不是模式的坚决拥护者，也不是坚决反对者（实际上我认为《设计模式》这本书是对我非常有帮助）。关键还是要看在什么样的场合。《设计模式》中对于每一种模式的适用场合、如何与其它模式搭配使用都有详细说明，一定要用心体会。用错了场合，反而达不到预期的目的。另外如果能用更简单的方法解决问题，就不一定要使用模式（使用模式是不是有一种很牛的感觉？呵呵）。尽可能保持体系结构的简练、容易理解是非常重要的，直接关系到项目的成败。另外已经列入教科书的模式能解决的问题是有限的，在特定的场合，如果发现自己的解决方法比使用某种模式能更好地解决问题，那么就使用自己的解决方法好了。也许你自己就能创造一些模式。模式是在发展的，千万别把模式当作死东西。
模式是 OOP 很重要的发展，但是现在国外软件业已经超越了模式，出现了反模式和 AOP 等最新的发展。一定要跟上这些发展的步伐，这样你的职业生涯才能永保青春。
自动测试、重构、XP 和敏捷建模都是我近期最关心的一些问题，希望我们能够开展深入的讨论。

关于软件体系结构，有本书我觉得还不错。
《软件架构——组织原则与模式》
http://www.cnforyou.com/query/bookdetail.asp?viBookCode=7202