未來的潮流是rich client
打開瀏覽器就可以實現(xiàn)自動升級
而且效果比現(xiàn)在的client更好
最后和B/S是完全一樣的工作機(jī)制

現(xiàn)在就是adobe的flex vs microsoft的sliverlight

個人看好sliverlight

flex大概要到5.0才可以成熟起來
現(xiàn)在follow它都是當(dāng)小白鼠

終于3.0了？
它2.0 bug又多，ide又差
沒想到3.0沒出幾個beta版就release了

你這個其實叫Dao

不素Facade

這一點和win32api很像

有種東西叫代碼規(guī)范。。。
這種規(guī)范其實是以前流傳下來的。在Java1.3版本里，+被翻譯成String.concat，會造成JVM留著大量的字符串。
在那時候是禁止寫+的，所以這種規(guī)范留到現(xiàn)在也是不允許寫+號的。

如果反編譯class文件會看到1.4版本后+被翻譯成StringBuffer，并沒有性能上的損失。

昏
flex你也敢用，我們現(xiàn)在就用flex做web開發(fā)
我把它的lib反編譯了一把，然后去adobe的bug區(qū)逛了一把
友情建議你，flex3.0以后再來看看
flex這種不成熟的玩意還要經(jīng)歷大改動

要承認(rèn)中國的軟件業(yè)已經(jīng)落后了。開源需要一大批水準(zhǔn)相當(dāng)?shù)某绦騿T參與，但是中國現(xiàn)在有那么多人嗎？有那么多人甘愿投入多少個人月做這樣一件完全沒有收入的事情嗎？

M$在技術(shù)上已經(jīng)落后于Java了。現(xiàn)在的C#語言也好VS也好處于一個追趕期。
從深層次上是兩者觀念的差異，eclipse是希望程序員自己動手，自己來完善，它只提供一個平臺。而MS是希望程序員一點擊就可以運(yùn)行，超級上手快。
單純從技術(shù)上來說，MS應(yīng)該選擇放棄兼容一些過時技術(shù)但是它那樣做的話就會失去市場

eclipse的體系設(shè)計很好，而vs2008幾乎不可能轉(zhuǎn)型成為eclipse那樣完全基于OSGi的設(shè)計。
因為M$投入的人年太多了，很難想象推倒重來而且還要經(jīng)受住工業(yè)化的測試。

而eclipse因為它免費，另一個是因為它在java ide里幾乎沒有遇到競爭對手，所以它可以從容的大修大改。
eclipse2.0的版本是不支持increment compile的，要編譯就全體編譯，-_-!
eclipse2.1后面的版本，幾乎每個版本都有API改動。而且更新非常快，快到Milestone版本里API都不一樣。這時候為eclipse寫插件幾乎沒法維護(hù)，且不說換個版本就編譯不過，而且某些個必須功能只存在于M版本里，而這些M版本幾乎都有這樣那樣的bug。
3.0后eclipse又遵循OSGi重寫底層代碼，不過API穩(wěn)定很多。當(dāng)然3.0到3.3改動還是很大，不過大方向已經(jīng)穩(wěn)定了。

不過根據(jù)我對JDT的認(rèn)識并不存在Eclipse Compiler，而是基于AST的詞法分析。你能即時啟動主要是因為你Ctrl-S的時候class已經(jīng)編譯好了，后面只是javaw的問題了。
而.net每次當(dāng)你修改后代碼啟動的時候都重編譯一次工程，所以-_-!!

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

首先去掉&#和結(jié)尾的;，然后取到0125（10進(jìn)制），強(qiáng)制轉(zhuǎn)化為int，然后再轉(zhuǎn)為char。因為里面的編碼和unicode一樣所以可以轉(zhuǎn)為char，取到unicode字符（？不確定）

這段代碼不能運(yùn)行因為你寫了String a="開始兌獎";這句不對，這句應(yīng)該是String a="〹";這樣的。

不過我覺得這種方式不太好，因為應(yīng)該有更好的方式轉(zhuǎn)化。等找到了再貼上來。

一般都是Service-BusinessLogic-DAO這樣的三層模式。
不過遷移數(shù)據(jù)庫基本上都素很痛苦的事情。
需要設(shè)計的時候就具備很高的素質(zhì)，對程序員也有很高的要求。
所以我們很少做到這種業(yè)務(wù)。

哪個工具實現(xiàn)了這個功能？

我在excel2003中打開POI寫的excel就直接掛掉了，什么都沒有。

POI現(xiàn)在還沒有更新過，我看素廢掉了。

AOP素個好東西，現(xiàn)在的實現(xiàn)上的問題只是因為sun不肯自己去寫一個改bytecode的API而已。
OpenSource里面的東西沒有經(jīng)過嚴(yán)謹(jǐn)?shù)臏y試自然會有這樣那樣的問題。
不過估計sun最后自己會拿一個版本去改個官方的實現(xiàn)。
至于在大項目中的應(yīng)用，2005年一個上千人月的項目中就用了。

AOP也不是OO的競爭伙伴，而是彌補(bǔ)OO的不足。


現(xiàn)在的框架我覺得也不需要全理解，搞得很高手，很有技巧，因為這種東西一方面還在完善中，一方面新陳代謝很快。應(yīng)該去理解它的思想，知道他應(yīng)該干什么，怎么去做。基本就夠了。

樓主我看是把理論和實現(xiàn)混淆了。
一個東西，理論可能很先進(jìn)，但是實現(xiàn)起來會有這樣那樣的問題。
不過實現(xiàn)的不好不代表這個理論就廢掉了。

現(xiàn)在潮流的大方向是簡單化，傻瓜化，提高生產(chǎn)性，降低技術(shù)難度。所以hibernate,aop,包括Linq應(yīng)運(yùn)而生，這是需求的產(chǎn)物。在大規(guī)模開發(fā)中，從資金，時間都不可能要求coder們都有很高手的水平，犧牲一定的性能提高開發(fā)效率是大勢所趨。或許再過10年，就不需要你寫什么SQL了，在ER圖里拖拖拉拉就可以生成SQL，和現(xiàn)在做網(wǎng)頁一樣。呵呵。

hibernate我也看過它的一點源代碼。hibernate的優(yōu)點我看主要是輕量級的封裝，它里面的設(shè)計也很好，我看起來很輕松。至于HQL，把數(shù)據(jù)庫關(guān)聯(lián)的部分再抽象出來，思路正確，但也不是多復(fù)雜的東西。
對被EJB2.1折磨過的我來說，這樣一個簡單易用易于二次開發(fā)的框架，的確是很滿意了。

其實hibernate和SQL倒沒什么對立，只不過把SQL封裝了一下。