牙牙窩

初衷是希望有一個(gè)簡便，不需要配置文件的辦法，提高數(shù)據(jù)層的事務(wù)處理能力。以及對連接池的支持。

解決思路是通過修改Spring框架，修改BeanFactory的類搜索機(jī)制，默認(rèn)載入相應(yīng)的類。

并采用繼承的方式，在基類中提供默認(rèn)方法，允許Spring注入在對象實(shí)例中。然后再對象實(shí)例中調(diào)用。

    最近項(xiàng)目組要求使用普元EOS進(jìn)行項(xiàng)目開發(fā)，使用了兩個(gè)月左右，雖然說有一些心得（這個(gè)以后會(huì)寫出來），但更多是看到了不足的地方，在這里就討論一下一個(gè)成熟的應(yīng)用框架到底應(yīng)該有哪些因素。

底層技術(shù)：
    Application Framework（下稱應(yīng)用框架）是為解決問題而生的，無論是基于JAVA、C++、Ruby等等語言，都必須有基礎(chǔ)技術(shù)的支持。如JAVA就有經(jīng)典的Struts+Spring+Hibernate的組合，因此，一個(gè)成熟的應(yīng)用框架，必須擁有完善的MVC框架，以及完整的業(yè)務(wù)組件管理容器，還有一個(gè)成熟的數(shù)據(jù)訪問框架。這個(gè)是一切的基礎(chǔ)。

權(quán)限管理：
    擁有一個(gè)成熟基礎(chǔ)權(quán)限架構(gòu)能夠?yàn)閼?yīng)用框架增色不少。如果能夠和框架本身更好地融合，這樣更好。其實(shí)目前有很多實(shí)現(xiàn)是俄可以借鑒的，如：ACEGI和Spring。

UI：
    標(biāo)簽已經(jīng)非常流行，擁有完善的標(biāo)簽庫是必不可少的，Struts是個(gè)很好的典范。
    Ajax大行其道，如果沒有整合一些方便易用的AJAX控件，估計(jì)也算不上是一個(gè)好框架。
    另外還有類似于Freemarker、Velocity之類的簡化UI開發(fā)的好東東，整合一兩個(gè)，對于減少開發(fā)、提高維護(hù)性有很大幫助。

開發(fā)工具：
    提供敏捷快速的開發(fā)工具是一個(gè)成熟應(yīng)用框架所不可或缺的。使用一個(gè)成熟的應(yīng)用框架的開發(fā)工具進(jìn)行開發(fā)，可以讓開發(fā)者最大程度減少對于技術(shù)上的瓶頸，讓開發(fā)者很輕松就可以完成高質(zhì)量的代碼，剩下的精力可以用于專注于業(yè)務(wù)等其它方面。
    另外還有像：單元測試、應(yīng)用部署等等方面，都是必不可少的一部分。（PS：我是非常痛恨維護(hù)幾百行ANT的build.xml代碼的人）
    這里不得不稱贊一下普元，普元提供的開發(fā)環(huán)境和它自身的底層技術(shù)融合的非常好，對于開發(fā)者而言，是非常方便的，可以不需要很多的培訓(xùn)就可以使用IDE開發(fā)出完整的應(yīng)用。而且測試和部署都很方便。

代碼生成器：
    其實(shí)這個(gè)應(yīng)該和開發(fā)工具放在一起，但是因?yàn)楸容^重要，所以單獨(dú)提出來說。
    一個(gè)好的代碼生成器可以省去開發(fā)人員很多不必要的麻煩，能夠非常大地提高開發(fā)效率。普元的代碼生成器是個(gè)不錯(cuò)的典范。
    我們公司自己也有一個(gè)JOP的應(yīng)用框架，但非常簡陋，和普元的設(shè)計(jì)思想不可同日而語。呵呵～～有點(diǎn)扯遠(yuǎn)了，但能夠看得出，代碼生成器對于應(yīng)用框架是必不可少的。

協(xié)同開發(fā)：
    整合一個(gè)好的協(xié)同開發(fā)和版本管理工具，能夠最大程度地降低溝通成本。除了能夠支持類似SVN或VSS之類的代碼版本管理工具之外，還應(yīng)該融合進(jìn)類似Visual Studio Team的任務(wù)管理和缺陷管理工具。最好擁有一個(gè)可以進(jìn)行自我積累的知識庫的實(shí)現(xiàn)。WIKI是個(gè)不錯(cuò)的主意。

設(shè)計(jì)器：
    我提出這個(gè)是因?yàn)榭吹搅薎BM的RUP，擁有一個(gè)能夠從設(shè)計(jì)到代碼實(shí)現(xiàn)乃至后面的測試這樣一個(gè)全流程開發(fā)工具，一直是IT人員的一個(gè)美好夢想。
    一個(gè)好的設(shè)計(jì)器，可以很輕松地在設(shè)計(jì)圖和代碼之間相互轉(zhuǎn)換，對于需求變更，設(shè)計(jì)管理、甚至項(xiàng)目后期的文檔都有很重要的意義。
    這里又要提到普元，普元在這方面很聰明，走了一條不同的路，它把代碼變成一個(gè)個(gè)圖標(biāo)時(shí)，本身就實(shí)現(xiàn)了對于設(shè)計(jì)圖和代碼之間互轉(zhuǎn)關(guān)系。（當(dāng)然，實(shí)現(xiàn)的方式有點(diǎn)土，而且沒有辦法支持標(biāo)準(zhǔn)的UML）

運(yùn)行容器：
    大家可能覺得奇怪，容器為什么要單獨(dú)提出來說，很多JAVA開發(fā)者都會(huì)說，只有遵循JAVA標(biāo)準(zhǔn)就可以啦～。其實(shí)不然，一個(gè)成熟的應(yīng)用框架當(dāng)然要考慮其兼容性，但是有時(shí)候，過多考慮兼容性往往會(huì)犧牲效率。事實(shí)上，很多應(yīng)用框架被開發(fā)出來，都是有一定的局限性的使用場景，針對使用場景的環(huán)境進(jìn)行優(yōu)化，絕對比使用通用的方法效率要高的多。如我們公司的移動(dòng)項(xiàng)目使用的是WebSphere，我們的框架就有一個(gè)針對WebSphere優(yōu)化的版本，但同時(shí)也存在一個(gè)通用版本。
    當(dāng)然還有其它方面也可以引用這種思路，比如使用Oracle自帶的一些JDBC類，其效率就比使用JAVA標(biāo)準(zhǔn)的JDBC類要高得多。

    其實(shí)應(yīng)用框架被創(chuàng)造出來的目的就是快速、高效、低成本地解決問題，這個(gè)大家都知道，但是何謂“成熟”，估計(jì)100個(gè)人應(yīng)該有100個(gè)答案，這里我的理解就是開發(fā)快捷、較低的學(xué)習(xí)成本、運(yùn)行穩(wěn)定，就是一個(gè)成熟的應(yīng)用框架。

PS：上面好像說了一些不少普元的好話，大家千萬不要以為我是普元的“托”，晚點(diǎn)我再寫遍罵它的文章吧～～呵呵～～。其實(shí)我更喜歡SpringSide，但是除了“底層技術(shù)”這塊之外，在其它方面還有很長的路要走，希望江南白衣兄能夠堅(jiān)持下去。

    今年真的是郁悶透頂了。項(xiàng)目組居然叫我去做我從來沒有做過的接口方面的編程，搞得我焦頭爛額。

    因?yàn)闆]有經(jīng)驗(yàn)，寫的代碼亂七八糟，出了好多問題，不過，也學(xué)了不少東西。

    首先就是Socket的編程，我只是在學(xué)習(xí)JAVA時(shí)寫了一些socket方面的例子，從來就沒有仔細(xì)研究過，組長居然叫我設(shè)計(jì)一個(gè)JAVA的接口平臺(tái)。胡弄了一通之后，系統(tǒng)上線了。但是問題就來了。

    首先第一個(gè)問題，長連接必須有心跳。因?yàn)橹皡f(xié)議中沒有定義心跳協(xié)議，而我又沒有經(jīng)驗(yàn)，所以等真正上線之后才發(fā)現(xiàn)，如果長連接沒有心跳，很容易導(dǎo)致在Socket連接中，長時(shí)間沒有通訊的話，就會(huì)導(dǎo)致連接雖然保持，但不能正常通訊的問題。

    第二個(gè)問題，必須加入流量控制。這個(gè)問題出現(xiàn)在業(yè)務(wù)高峰期時(shí)，會(huì)接收到大量請求，這時(shí)業(yè)務(wù)系統(tǒng)的處理速度跟不上請求發(fā)起方，導(dǎo)致大量請求積壓在Socket服務(wù)器端，導(dǎo)致JVM崩潰。這個(gè)問題我之前是使用了JAVA5中所帶的ExecutorService，通過設(shè)置固定的線程池?cái)?shù)量的方式做流量控制，后來發(fā)現(xiàn)不行，線程會(huì)不斷增加，導(dǎo)致JVM崩潰。不知道是我代碼問題還是ExecutorService本身的問題。建議使用BlockingQueue來做隊(duì)列，我目前用起來還是比較穩(wěn)定。

    第三個(gè)問題，是由上面的問題衍生出來的一個(gè)問題，就是效率問題。我之前的線程處理方式是每接到一個(gè)請求，會(huì)在主線程實(shí)例化一個(gè)線程實(shí)例，再把線程放到線程池中運(yùn)行，這個(gè)方式除了導(dǎo)致上面的問題以外，而且效率很慢，我稱之為“推”的方式。現(xiàn)在經(jīng)過改良后，在服務(wù)起來之后，先事先運(yùn)行固定數(shù)量的線程，然后所有線程都從同一個(gè)BlockingQueue中獲取指令，我稱之為“拉”的方式。這種方式讓程序效率提高了很多，省去了每次生成對象的過程。而且這個(gè)設(shè)計(jì)本身也實(shí)現(xiàn)了處理量的控制。

    第四個(gè)問題，就是指令的返回問題。在處理每個(gè)異步指令的過程時(shí)，對于返回指令，通常的做法是將返回結(jié)果指令放入隊(duì)列中，然后再逐一返回。這個(gè)做法就存在了一個(gè)隱患，就是當(dāng)服務(wù)器的進(jìn)程core掉，或者因其它原因中斷，所有的返回指令都會(huì)丟失。建議的做法是在得到返回指令之后，將要返回的結(jié)果指令持久化，通常是放入數(shù)據(jù)表或者緩存文件中，然后再操作，這樣的話，當(dāng)重啟進(jìn)程，也可以重新讀取返回指令，最大可能保證接口的數(shù)據(jù)準(zhǔn)確性。

    第五個(gè)問題，其實(shí)跟上面有一些接近，就是做接口程序，有一個(gè)大原則，就是一切有跡可尋。在受理時(shí)要寫日志，執(zhí)行業(yè)務(wù)時(shí)要記錄、返回結(jié)果時(shí)要入庫。總之讓運(yùn)維人員可以很方便的定位問題，排除問題。否則，只能麻煩自己啦！

    至于其它錯(cuò)誤我就不一一羅列了，總之在錯(cuò)誤中進(jìn)步，還是學(xué)到不少知識。呵呵～～

???非常有幸能調(diào)到公司的J2EE基礎(chǔ)架構(gòu)組，負(fù)責(zé)為公司預(yù)研一套完整的架構(gòu)模型。主要是引入SOA、WorkFlow、AJAX等新技術(shù)。
???
???做了開發(fā)人員這么久，也做了這么久項(xiàng)目，根本就沒有時(shí)間好好坐下來研究一下新技術(shù)。現(xiàn)在必須先跟一跟潮流，看看那些流行的技術(shù)以及概念了，呵呵。。。。。。

???研究主要是分三個(gè)方向：UI、BPM/SOA、構(gòu)件化。希望能在這幾個(gè)方面有所收獲吧！努力努力！！！

1 ：毛巾擦身的鍛煉減肥
把毛巾浸在冷水 ( 自來水 ) 中擰掉 大部分水后，依次推擦上肢、下肢、腰部、后背、頸部、腹部、胸部，每一部位反復(fù)推擦 10—20 次。在推擦中反復(fù)浸洗毛巾，以保持一定的低溫及濕度。
冷水擦身可以消耗大部分熱能。熱能是身體內(nèi)的糖、脂肪所轉(zhuǎn)化，故消耗熱能，即是消耗糖和脂肪，促進(jìn)糖和脂肪代謝，起到調(diào)膚美顏的作用。（現(xiàn)在是冬天了哦 ^-^ 不知道你能不能堅(jiān)持。還可以抗感冒的） —— 我估計(jì)這個(gè)方法我是不成了，麻煩不說，身處北方還要用冷毛巾，我只能給自己一個(gè)結(jié)論 —— 找死。

2 ：曲米茶

把粳米像炒瓜子一樣炒至焦黃再煮成粥，這個(gè)叫曲米茶。聽說原理是破壞主食中的淀粉，變成了活性碳，還能刮油呢。聽說還能緩解便秘。我在夏天的時(shí)候吃過，雖然沒有大的感覺，但是我想總比吃過多的主食擔(dān)心發(fā)胖要好。

3 ：拍打局部

哪里胖就拍打哪里，打紅了為止，還要配合揉、捏、推擠等手法，總之讓肉動(dòng)起來。要是有貝貝油就好了，減少點(diǎn)摩擦肚子還能好受一點(diǎn)，要不會(huì)很疼。

懶人減肥食譜

1 ：早餐，曲米茶一碗。 早飯與午飯之間蘋果一個(gè)，要切成小瓣，分幾次吃掉。橘子半個(gè)吧。

2 ：午餐，曲米茶一碗，中午適當(dāng)?shù)某孕┦卟耍遣荒芏唷?/span> 午飯與晚飯之間蘋果一個(gè)，橘子半個(gè)。

3 ：晚餐，曲米茶一碗，配合適當(dāng)?shù)氖卟恕?/span> 睡覺以前最好什么都不吃，要是餓了呢，就喝牛奶 120 克 ，多了浪費(fèi)。

減肥期間少吃含鹽高的食品，減少喝水次數(shù)。別人我是不知道，但是我自己我非常清楚，喝水基本對減肥起不到好的作用，還很有可能誘發(fā)濕疹，曾經(jīng)有過一次慘痛的教訓(xùn)。白水改為紅姜茶，有排毒功效。配合一天兩次的局部按摩，主要集中在身體中段，主要針對我的 3 層游泳圈。

健康的減肥計(jì)劃即將開始了， 堅(jiān)持就是勝利！！

??????? 這個(gè)題目有點(diǎn)老土，因?yàn)閯e人用過了。但經(jīng)過這段時(shí)間的觀察，發(fā)現(xiàn)聚合的能力

已經(jīng)開始慢慢延伸，已經(jīng)成為了一種文化。已經(jīng)沒有人能躲開這個(gè)大潮的來臨。

??????? 既然不能躲，那就迎上去吧！

??????? 關(guān)注Web 2.0，其實(shí)就是關(guān)注網(wǎng)絡(luò)的走向。冒昧的說一句我的理解：Web 2.0 = 聚合力