#
構(gòu)建一個項目，是一件極其復(fù)雜的事情。尤其是那種非常復(fù)雜的工程。
拿Java來說，構(gòu)建一個項目的問題有一下這么幾個：
- 項目的組織方式
- 項目的源代碼控制策略
- 項目的依賴控制（工程之間的依賴以及第三方庫的依賴）
- 項目的構(gòu)建方式
- 項目的構(gòu)建和發(fā)布周期
現(xiàn)在，有一些人還是在使用IDE來進(jìn)行項目的配置管理的，它的缺點是什么呢？
- 一般的IDE都擁有項目組織的功能。但是，可惜的是。IDE自帶的項目組織功能往往比較弱，IDE采取的項目組織方式都是平行式的，沒有項目的層次感，必須通過逐級命名來體現(xiàn)，比如foo項目下，有兩個子項目，于是分別命名為foo.bar和foo.demo，同理再深一層為foo.bar.web等，項目完全平行化管理（結(jié)構(gòu)未必一定是平行的，但是對于IDE而言，它們是平等的）
- 現(xiàn)在流行的IDE對源代碼控制工具都有非常不錯的支持
- IDE對同一個工作區(qū)里的項目依賴的控制作的非常不錯，但是形式相對單一
- 一般都是采用IDE自行手工構(gòu)建，某些IDE可以給你提供Ant腳本（比如NetBeans），如果采用復(fù)雜的構(gòu)建策略，那么要做很多手工的操作
- 沒法實現(xiàn)自動化構(gòu)建，隨著項目的增大，構(gòu)建成本越來越大，構(gòu)建和發(fā)布周期傾向于延長
現(xiàn)在，大多數(shù)的Java開發(fā)人員都采取了使用Ant腳本進(jìn)行構(gòu)建的方式。因為Ant腳本：
- 不會影響你的項目的組織方式，你可以隨意的按照任何方式組織你的項目
- Ant對源代碼控制工具有很好的支持
- Ant可以明確的管理和控制項目的依賴，通過Ivy可以自動下載項目依賴
- 自動化批處理的方式
- 支持構(gòu)建服務(wù)器，可以實現(xiàn)每日構(gòu)建
但是，Ant腳本也不是一點兒問題也沒有。首先，Ant腳本的重用性不好。一般意義上的Ant腳本重用，就是Copy&Paste。Ant對此沒有什么封裝。其次，Ant使用起來也比較困難，XML格式的腳本不是十分的好寫（有了Eclipse支持以后，強(qiáng)了很多），作為腳本語言，Ant非常的不完善（連字符串處理的功能都非常弱，這一點Ant-Contrib提供了一些好一點兒的支持）。Ant的擴(kuò)展機(jī)制完全基于Java，不能做到即時修改。
除了Ant，在Java中，還可以采用Maven進(jìn)行項目的構(gòu)建。Maven項目是一個非常出色的項目。首先，它體現(xiàn)了Apache資深開發(fā)人員的項目組織和管理智慧。另外，它以統(tǒng)一有效的方式實現(xiàn)了項目的整個構(gòu)建生命周期。Maven的黑盒化操作也給項目的配置管理減輕了負(fù)擔(dān)。如果采用了Maven的話，項目的組織方式、項目的構(gòu)建方式、項目的發(fā)布控制全部迎刃而解。而且你所作的擴(kuò)展，也是以插件的方式來透明化的起作用的。重用性比Ant高很多。使用起來也非常簡便。
但是，Maven也并不是沒有缺點。首先，Maven的項目組織方式是固定的，雖然這種固定的方式確實非常有道理。但是，如果與現(xiàn)有項目不兼容或者與IDE的項目組織方式不兼容的話，那么就完全不起作用了。比如Eclipse的Plugin項目，PDE的項目組織格式就與Maven2的項目格式完全不兼容。而且，Maven2自身的Manifest文件生成功能比較弱，對于OSGI項目而言，根本沒有可用性（因為要造成重復(fù)工作）。由于Maven采用的是黑盒操作方式。操作不透明。你如果想作一些簡單的自定義操作，也必須寫一個Maven的插件。插件的測試、調(diào)試和修改都要比Ant困難得多。
那么有什么好辦法呢？我推薦采用Ruby。
首先，Ruby是一種腳本語言，支持的環(huán)境有很多，而且還可以采用JRuby來運(yùn)行。而且，Ruby支持一個類似Make語法的腳本語言，那就是Rake。
Rake腳本其實就是標(biāo)準(zhǔn)的Ruby腳本，擁有所有Ruby擁有的特性（面向?qū)ο蟮龋６鳵uby也有非常好的依賴控制系統(tǒng)Gem（我個人認(rèn)為比目前的Maven的依賴控制系統(tǒng)要好）。由于Ruby是標(biāo)準(zhǔn)的解釋型語言，所以操作都是非常透明的，也可以做到即時修改的效果。所以，用來作構(gòu)建腳本是非常合適的。
但是，怎么用它來構(gòu)建Java項目呢？現(xiàn)在已經(jīng)存在一個基于Rake的Java構(gòu)建系統(tǒng)了，那就是：Raven。
Raven除了提供一些處理Java的Rake Task之外，它還提供了對Maven Repository的Gem封裝，這樣，你就可以采用Gem的方式來獲取Java的項目依賴了。
Rake是我所看到的第一個用面向?qū)ο笳Z言來寫構(gòu)建腳本的。但是，它也并不是完全沒有缺點的，對Java的支持太少，就是一個很討厭的缺點。
如果想要采用Rake，而且還要做到象Maven那樣好，那么至少要有以下幾個功能（除去Raven已經(jīng)提供的功能）：
- 新項目的Archetype功能
- Java項目構(gòu)建生命周期模型
- IDE支持
- 根據(jù)源信息生成項目信息網(wǎng)站
目前我能想到的辦法只有一個，就是自己寫（呵呵）。大家有什么高見？
中等收入家庭該如何理財？
專家建議：增加房產(chǎn)投資，安排適當(dāng)保險，構(gòu)建基金組合。 作者：陳婷
張平是某建筑企業(yè)的生產(chǎn)管理人員，月收入3000元。妻子是一名普通的公司職員，月收入2000元。兩人有一個活潑可愛的孩子，還未滿 周歲。一家三口每個月的基本生活開銷為1500元。另一筆大開銷是交通費(fèi)，由于張平的工作地點經(jīng)常都在郊外，也沒有班車可以搭乘，所以他的交通費(fèi)用每月將 近800元。兩人均為28歲，年輕力壯很少生病，沒有什么醫(yī)療費(fèi)支出，只是小寶寶需要平均每月200元左右的醫(yī)療保健費(fèi)用。這樣算下來，他們每個月可以結(jié) 余2500元。
此外，兩人的年終獎勵合計有8000元左右，存款和債券利息有5000元，股利、股息有1000元左右，年度性收入在14000元左右。年度性支出方面，則主要有一些人情往來，大約在1000元左右。另外還要孝順給父母1000元左右。
家庭資產(chǎn)多為存款
細(xì)觀他們的家庭資產(chǎn)，"最大頭"的比例就是存款了。其中現(xiàn)金和活期存款在5000元左右，定期存款則有20萬元之多，股票上投資了 25000元，去年還買進(jìn)了10000元的基金。加上35萬元的自住房，房子面積48平方米。目前，他們的家庭總資產(chǎn)為59萬元左右。由于他們是在結(jié)婚前 花了3.5萬元"成本價"從父母處購得的售后公房，所以目前也沒有什么債務(wù)。
5年后換購大房子
張平和妻子短期內(nèi)沒有什么特別大的計劃，倒是希望5年內(nèi)可以再買一套房子，或者以現(xiàn)有房產(chǎn)換購一套面積較大的房子。因為隨著孩子的逐漸長大，一家三口需要的生活空間肯定要增大，而且對居住環(huán)境的要求可能會越來越高。
未雨綢繆累積教育金
今年最讓張平和妻子開心的事情，莫過于兩人在去年有了個愛情的結(jié)晶。小孩現(xiàn)在還未滿周歲，要把孩子培養(yǎng)到大學(xué)畢業(yè)，還需要不少錢。正所 謂"可憐天下父母心"，張平和妻子甚至還希望在小孩成家時，至少能給孩子20萬元。這"教育金"和"子女婚嫁基金"可是不小的費(fèi)用，還需要努力積累。
考慮增加一定的保障
張平夫妻兩人的單位都有社保和醫(yī)療保險，父母均健在，也有社保。但父母現(xiàn)在健康不代表未來沒事，考慮到社保的保障力度不夠，還是有些擔(dān) 心他們以后的養(yǎng)老和醫(yī)療支出。小夫妻本身的健康醫(yī)療及養(yǎng)老儲備也是張平考慮的一個重點問題。張平目前的想法是，他希望自己和妻子退休后每年能有相當(dāng)于現(xiàn)在 2-3萬元的生活費(fèi)用。
期待專家的分析和建議
此外，張平認(rèn)為自己家的財務(wù)管理過于松散，為了順利解決孩子的教育費(fèi)用、自己的買房費(fèi)用、夫妻倆和父母的醫(yī)療和養(yǎng)老費(fèi)用，希望專家能幫他給出一定的分析和建議，以便他們能更加輕松地完成家庭的各項理財計劃。
專家建議一：資產(chǎn)配置分析
一、財務(wù)狀況分析
1.收支分析：張平夫婦目前家庭年度總收入為74000元。家庭總支出為32000元。結(jié)余比例為57%。可以看出該家庭是相當(dāng)節(jié)省 的。而且該家庭的收入也比較穩(wěn)定，主動性收入（68000元）占總收入的92%。但應(yīng)當(dāng)看到，隨著家庭新成員的到來和不斷成長（目前還沒有教育性支出）， 該家庭的日常開支將會慢慢提高。而且該家庭目前沒有安排任何商業(yè)保險，在這個方面顯然也需要有一些安排。所以該家庭未來的支出預(yù)期將會上升。
2.資產(chǎn)分析：張平夫婦目前家庭凈資產(chǎn)已經(jīng)有59萬元。其中金融資產(chǎn)為24萬元，房產(chǎn)資產(chǎn)為35萬元，金融資產(chǎn)比重為40.7%，還算基本合適。該家庭沒有任何負(fù)債，財務(wù)穩(wěn)健。家庭資產(chǎn)配置的主要問題是現(xiàn)金存款部分太高，占所有金融資產(chǎn)的83.3%，需要調(diào)整。
3.保障分析：盡管張平夫婦和他們的父母都有社保。但保障程度顯然不足，需要通過商業(yè)保險做一定的補(bǔ)充。特別在他們的孩子出生以后，這對小夫妻就更加需要保障了。
二、理財階段、理財重點和理財目標(biāo)分析
張平夫婦目前才28歲，孩子也剛剛出生。此時正是家庭建設(shè)和事業(yè)發(fā)展的重要階段。在該階段理財?shù)闹攸c應(yīng)當(dāng)是安排好家庭生活，同時應(yīng)當(dāng)集中精力到各自事業(yè)的發(fā)展方面，因此投資的安排不宜過于復(fù)雜，應(yīng)當(dāng)以簡單易操作為主要考慮原則。
張平夫婦對未來有很多設(shè)想和安排。他們提出的理財目標(biāo)主要有：
1.五年后再買一套房產(chǎn)或換購一套大房子，用于改善居住條件。
2.孩子未來直到大學(xué)畢業(yè)的教育費(fèi)用。
3.孩子未來的婚嫁基金：20萬元。
4.夫妻兩退休后每年能有相當(dāng)于現(xiàn)在2-3萬元的生活費(fèi)用。
其實，目前張平夫婦孩子剛剛出生，自己也很年輕，此時談?wù)?0年以后的孩子婚嫁或自己的退休都尚顯太早。目前階段理財?shù)哪繕?biāo)應(yīng)當(dāng)是將家庭現(xiàn)有的財務(wù)和孩子出生以后的家庭保障等方面要安排好。
三、當(dāng)前財務(wù)安排建議
1.增加房產(chǎn)投資：孩子出生以后的確需要更大的生活空間，目前48平方米三人居住顯得太擁擠。同時考慮到他們實際的資產(chǎn)狀況和未來月供 能力，我們建議目前就通過出售現(xiàn)有住房、然后支出現(xiàn)有存款10萬元左右，再負(fù)債15萬元來購買一套70萬元左右的房產(chǎn)，使得總居住面積達(dá)到75平方米以 上。而完全不必等到5年后再買。那時的房價和現(xiàn)在絕不是一個概念。而且該家庭目前資金充裕，又沒有任何負(fù)債，換購一套房產(chǎn)在財務(wù)的安排上沒有任何問題。
2.安排適當(dāng)保險：孩子出生以后家庭保障就顯得格外重要了，應(yīng)當(dāng)安排好充足的保障。具體來說，張平夫婦的壽險、大病和意外保險都需 要。孩子也需要安排一定的醫(yī)療保險。保險的支出額度應(yīng)當(dāng)安排在一個月左右的家庭收入為宜。主要應(yīng)當(dāng)安排家庭保障類的保險，儲蓄理財類的保險暫緩。
3.構(gòu)建基金組合：因為張平夫婦還很年輕，應(yīng)當(dāng)爭取在事業(yè)上更上層樓。所以在投資上應(yīng)當(dāng)盡量簡單。因此，我們建議張平夫婦的金融資產(chǎn) 除保留一部分存款外應(yīng)當(dāng)主要通過購買基金來安排，構(gòu)建一個基金組合，長期投資，讓專家來幫助理財，省心省力。目前的股市投資可暫時保留，但今后也應(yīng)當(dāng)擇機(jī) 退出，全部通過基金來投資。而且今后每月收入的結(jié)余也應(yīng)當(dāng)采用定期定量的方式投入到家庭的基金組合中。
——本刊首席理財師 徐建明
專家建議二：投資建議
對于張平先生的理財需要，我們提出以下幾點建議，希望能夠?qū)λ兴鶐椭?
1.對于孩子的“教育和婚嫁基金”
我們建議做個"傻瓜型"的計劃。那就是在與理財專家溝通后，做一個基金的“一籃子”方案，即將貨幣基金、債券基金、股票基金按1:2: 7的比例進(jìn)行定期定額的投資。由于張平夫婦年紀(jì)較輕，承擔(dān)風(fēng)險的能力較強(qiáng)，所以我們的建議中適當(dāng)增強(qiáng)了股票基金的投資比例。同時，我們也提醒張平先生要在 家庭情況發(fā)生巨大變化時，對投資比例進(jìn)行適時的調(diào)整。長期性定期的投入會更好地增加收益，控制風(fēng)險也無須花費(fèi)太多精力。
2.對于夫妻倆的購房需求
張平夫婦的購房是為了自住需要，因此我們建議可以每年投入一定比例的資金進(jìn)入保本增值市場，來進(jìn)行購房基金的積累。如保本基金、貨幣市場基金、記賬式國債、以及最新發(fā)行的儲蓄國債等。這樣既可保持其靈活性，又可以在5年之內(nèi)尋求適當(dāng)?shù)臅r機(jī)以按揭貸款形式購入新房。
至于未來是賣了現(xiàn)有房產(chǎn)換購新房，還是增大負(fù)債比例購置新房保留現(xiàn)有住房，則要看未來的家庭資產(chǎn)總量和月收入能力。若未來能力足夠，當(dāng) 然也可以保留現(xiàn)有老房子用于出租，用租金來緩解部分月供能力。若未來家庭積累的資金量不夠，則可以選擇出售后換購大房子，負(fù)債額度可以由當(dāng)時的月收入能力 來計算。
雖然理論上認(rèn)為月供額度只要不超過月收入的50%就是安全的了，但我們建議月供最好不要超過月收入的1/3，否則對一家三口的基本生活將會產(chǎn)生不小的壓力，甚至淪為“房奴”一族。
3.在張平先生的家庭情況中我們注意到，其本人是建筑企業(yè)的生產(chǎn)管理人員，建筑行業(yè)是一個受經(jīng)濟(jì)波動影響較大的行業(yè)。這對他家庭收入長 期的穩(wěn)定性有不利的因素存在。因為夫婦二人均只有28歲，所以我們建議張平夫婦現(xiàn)在每年也為自己準(zhǔn)備一筆“教育基金”。進(jìn)一步的“充充電”，學(xué)習(xí)一些新的 知識和技能來提高自己。在我們看來理財不僅僅是對金錢進(jìn)行投資規(guī)劃，也可以是對自身進(jìn)行投資規(guī)劃，而且或許收益回報會更高，也能更好、更快地實現(xiàn)家庭理財 計劃。
——建行上海市分行盧灣支行 馬鈞潔
專家建議三：保險建議
家庭所面臨的風(fēng)險不外乎人身損失風(fēng)險、財產(chǎn)損失風(fēng)險和責(zé)任損失風(fēng)險。從表面上來說張平一家的財務(wù)狀況基本穩(wěn)定，沒有什么債可“負(fù)”，但 是一旦碰到重疾或者意外等不確定因素的發(fā)生，不僅會嚴(yán)重影響家人的心理狀態(tài)，而且會對家庭的財務(wù)狀況造成不同程度的沖擊，所以絕對是可不言、但不可不理 的。況且，他們未來還打算購買大面積的房子，估計需要增加債務(wù)負(fù)擔(dān)。
風(fēng)險的分析應(yīng)該從兩個角度入手：損失發(fā)生的可能性和損失發(fā)生后的嚴(yán)重程度。正值盛年的張平夫婦的身故可能性很低，但是發(fā)生意外事故的風(fēng)險不容忽視，尤其是張平本人從事的是建筑企業(yè)的生產(chǎn)管理工作。萬一有一方發(fā)生不測，家庭收入就會減少一半以上。
解決這個問題的最佳途徑之一莫過于人身意外傷害保險，它的最大優(yōu)勢就是在引起損失的事故發(fā)生時提供一筆收入，從而可以彌補(bǔ)損失，緩解生者面臨的財務(wù)壓力。
將來購買新房有了負(fù)債之后，還應(yīng)該增加一定的壽險保障。
根據(jù)張平的需求，他想為自己和妻子購買養(yǎng)老和醫(yī)療方面的保障，以及為兒子選擇教育金之類的險種。但按照他的家庭收入能力，我們建議他暫緩夫妻倆人的養(yǎng)老保險計劃，等到十年以后，也就是37歲、38歲以后再考慮養(yǎng)老保障。
夫妻倆人的醫(yī)療保障，則應(yīng)該從現(xiàn)在開始做起，畢竟他們也是"奔三"的人了，雖然現(xiàn)在年富力強(qiáng)甚至沒有什么醫(yī)療費(fèi)用指出，但再過兩三年肯 定會明顯感覺到身體的亞健康狀態(tài)來臨。而且，隨著撫育幼兒所付出的超額體力和精力，張?zhí)纳眢w狀況可能面臨直線下滑的趨勢。為此，張平可以先為自己和太 太選擇一定的醫(yī)療補(bǔ)貼保險和大病保險。孩子方面，如果體質(zhì)較弱，夫妻雙方的單位又不能負(fù)擔(dān)任何醫(yī)療費(fèi)用，那么也可以為孩子選擇一份兒童醫(yī)療保險，向保險公 司轉(zhuǎn)移家庭的醫(yī)療負(fù)擔(dān)風(fēng)險。
——上海合泰保險超市 高逢潔
軟件項目開發(fā)過程模型
1.????
什么是軟件項目開發(fā)過程模型
項目開發(fā)過程模型就是對于項目開發(fā)過程的概念建模，從而能夠?qū)崿F(xiàn)在理論上對于軟件項目開發(fā)過程進(jìn)行量化分析。
?
軟件開發(fā)過程模型以
Rational Unified Process
（簡稱
RUP
）為代表，如下圖
圖
1
、
Rational
Unified Process
但是也并不是只有
RUP
一種，比如
Agile Unified Process (
簡稱
AUP)
圖
2
、
Agile Unified Process
?
總體來說，
RUP
是最細(xì)化的項目開發(fā)過程模型，不管你采用什么樣的開發(fā)方式，整個開發(fā)過程的每一個過程你都是無法逃掉的（我們后面會討論這個），因為這代表了整個軟件開發(fā)實踐的客觀規(guī)律，只是在定義上有所不同，側(cè)重點上有所不同，對于迭代的看法有所不同罷了。
2.????
為什么要關(guān)注軟件項目開發(fā)過程模型
如同它的概念所示，軟件項目開發(fā)過程就是對軟件項目開發(fā)過程的概念建模，從而能夠?qū)崿F(xiàn)在理論上對于軟件項目開發(fā)過程進(jìn)行量化分析。
?
那么，這種量化的分析到底有能有什么好處呢？
?
我們在引子里說過：任何的軟件項目都有它存在的目的，都是為了解決一些現(xiàn)實中的問題。可以把這個成為這個項目的目的，可以把需要解決的問題的需求稱作這個項目的需求。
?
而對于商用（尤其是企業(yè)級應(yīng)用）軟件項目開發(fā)而言，最基本也是最重要的目的就是以最小的成本，在項目交付的期限內(nèi)，提供穩(wěn)定的、可靠的軟件，用以解決用戶提交的所需要解決的問題，并且如有可能，必須為現(xiàn)實生活中問題的變更引起的用戶需要解決的問題的變更從而要求的軟件功能的變更做好準(zhǔn)備。
?
l????????
為了能夠把客戶的問題描述清楚，必須進(jìn)行業(yè)務(wù)建模和需求收集；
l????????
為了能夠把收集完的問題需求轉(zhuǎn)變成為可以信息化解決的問題并且解決，必須對其進(jìn)行軟件化設(shè)計并進(jìn)行實現(xiàn)；
l????????
為了保證軟件產(chǎn)品的質(zhì)量，必須進(jìn)行足夠多的測試（看看硬件廠商是怎么測試的？）；
l????????
為了能夠讓軟件產(chǎn)品正常運(yùn)轉(zhuǎn)，必須進(jìn)行軟件的部署；
l????????
而在軟件開發(fā)的過程當(dāng)中，對于項目的管理、代碼的管理、還有資源的管理，在哪一個軟件項目開發(fā)中能缺少？
?
綜上，對這些過程的建模和定量的分析，并且確定在整個開發(fā)過程中各個階段所占的份額和所擁有的重要性，對于保證項目（尤其是大項目）的平穩(wěn)開發(fā)和增強(qiáng)項目開發(fā)管理有著重要的作用。
?
并且，確定了項目開發(fā)過程模型，對于確定項目管理方式和提供技術(shù)、工具支持有著非常重要的作用。
3.????
接下來要討論的
既然我們已經(jīng)有了一個明確的定義，并且能夠把它分解成為幾個部分（當(dāng)然，我們將會看到，這些部分本身也是十分復(fù)雜的）。那么，看上去下一步，我們的任務(wù)就是一步一步的分析每一個部分。
?
但是，且慢，這些部分有些是沒法討論的（比如業(yè)務(wù)建模，它與用戶的域?qū)＜矣嘘P(guān)，或者跟一些國家、國際標(biāo)準(zhǔn)有關(guān)，跟計算機(jī)軟件開發(fā)沒太多的關(guān)系——除非是
IDE
之類的），有些是仁者見仁、智者見智的部分（比如設(shè)計和實現(xiàn)），有一些可以不必花太多口舌去討論（比如軟件項目的部署和資源管理），這一點
AUP
給我們開了個好頭，我們現(xiàn)在需要討論的就是：
l????????
需求分析
l????????
測試
l????????
配置管理
l????????
項目管理
?
但就是這么幾個，就足夠我們討論的。事實上，如果能夠?qū)@些問題都全面的分析并且提出自己的見解和解決方案的話，分量足夠一個博士論文（起碼重量上差不多），也許那樣我可以出本書，呵呵，玩笑。
?
我只能盡力的往下分析，但是，我更希望的是大家能夠有所反饋。因為，在軟件設(shè)計中很多問題都是隱藏的（像地雷一樣），直到你踩上它為止，你都不會發(fā)現(xiàn)它。
?
我很希望能夠有反饋使我避免低級的錯誤。
“
是我們創(chuàng)造了工具，并且使用它們，而不是相反”
任何的軟件項目都有它存在的目的，都是為了解決一些現(xiàn)實中的問題。可以把這個成為這個項目的目的，可以把需要解決的問題的需求稱作這個項目的需求。任何的軟件項目的開發(fā)都必然離不開了解需求、根據(jù)需求進(jìn)行設(shè)計、根據(jù)設(shè)計進(jìn)行實現(xiàn)這些過程。不管是多大的項目，也不管是采用何種開發(fā)方式。
?但是，設(shè)計的方式卻有多種，沒有誰會規(guī)定，只有采用UML圖進(jìn)行建模才叫設(shè)計。也沒有誰規(guī)定，只有“設(shè)計”好了的項目才能開始代碼實現(xiàn)。
對于軟件項目開發(fā)而言，大型的項目和小型的項目所面臨的項目開發(fā)的問題是不同的。
一個人幾天就可以完成的項目和幾個小組好幾個月才能完成的項目相比，它們面臨的實際中的開發(fā)問題，和開發(fā)結(jié)束后面臨的維護(hù)問題都是不可同日而語的。
而且，技術(shù)的角度上看，適合大的項目的開發(fā)方式也未必一定適合小的項目。
好了，說了這么多，我只是想說：
綜上所述，軟件開發(fā)過程是一個非常復(fù)雜的問題，對于做技術(shù)的人來說（尤其是做計算機(jī)軟件技術(shù)的人），解決問題的方式只有一種，分析問題、根據(jù)問題設(shè)計解決方案、然后實現(xiàn)解決方案來解決問題（解決方案未必一定是軟件）。
分析問題的第一步，就是把現(xiàn)實中的東西轉(zhuǎn)換成為概念模型，這樣我們才有一個討論和研究的平臺。如果沒有一個明確的統(tǒng)一的概念模型，那么，無論做什么研究都會顯得毫無意義（古代的智者和詭辯論者經(jīng)常這么干）。
既然我們面臨的問題是軟件項目開發(fā)，那么我們第一個要做的就是把它建模，并且對它進(jìn)行一下研究。
我會在接下來幾篇文章中對它進(jìn)行詳細(xì)的闡述，并且針對我在項目開發(fā)中的一些經(jīng)驗、總結(jié)和思考提出我對這個問題設(shè)計的解決方案。
目的只有一個，希望針對這個問題作出一些探討。希望能夠拋磚引玉。
當(dāng)前問題：
流程－
ERP
軟件的死穴？
時間：
2004-03-12
提問者：
quicker??
地址（需要注冊）：
http://www.ceconline.com/DG/NOTE_900001_900002_793863.HTM?dmsource=CECOL_060419_EETCOL
這些年，接觸了不少
ERP
軟件，聽了不少關(guān)于
ERP
軟件的推廣說明會，自己也嘗試了好幾種軟件模塊的實際運(yùn)用，但效果一直不如人意，專家對此也評論不同。說什么的都有，但幾乎沒人點出
ERP
的死穴。
有幾個問題我們必須首先理清。
一、任何一種
ERP
軟件都有其適用范圍，至少到目前為止，還沒有一個軟件可以成為放之四海而皆準(zhǔn)的通用軟件。即使，某些聲稱自己是通用軟件的公司也不行。
二、任何一種
ERP
軟件都是建立在一種管理思想或者管理結(jié)構(gòu)上的。我們知道，管理本無定法，也沒有優(yōu)劣之分，主要看其是否能夠解決問題。軟件不過是這些思想的一種體現(xiàn)形式，同樣也擺脫不了這個約束。
三、實施
ERP
不是目的，
ERP
只是一個系統(tǒng)工具。這幾乎已成共識。我們試圖用一個系統(tǒng)思考的辦法來解決企業(yè)各部門之間的協(xié)調(diào)與資源共享，以達(dá)到企業(yè)整體經(jīng)營績效的目的。
四、多數(shù)情況下，
ERP
都有個在實際運(yùn)用中進(jìn)行二次開發(fā)的問題。如果說，實際
ERP
表現(xiàn)有好、壞之分的話，主要還是看軟件公司二次開發(fā)的能力。
但是，以上這四點觀念，都無法回避一個事實：現(xiàn)在的
ERP
是建立在流程基礎(chǔ)之上的。因為，有
“
業(yè)務(wù)流程重組
”
做理論指導(dǎo)，這方面還有
6
西格瑪做旁證。
而我的觀點是，建立在流程基礎(chǔ)上的
ERP
軟件會被流程所困住，流程思路便成了
ERP
的死穴。如果我要界定一下我說的論點的適用范圍的話，那么，我
要說，對中國，對民營企業(yè)，
ERP
還很遙遠(yuǎn)。因為，我無法窮舉，所以，為防止招來批評，我不得不界定成上述的一個相對狹窄的范圍。
為什么？這是中國的客觀現(xiàn)實所然。
今天的中國市場變化太大了，昨天的英雄，今天可能就成為了失敗者。中國的企業(yè)外部環(huán)境是多變的。在這種情況下，一個企業(yè)想要經(jīng)營良好，沒有多變的
機(jī)制或者更準(zhǔn)確說，具備靈活的應(yīng)對機(jī)制，恐怕是很難持久的。進(jìn)一步講，由于企業(yè)經(jīng)營機(jī)制多變，那就要求企業(yè)具備動態(tài)調(diào)整的能力，這種能力從企業(yè)實際來講，
就是：組織結(jié)構(gòu)多變、權(quán)責(zé)多變（也是權(quán)責(zé)不清的一個原因）、人員多變、流程多變等等。
有人講：唯一不變的真理就是變化。
那么，作為
ERP
軟件開發(fā)的公司來講，是不希望你變來變?nèi)サ模皇擒浖O(shè)計師在模塊規(guī)劃時很難協(xié)調(diào)，二是二次開發(fā)可能因為多變而成了多次開發(fā)，軟
件公司也受不了。有的軟件公司為逃避這種責(zé)任，干脆把源代碼交給企業(yè)，由企業(yè)去自行修訂。可是，有多少企業(yè)有這樣的強(qiáng)大開發(fā)能力呢？
其實，問題既不在于企業(yè)多變，也不在于軟件公司不負(fù)責(zé)任，而是建立在流程基礎(chǔ)上的框架是個死穴。
包括四川維尼綸公司在內(nèi)一些早期應(yīng)用過
ERP
的企業(yè)曾經(jīng)談過：
“
。。。我們不得不加班登錄數(shù)據(jù)，否則第二天其它部門上班便沒法運(yùn)作。。。
”
這就是
一個很典型的情況。由于流程的限制，上、下部門之間的數(shù)據(jù)庫是被流程捆綁起來的，所以，流程要求這樣，你不得不先行一步。但是，我們似乎應(yīng)該思考一下，我
們真的應(yīng)該這樣嗎？
我們不妨換個角度看看。如果，我們不把流程作為數(shù)據(jù)庫鏈接的基礎(chǔ)，而是把流程所產(chǎn)生的結(jié)果作為基礎(chǔ)，那會是一種什么樣的情況呢？
關(guān)注結(jié)果而不是關(guān)注流程，那么無論流程如何多變，均沒有什么可以擔(dān)憂的。
只要結(jié)果能夠反應(yīng)企業(yè)的整體經(jīng)營需要，隨著市場環(huán)境的變化，企業(yè)可以動態(tài)調(diào)整自己的組織結(jié)構(gòu)、調(diào)整自己的運(yùn)作流程。需要說明的是人員的調(diào)整也同樣不會產(chǎn)生大的影響，而現(xiàn)在的關(guān)注流程的方式，倒要受到這方面的影響，使得企業(yè)不得不再行投入成本進(jìn)行培訓(xùn)。
只有三種情況是例外：企業(yè)流程本身比較穩(wěn)定或變革后流程重新穩(wěn)定的能力很強(qiáng)；軟件公司的后續(xù)開發(fā)能力很強(qiáng)（往往有管理顧問做后盾）；企業(yè)自身的軟件開發(fā)調(diào)整能力超強(qiáng)。
否則，應(yīng)用
ERP
，真應(yīng)該小心啦。
你們說呢？
評注： 作者提出了ERP對業(yè)務(wù)處理流程提出了要求，也對ERP依賴于業(yè)務(wù)流程的程度提出了質(zhì)疑。本身觀點是比較清晰的。但是，我個人覺得，拋開業(yè)務(wù)流程的處理而只關(guān)注業(yè)務(wù)處理的結(jié)果的話，只會降低ERP系統(tǒng)的價值，失去ERP系統(tǒng)對企業(yè)內(nèi)部資源的統(tǒng)一調(diào)配能力和協(xié)調(diào)能力。所需要關(guān)注的應(yīng)該是怎樣提高業(yè)務(wù)流程的靈活性和可定義性，在深層次上解決當(dāng)前企業(yè)內(nèi)部流程不確定的問題，沒有一家成熟的企業(yè)規(guī)則朝令夕改，雖然目前來看，中國的國情（最好的不一定是正確的，正確的不一定是掙錢的）決定了一個企業(yè)要想生存，必須能夠靈活的進(jìn)行適應(yīng)，但是這并不一定代表著確立業(yè)務(wù)處理流程沒有必要，確立公司內(nèi)部業(yè)務(wù)處理規(guī)則沒有必要，在
解決當(dāng)前企業(yè)內(nèi)部流程不確定的問題上，ERP的開發(fā)企業(yè)必須要達(dá)到技術(shù)上提高業(yè)務(wù)處理流程的靈活性和可定制性，降低修改帶來的時間和經(jīng)濟(jì)成本，還要結(jié)合自身的開發(fā)經(jīng)驗，向客戶推薦當(dāng)前業(yè)內(nèi)先進(jìn)的管理思想和管理方式，在另一個方面上提升用戶的價值。
這方面，大家有什么想法？
??? 在這里只是簡單的介紹一些企業(yè)應(yīng)用開發(fā)應(yīng)該采納和借鑒的一些展現(xiàn)層技術(shù)、架構(gòu)和開發(fā)方式，之所以稱它們?yōu)樾拢饕轻槍夹g(shù)和趨勢而言，其實他們的概念已經(jīng)不算是太新的了（已經(jīng)存在一段時間了），正是因為如此，它們更加具有可借鑒的價值。
???
瀏覽器胖客戶端技術(shù)：
??? 無論如何說、無論采用何種技術(shù)目前的三層分布式企業(yè)級應(yīng)用也都是網(wǎng)絡(luò)應(yīng)用，它在本質(zhì)上與其他的網(wǎng)絡(luò)應(yīng)用是有相似性的，我們可以在它們之間作一個類比。
???
就在不遠(yuǎn)的以前，網(wǎng)站的用戶界面也是靜態(tài)的，雖然很多網(wǎng)站提供了服務(wù)端動態(tài)網(wǎng)頁的支持，但是用戶看到的卻還是一張張靜態(tài)的網(wǎng)頁。用戶與網(wǎng)站之間是一個請求
和交互的過程（本質(zhì)上就是這樣，看上去也是這樣），用戶通過超鏈接在一個個動態(tài)/靜態(tài)的頁面之間瀏覽。而所有的處理全部是由服務(wù)器來進(jìn)行的。大多數(shù)能夠即
時響應(yīng)客戶的是Flash或者Applet這種瀏覽器的插件。當(dāng)然客戶端動態(tài)網(wǎng)頁的技術(shù)當(dāng)時也已經(jīng)存在很長時間了，但是并沒有得到太多的重視。
???
但是，近幾年來，動態(tài)網(wǎng)頁無刷新技術(shù)逐漸興起起來，它充分利用了客戶端瀏覽器所具備的計算能力，通過借助于DHTML容器的事件機(jī)制和非提交形式HTTP
訪問服務(wù)器的方法實現(xiàn)了可以在客戶端自行處理用戶請求的基于瀏覽器的胖客戶端，使得使用界面更加友好和易用，而且還在相當(dāng)?shù)某潭壬蠝p輕了服務(wù)器處理的負(fù)
擔(dān)。
???
???
再拿二層的分布式企業(yè)級應(yīng)用來作縱向比較，雖然抽象出應(yīng)用服務(wù)器這一層對于數(shù)據(jù)庫服務(wù)器是一種解脫（也為SOA打下了基礎(chǔ)），但是由于當(dāng)時的網(wǎng)絡(luò)應(yīng)用的技
術(shù)所限，真正的用戶體驗是下降了的，胖客戶端的安裝和升級確實比較麻煩，但是一般說來客戶端的安裝問題只是部署和維護(hù)企業(yè)級應(yīng)用系統(tǒng)的一個很小的問題。但
對于底層的實際用戶而言，基于網(wǎng)絡(luò)HTML技術(shù)的客戶端界面可能會好看一些，但是效率、操作性、實時反應(yīng)的能力都是下降了的。對于底層的用戶而言，鍵盤操
作要比鼠標(biāo)操作工作效率更高。企業(yè)級應(yīng)用的系統(tǒng)是要給企業(yè)做的，而企業(yè)的主要目標(biāo)是創(chuàng)造最大利潤，在這一點上其實很多三層的企業(yè)級應(yīng)用都是對企業(yè)級應(yīng)用所
要達(dá)成的目標(biāo)的一種背離。但是，這主要是因為當(dāng)時的技術(shù)所限，就算是最能代表當(dāng)時網(wǎng)絡(luò)技術(shù)的大型商業(yè)網(wǎng)站，他們的用戶界面也幾乎全是靜態(tài)的HTML網(wǎng)頁。
???
???
綜上所述，可以看出三層分布式的企業(yè)級應(yīng)用系統(tǒng)應(yīng)該在展現(xiàn)層進(jìn)行一次革新，應(yīng)該盡可能的采用瀏覽器胖客戶端的技術(shù)，這樣一方面可以充分利用客戶端的計算能
力和資源，緩解服務(wù)端壓力，還可以通過快捷鍵、自定義快捷方式甚至自定義宏的方式提高用戶的使用效率和使用體驗。
???
服務(wù)端組件化開發(fā)技術(shù)：
??? Struts
是一個很好的框架，它的靈活性和穩(wěn)定性是有目共睹的。但是無論如何它給開發(fā)人員帶來的工作量和調(diào)試起來的難度也是很多的（尤其是在沒有充分體現(xiàn)出分層概念
的企業(yè)級應(yīng)用系統(tǒng)中）。其實難度最終是要轉(zhuǎn)化到網(wǎng)絡(luò)應(yīng)用的開發(fā)上去的。三層的企業(yè)級應(yīng)用系統(tǒng)也是網(wǎng)絡(luò)應(yīng)用，而對于網(wǎng)絡(luò)應(yīng)用而言，業(yè)務(wù)開發(fā)人員和美工（又叫
WebUI？）人員的分工也是比較頭疼的問題。JSP等模板技術(shù)于是應(yīng)運(yùn)而生，但其實這不過是一種善意的謊言。對于JSP而言業(yè)務(wù)開發(fā)人員還是必須對
HTML有比較深的了解，而且最頭疼的是，除非你把它放在Web容器中運(yùn)行，否則你決不會知道它到底是一個什么樣子（除非你把你自己的大腦變成一個Web
容器加上一個瀏覽器），JSP Tag的出現(xiàn)并不能解決什么問題，從本質(zhì)上來說它就是JSP概念的一個延展，可以節(jié)省代碼而已（而且?guī)砀嗟膹?fù)雜度）。
??? 難道真的沒有辦法了嗎？
??? 我們縱向?qū)Ρ纫幌露拥钠髽I(yè)級應(yīng)用，它開發(fā)和維護(hù)起來就沒有三層那么麻煩。原因何在？組件已經(jīng)封裝了絕大多部分的工作，你所需要的只是應(yīng)用組件、配置組件、添加事件處理代碼而已。
???
從這個方面上來說，還有什么DHTML更好的用戶界面描述語言？設(shè)想一下，你可以試圖拿Swing（為什么Swing？——平臺無關(guān)）寫一個可以在運(yùn)行時
動態(tài)的改變界面結(jié)構(gòu)、通過樣式描述文件動態(tài)改變組件樣式的程序（這一切可以跟一個或多個很完善的腳本語言無縫集成），它會多復(fù)雜？
??? 還記得桌面應(yīng)用的開發(fā)嗎？沒有一個像樣的桌面程序沒有自定義組件的，但是它們的自定義組件大多數(shù)其實只是基礎(chǔ)組件的組合。
??? 同理，也可以對HTML進(jìn)行如此開發(fā)。
??? 下面給出解決的架構(gòu)。
???
展現(xiàn)層開發(fā)架構(gòu)：
???? 開發(fā)要明確體現(xiàn)出客戶端、應(yīng)用服務(wù)器端、數(shù)據(jù)庫服務(wù)器端的三層概念。數(shù)據(jù)庫服務(wù)端的開發(fā)與展現(xiàn)層無關(guān)略去不講。
- 客戶端開發(fā)：使用JavaScript進(jìn)行事件處理響應(yīng)用戶的操作，對組件進(jìn)行相應(yīng)的操作，如有必要可以采取遠(yuǎn)程服務(wù)器端服務(wù)調(diào)用（既可以調(diào)用自己服務(wù)器提供的服務(wù)也可以調(diào)用其他的公用網(wǎng)絡(luò)服務(wù)，符合SOA的要求）的方式。
- 服
務(wù)端開發(fā)：展現(xiàn)層組件分為兩部分，動態(tài)網(wǎng)頁組件和JavaScript組件。動態(tài)網(wǎng)頁組件采用基于組件化的動態(tài)網(wǎng)頁框架（比如Tapesrty，為什么不
用JSF稍后再講）。另外服務(wù)端開發(fā)還有業(yè)務(wù)邏輯處理服務(wù)，其中業(yè)務(wù)邏輯處理屬于業(yè)務(wù)邏輯層不再多說，而業(yè)務(wù)邏輯處理服務(wù)和服務(wù)的遠(yuǎn)程調(diào)用以及相應(yīng)的安全
處理可以采用Spring + Acegi +
DWR的方式（這樣可以既可以實現(xiàn)JavaScript客戶端遠(yuǎn)程調(diào)用業(yè)務(wù)邏輯服務(wù)，還可以很容易的實現(xiàn)服務(wù)的安全公開化，符合SOA的要求）。
??? 為什么這么看重Tapestry而不用JSF呢？
- JSF
的標(biāo)準(zhǔn)還是跟JSP綁在一塊的，雖然有Facelet的存在，但是本身擺脫不了JSP的JSF還是會被JSP所拖累的。我并沒有說JSP一無是處，作為模
板技術(shù)而言，JSP已經(jīng)非常成功了，但是對于JavaScript胖客戶端開發(fā)而言，JSP本身容器相關(guān)的特性實在是沒什么好處。
- 目前
而言JavaScript是可以進(jìn)行單元測試的，而Tapestry的Html模板技術(shù)使得JavaScript和Html的集成測試達(dá)到可能。你可以完
全不管Tapestry而調(diào)試JavaScript，調(diào)試成功以后再加上Tapestry的組件標(biāo)簽就可以了。你可以為重要的JavaScript（一些
起粘結(jié)作用的Script就沒有必要測試了）寫測試腳本進(jìn)行測試，而這些全部都是遠(yuǎn)離Web容器的。
???
??? 我們的開發(fā)人員為什么要遠(yuǎn)離JavaScript呢？因為它是動態(tài)解釋語言？Ruby也是。只要測試到位，動態(tài)語言也可以實現(xiàn)穩(wěn)定的系統(tǒng)。
??? 運(yùn)行的效率低？也許吧，但總高過整個頁面刷新，我說的不過分吧。
???
開發(fā)人員對JavaScript認(rèn)識不夠，沒有很好的IDE支持？事實上，根本不必讓開發(fā)人員對它認(rèn)識“夠”，因為他所寫的主要是一些GlueCode，
配置一下組件，把組件之間通過事件結(jié)合起來。當(dāng)然，這些有一部分你可以自己發(fā)明一些XML來達(dá)到，值得嗎？我個人認(rèn)為寫動態(tài)腳本也好過寫XML（別跟我說
你還可以寫個DTD）。至于IDE的話，我認(rèn)為，寫JavaScript根本用不著，尤其是在你根本不會寫很多的時候。只要有一個瀏覽器和瀏覽器支持的
JavaScript調(diào)試器足夠了。只要組件化做好了，再結(jié)合工程模板，那么開發(fā)人員就象回到了二層的時代，選擇相應(yīng)的組件，組合然后就是調(diào)試了。比兩層
有優(yōu)勢的一點是，他不必啟動服務(wù)器就可以調(diào)試客戶端。
???
這一方面的網(wǎng)絡(luò)應(yīng)用開發(fā)先驅(qū)是Google（可惜，他們沒用JavaEE技術(shù)，呵呵），到現(xiàn)在已經(jīng)成為一種風(fēng)潮，對企業(yè)級應(yīng)用開發(fā)趕時髦是沒有必要的，但
是技術(shù)的發(fā)展帶來了新的可能，不管是在開發(fā)方面還是在客戶體驗和客戶效率提高上都會有更好的機(jī)會，為什么不把握這個機(jī)會呢？
??? 末了，SOA完全可以評為今年的軟件開發(fā)最流行關(guān)鍵詞。呵呵。它的核心概念是什么呢？不要浪費(fèi)現(xiàn)有的IT資源。
??? 我們現(xiàn)在對于網(wǎng)絡(luò)和計算機(jī)技術(shù)的資源開發(fā)和應(yīng)用的大部分都處于浪費(fèi)狀態(tài)，有政治原因、有商業(yè)原因但是還有技術(shù)原因。能夠盡可能有效的利用手中現(xiàn)有的資源，對于企業(yè)的發(fā)展也有相當(dāng)?shù)姆e極作用。
地址：http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
評論：
??? 很久沒有看到這么好玩的東西了。開始還是討論，但是由于
Gavin King的壞脾氣，最后直接變成了批斗大會了。哈哈。
??? 其實Hibernate怎么能夠封殺得掉Spring呢？他們只能自己生氣罷了。
??? 我倒不是太討厭EJB3，可是還要涉及到JDK5.0的技術(shù)，對以前的東西的兼容性也不能保證。目前來看，也不見得就比Spring強(qiáng)。
??? 我對他們倒是沒有偏見，但是我還是選擇用Spring。
AOP是一個什么概念呢？
AOP是Aspect Oriented Programming的縮寫，翻譯成中文就是面向方面編程。它是最近幾年流行起來的另一種編程方式。
- 首先，AOP只是OOP的補(bǔ)充，換句話說，Procedure Oriented Programming的工程是很難，也是幾乎不可能使用AOP的。
- 其次，AOP是對OOP系統(tǒng)的縱向切割，從另一個方面上實現(xiàn)了系統(tǒng)解耦
- 再次，AOP給OOP提供了另一種重用的可能。
對于OOP系統(tǒng)而言，系統(tǒng)的解耦主要依賴分層和良好的設(shè)計，一般良好的OOP架構(gòu)沒有不采用分層和設(shè)計模式的（當(dāng)然，分層分得恰當(dāng)不恰當(dāng)、模式用得好不好，跟框架的設(shè)計者有著直接的關(guān)系）。但是，對于OOP系統(tǒng)而言，它只能到達(dá)這一步了。
對于系統(tǒng)的必須要求，比如日志、錯誤跟蹤、訪問攔截、權(quán)限控制等操作，OOP就很難達(dá)到八面玲瓏。
其實，倒不是OOP一定不能實現(xiàn)上述功能的分離和重用，但是由于那又需要更高層次的抽象和封裝，憑空增加系統(tǒng)的復(fù)雜性和使用難度，又不利于版本控制和發(fā)布控制，一般來說，是得不償失的。
所以，很多開源項目比如Commons Logging等應(yīng)運(yùn)而生，它們的存在從一定的意義上解決了這個問題。
但是，還有一種很好的解決方案，那就是AOP（實際上AOP就是為了解決這種問題而誕生的）。
AOP既然是OOP系統(tǒng)的縱向切割，那么它就應(yīng)該具備以下幾點：
- 切入點（Point Cut）：它需要一個點來切入到OOP系統(tǒng)中去，目前流行的AOP框架都采用從方法切入的方式。
- 切面（Advice）：切入之后，它要做些什么呢？必須可以有一種方式進(jìn)行定制，目前流行的AOP框架都采用Java代碼實現(xiàn)的方式
- 重用性：一般來說，AOP能帶來的重用一般都是Advice描述文件的重用，目前所有的AOP的Advice都是Java的Class文件，這就提供了一種可能，所有的Advice都可以通過打包成Jar的形式實現(xiàn)重用。
由此可以看出，使用AOP能夠帶來的好處是提供了一種抽象模型的方式、一種重用以前工作的方式（在不更改過去的代碼的基礎(chǔ)上添加新的功能、同時也可以重用過去寫的Advice）。
AOP還有一個好處，就是減少工作量。
因為目前流行的AOP框架的PointCut定義一般都支持通配，這樣就可以實現(xiàn)批量定義和修改。如果代碼有著良好的規(guī)范、在良好的設(shè)計下，開發(fā)和維護(hù)工作量的減少會非常可觀。而且對于添加新的功能不必修改原有的架構(gòu)設(shè)計，從另一方面也降低了非常可觀的工作量。
那么AOP在JavaEE企業(yè)級應(yīng)用中能夠起什么作用呢？
- 事務(wù)控制：很多業(yè)務(wù)邏輯方法都需要事務(wù)控制，通過通配實現(xiàn)事務(wù)控制絕對是一個節(jié)省工作量的好辦法，如果再結(jié)合IOC更加可以脫離事務(wù)控制的依賴，實現(xiàn)事務(wù)控制靈活更換，提高了業(yè)務(wù)系統(tǒng)的重用性
- 權(quán)限控制：權(quán)限控制到底算不算業(yè)務(wù)邏輯？如果不算，為什么還要體現(xiàn)在業(yè)務(wù)邏輯中？通過AOP的方式，可以靈活的實現(xiàn)FilterChain機(jī)制，而業(yè)務(wù)邏輯的代碼可以對其毫無察覺。
- 持久層對象的裝飾和過濾：可以根據(jù)需要對持久層操作返回的結(jié)果進(jìn)行裝飾和過濾，甚至替換，而對系統(tǒng)架構(gòu)沒有任何要求。這是最漂亮和最干凈的做法。
- 系統(tǒng)級別診斷日志：實現(xiàn)可插拔式系統(tǒng)級別日志，這樣在系統(tǒng)正常運(yùn)行后就可以為了提高系統(tǒng)性能而不費(fèi)事的去掉它卻不會影響到系統(tǒng)的穩(wěn)定。
- 業(yè)務(wù)級別高級抽象：比如可以把工作流支持API封裝，通過AOP的機(jī)制實現(xiàn)Mixin，這樣就可以實現(xiàn)工作流支持和原業(yè)務(wù)邏輯分離，可以分開進(jìn)行管理，也可以在更高的抽象級別上實現(xiàn)重用。
AOP也不是沒有缺點，它本身就有一定的學(xué)習(xí)曲線，而且目前為止有具體意愿的好的實踐并不多，而且它也會給你的工程帶來復(fù)雜性，它還會給你的代碼增加理解的難度（不管你承認(rèn)不承認(rèn)，代碼閱讀的難度確實是跟代碼的耦合程度反相關(guān)的——雖然這是設(shè)計模式所力圖解決的問題）
但是，目前來看適當(dāng)?shù)氖褂肁OP，給你的項目提高靈活性和可維護(hù)性，是值得的。
什么是容器？
JavaEE原話：“
Containers are the interface between a
component and the low-level platform-specific functionality that
supports the component. ”
翻譯過來就是“容器就是底層的、與支撐平臺相關(guān)的、對組件進(jìn)行功能化支持的接口”。
難以理解？
通俗的解釋就是，容器是一系列為了實現(xiàn)分層的概念而定義的一系列功能的平臺無關(guān)的標(biāo)準(zhǔn)。它的主要用處就是平臺無關(guān)性和底層操作封裝性（Java的核心哲學(xué)）。
說白了，容器就是
Java的核心哲學(xué)在企業(yè)級應(yīng)用范圍內(nèi)的具體實現(xiàn)。
那么使用容器，能給我們帶來多大的好處呢？
- 強(qiáng)制性分層：通過Java的接口定義機(jī)制和強(qiáng)類型編譯器的支持，在底層就實現(xiàn)了分層的概念。即使頂層的實現(xiàn)十分沒有經(jīng)驗，底層的分層還是可以辨認(rèn)的。
- 底層操作封裝：以服務(wù)端應(yīng)用服務(wù)器為中心的三層企業(yè)開發(fā)涉及到的技術(shù)相當(dāng)麻煩和復(fù)雜，但是之間又有相當(dāng)多的共性，所以進(jìn)行有效的底層次的封裝是可行的而且是有必要的。這樣開發(fā)人員的工作就可以建立在一個穩(wěn)固的基礎(chǔ)上，而不是靠自己的經(jīng)驗去應(yīng)對這些問題。
- 平臺無關(guān)性：這個也是Java的核心哲學(xué)，至于好處嗎，我就不多說了
- 代碼的重用可能性提高：記住，是可能性。具體的重用性要看開發(fā)的方式和開發(fā)后代碼的質(zhì)量。
就JavaEE而言，它的標(biāo)準(zhǔn)里面只有WEB容器和EJB容器，這兩個容器已經(jīng)充分體現(xiàn)了它們的概念。
但是，還有一種概念上的容器，它的概念與上述概念不同，所以被稱作輕量級容器。
首先，輕量級容器不是接口的抽象，沒有JavaEE概念中的部署和移除，從概念上說輕量級容器就是一個擁有IOC支持的Bean工廠。
從形象的角度上來看，輕量級容器是一個盒子，盒子里面裝滿了貼有標(biāo)簽的JavaBean，對外界而言，它是一個魔盒，只要給它一個咒語（咒語必須正確），它就能給你一個禮物。
輕量級容器目前而言沒，有相應(yīng)的標(biāo)準(zhǔn)，但是它的使用范圍卻比真正的JavaEE標(biāo)準(zhǔn)要寬泛得多（誰不喜歡禮物呢？）。
- 首先，它是一個非常好的JavaBean工廠（誰沒用過工廠模式？）
- 其次，它能夠給你的代碼帶來IOC支持（懶人最喜歡的生活方式莫過于東西自己來找它）
- 再次，一般來說，輕量級容器都可以通過動態(tài)代理和字節(jié)碼增強(qiáng)的方式提供AOP的支持
總而言之，輕量級容器是JavaEE容器概念的一種有力補(bǔ)充，它的用法更加靈活，適用的范圍更廣，從目前的經(jīng)驗上看，開發(fā)、測試和管理起來也要比標(biāo)準(zhǔn)容器對象開發(fā)起來簡單。
-
輕量級容器一般不會給你提供分布式和集群的支持，因為它的優(yōu)點就是靈活而不笨重。
-
輕量級容器就像作漢堡的那兩塊面包，你想吃什么就往里夾，但是漢堡好吃不好吃，主要就在你放進(jìn)去的東西和搭配的手藝。
-
輕量級容器不能強(qiáng)制的要求你分層
- 輕量級容器的底層封裝一般以模塊加載進(jìn)容器的方式實現(xiàn)。
-
有的人不愛吃漢堡。
總體評價：
容器是Java的核心哲學(xué)的體現(xiàn)，而輕量級容器則是工程師開發(fā)文化的體現(xiàn)，它可以很靈活的幫助你，對你沒有什么具體的要求。二者不會出現(xiàn)誰替代誰的情況。具體的使用方式，還得看你在設(shè)計時所處的情況。
更正一下：
就JavaEE而言，它的標(biāo)準(zhǔn)里面只有WEB容器和EJB容器是對它的服務(wù)端而言的。客戶端還有Application Container和Applet Container兩個容器。
除了關(guān)系型數(shù)據(jù)庫（企業(yè)級應(yīng)用主要的數(shù)據(jù)持久工具）之外，企業(yè)級應(yīng)用還需要其他的方式進(jìn)行持久層操作。比如，數(shù)據(jù)保存在文件中、數(shù)據(jù)來自或者流向遠(yuǎn)程的其
他服務(wù)等。這樣持久層的操作就會有3——5種之多（還分有事務(wù)管理支持的和沒有事物管理支持的）。
怎么對這么多的操作進(jìn)行有效的管理，怎么才能使持久層的變更只
限定在持久層的范圍內(nèi)，怎么才能實現(xiàn)業(yè)務(wù)邏輯開發(fā)人員在開發(fā)上不必具有很多的持久層框架經(jīng)驗（注1），還有就是怎樣實現(xiàn)既可以利用強(qiáng)制和工具輔助的方式使一個新人能夠開發(fā)出跟掌握持
久層開發(fā)的精髓的核心開發(fā)人員同樣質(zhì)量的代碼（注2）又可以讓老手開發(fā)起來非常快捷（熟練工種），更重要的是在業(yè)務(wù)邏
輯方面物質(zhì)化、代碼化積累公司的業(yè)界開發(fā)經(jīng)驗，這就是我們下面要討論的問題。
我認(rèn)為，要想實現(xiàn)持久層的修改（注3）與業(yè)務(wù)邏輯層分離。還要最大可能的把公用的東西抽象出來，最大可能的為培養(yǎng)業(yè)務(wù)專精人員提供基礎(chǔ)，就必須
要有一個機(jī)制，實現(xiàn)把持久層的任務(wù)交給持久層去作。
這是什么意思呢？
就是在系統(tǒng)基礎(chǔ)架構(gòu)上，實現(xiàn)業(yè)務(wù)邏輯層和持久層的明顯松耦合（業(yè)務(wù)邏輯層根本不必知道持久層到底是什么介質(zhì)和實現(xiàn)方式）。
但是作為業(yè)務(wù)邏輯層的對象，數(shù)據(jù)的持久化操作是它所不能避免的東西，也就是說，它不可避免的會和持久層打交道。
那么怎樣在代碼的級別實現(xiàn)和持久層打交道還不跟持久層相關(guān)呢？
這就是要在下面給出的總體設(shè)計。在這里簡單的介紹一下用到了三個技巧，一個是
IOC，一個是
Command模式，還有一個就是CallBack的概念。
IOC就是著名的好萊塢模式——你不用來找我，我會自己去找你的，而CallBack通俗一點說就是“你要做什么，你告訴我，到時候我會通知你，并把你想要的東西帶來的”。
業(yè)務(wù)邏輯對象不可避免的要對持久層進(jìn)行操作，但是它對持久層的操作本身可以抽象成為一個Command對象，由注入到業(yè)務(wù)邏輯對象中的DAO來負(fù)責(zé)操作。說通俗點兒就是
說，對業(yè)務(wù)邏輯對象（BO）而言它是把一個任務(wù)說明書（CommandCallBack）給了一個它自己都不知道是從哪里來的叫做DAO的家伙（IOC），然后跟他說：
“你拿著它，按它的指示去把這事兒給辦了吧。”；業(yè)務(wù)邏輯對象知道“這事兒”是什么事兒，因為任務(wù)說明書是有名稱的，但是至于任務(wù)說明書的內(nèi)容，它就不清
楚了。具體的事情DAO和任務(wù)說明書清楚，但是業(yè)務(wù)邏輯對象只是一個交接。換句話就是說，通過這么一個交接手續(xù)，把持久層的東西還給持久層了。業(yè)務(wù)邏輯對
象只想知道“這事兒”辦完的結(jié)果，事實上本來就應(yīng)該這樣。
整體設(shè)計上面，涉及到了幾個持久層開發(fā)的基本的技巧，除了IOC、CallBack之外，還有DAO和容器管理。
DAO的模式其實也不是什么新鮮的搖滾Rock'n'Roll了，企業(yè)級應(yīng)用要的就不是新鮮的東西（注4）。這個方式里面用的DAO是通用型的DAO，通
用型的DAO的優(yōu)點就是接口統(tǒng)一，框架比較容易理解。但是缺點也十分明顯，那就是它本身的靈活性是值得懷疑的，JDBC就是一個統(tǒng)一的接口，結(jié)果呢，直接
用它就會導(dǎo)致SQL遍布代碼，這本身就增加了管理的復(fù)雜度，本來就是來封裝持久層的，結(jié)果跟沒封裝沒有區(qū)別，那么這個工作就是值得懷疑的。非通用型的
DAO倒是可以解決這個問題，但是非通用型的DAO就太靈活了，沒有辦法對它進(jìn)行良好的封裝，而且對于建筑在持久層的基礎(chǔ)之上的業(yè)務(wù)邏輯層架構(gòu)而言，這種
靈活性導(dǎo)致了只能對業(yè)務(wù)邏輯操作進(jìn)行粗放式的封裝，可重用的東西相對沒有使用通用型DAO的時候多了。還有就是非通用型DAO的開發(fā)上面想要實現(xiàn)代碼重用
也是比較麻煩的（需要良好的設(shè)計）。
至于容器管理嗎，明天再談。
注1：如果業(yè)務(wù)開發(fā)人員具有很多的持久層框架經(jīng)驗，當(dāng)持久層框架更
換時，必然會造成他的極度不適應(yīng)，這通常是系統(tǒng)移植成本很高的原因之一
注2 ：這是有可能的，類比一下C++和匯編語言，用Eclipse和用手工進(jìn)行重構(gòu)
注3：包括庫表修改、框架更換和方式的修改——事實上，如果業(yè)務(wù)邏輯發(fā)生了修改，那么持久層可能必須得改，但是如果持久層封裝的好的話，反之未必亦然
注4：公司重要的事情是盈利，根據(jù)技術(shù)辯證法，任何一個技術(shù)有有其優(yōu)點也有其缺點，都有其適用和不適用的地方，新鮮的技術(shù)往往由于是對已有技術(shù)的革新，所
以在一段時間內(nèi)會有很多潛在問題，作為愛好者去試用去跟技術(shù)的負(fù)責(zé)人聯(lián)系當(dāng)然是沒問題，但是作為企業(yè)，對產(chǎn)品是質(zhì)量要負(fù)有法律責(zé)任的，一般的公司當(dāng)然都不
會愿意當(dāng)新技術(shù)的小白鼠。相對而言，舊的技術(shù)由于擁有廣泛的使用，優(yōu)點和缺點廣為人知，熟練開發(fā)人員也比較容易找到，可以在開發(fā)中規(guī)避其自身的缺點。當(dāng)
然，不新鮮的也得看著要，得根據(jù)實際情況再作決定。