未来的潮流是rich client
打开浏览器就可以实现自动升级
而且效果比现在的client更好
最后和B/S是完全一样的工作机制

现在就是adobe的flex vs microsoft的sliverlight

个人看好sliverlight

flex大概要到5.0才可以成熟起来
现在follow它都是当小白鼠

终于3.0了？
它2.0 bug又多，ide又差
没想到3.0没出几个beta版就release了

你这个其实叫Dao

不素Facade

这一点和win32api很像

有种东西叫代码规范。。。
这种规范其实是以前流传下来的。在Java1.3版本里，+被翻译成String.concat，会造成JVM留着大量的字符串。
在那时候是禁止写+的，所以这种规范留到现在也是不允许写+号的。

如果反编译class文件会看到1.4版本后+被翻译成StringBuffer，并没有性能上的损失。

昏
flex你也敢用，我们现在就用flex做web开发
我把它的lib反编译了一把，然后去adobe的bug区逛了一把
友情建议你，flex3.0以后再来看看
flex这种不成熟的玩意还要经历大改动

要承认中国的软件业已经落后了。开源需要一大批水准相当的程序员参与，但是中国现在有那么多人吗？有那么多人甘愿投入多少个人月做这样一件完全没有收入的事情吗？

M$在技术上已经落后于Java了。现在的C#语言也好VS也好处于一个追赶期。
从深层次上是两者观念的差异，eclipse是希望程序员自己动手，自己来完善，它只提供一个平台。而MS是希望程序员一点击就可以运行，超级上手快。
单纯从技术上来说，MS应该选择放弃兼容一些过时技术但是它那样做的话就会失去市场

eclipse的体系设计很好，而vs2008几乎不可能转型成为eclipse那样完全基于OSGi的设计。
因为M$投入的人年太多了，很难想象推倒重来而且还要经受住工业化的测试。

而eclipse因为它免费，另一个是因为它在java ide里几乎没有遇到竞争对手，所以它可以从容的大修大改。
eclipse2.0的版本是不支持increment compile的，要编译就全体编译，-_-!
eclipse2.1后面的版本，几乎每个版本都有API改动。而且更新非常快，快到Milestone版本里API都不一样。这时候为eclipse写插件几乎没法维护，且不说换个版本就编译不过，而且某些个必须功能只存在于M版本里，而这些M版本几乎都有这样那样的bug。
3.0后eclipse又遵循OSGi重写底层代码，不过API稳定很多。当然3.0到3.3改动还是很大，不过大方向已经稳定了。

不过根据我对JDT的认识并不存在Eclipse Compiler，而是基于AST的词法分析。你能即时启动主要是因为你Ctrl-S的时候class已经编译好了，后面只是javaw的问题了。
而.net每次当你修改后代码启动的时候都重编译一次工程，所以-_-!!

这段代码意思是把HTML里的}改成字符串形式。

首先去掉&#和结尾的;，然后取到0125（10进制），强制转化为int，然后再转为char。因为里面的编码和unicode一样所以可以转为char，取到unicode字符（？不确定）

这段代码不能运行因为你写了String a="开始兑奖";这句不对，这句应该是String a="〹";这样的。

不过我觉得这种方式不太好，因为应该有更好的方式转化。等找到了再贴上来。

一般都是Service-BusinessLogic-DAO这样的三层模式。
不过迁移数据库基本上都素很痛苦的事情。
需要设计的时候就具备很高的素质，对程序员也有很高的要求。
所以我们很少做到这种业务。

哪个工具实现了这个功能？

我在excel2003中打开POI写的excel就直接挂掉了，什么都没有。

POI现在还没有更新过，我看素废掉了。

AOP素个好东西，现在的实现上的问题只是因为sun不肯自己去写一个改bytecode的API而已。
OpenSource里面的东西没有经过严谨的测试自然会有这样那样的问题。
不过估计sun最后自己会拿一个版本去改个官方的实现。
至于在大项目中的应用，2005年一个上千人月的项目中就用了。

AOP也不是OO的竞争伙伴，而是弥补OO的不足。


现在的框架我觉得也不需要全理解，搞得很高手，很有技巧，因为这种东西一方面还在完善中，一方面新陈代谢很快。应该去理解它的思想，知道他应该干什么，怎么去做。基本就够了。

楼主我看是把理论和实现混淆了。
一个东西，理论可能很先进，但是实现起来会有这样那样的问题。
不过实现的不好不代表这个理论就废掉了。

现在潮流的大方向是简单化，傻瓜化，提高生产性，降低技术难度。所以hibernate,aop,包括Linq应运而生，这是需求的产物。在大规模开发中，从资金，时间都不可能要求coder们都有很高手的水平，牺牲一定的性能提高开发效率是大势所趋。或许再过10年，就不需要你写什么SQL了，在ER图里拖拖拉拉就可以生成SQL，和现在做网页一样。呵呵。

hibernate我也看过它的一点源代码。hibernate的优点我看主要是轻量级的封装，它里面的设计也很好，我看起来很轻松。至于HQL，把数据库关联的部分再抽象出来，思路正确，但也不是多复杂的东西。
对被EJB2.1折磨过的我来说，这样一个简单易用易于二次开发的框架，的确是很满意了。

其实hibernate和SQL倒没什么对立，只不过把SQL封装了一下。