|
|
1．大量的案例由于采用了這種技術(shù)反而使得系統(tǒng)開發(fā)日趨復(fù)雜，而不是想像的簡化開發(fā)周期加長成了家常便飯，實現(xiàn)一個進銷存就把很多人難倒。
2． EJB成了昂貴的代名詞，而不是期望的成本降低
3． 廢了半天勁還不如用消息傳遞進行系統(tǒng)互操作
4． 最終發(fā)現(xiàn)徹底地擺脫平臺是不可能的
但是Java總歸還是不錯的，于是有了Spring等等N種體系。EJB開始讓人們困惑。任何技術(shù)和人生一樣有它的困惑期，但是EJB給人們的困惑尤為經(jīng)典，更具意義。J2EE和其他體系的對比已經(jīng)泛濫于網(wǎng)上，實際應(yīng)用的經(jīng)驗也隨處可見，以至于不需要這里介紹，但是EJB現(xiàn)在并未被單獨地被重視這是應(yīng)該值得注意的，這與J2EE發(fā)展史卻是背道而馳的。必須承認這么一個事實，EJB是被單獨提出和定義的，最早是完全單獨的一種規(guī)范，這與所謂體系結(jié)構(gòu)并沒有直接的關(guān)系，或者說EJB的意義和目標絕不只是在J2EE內(nèi)封裝商業(yè)邏輯，所以過于在框架內(nèi)討論EJB，或者說認為J2EE的弱點一定要蔓延到EJB上是否合適是值得探討的。
EJB誕生的初期人們的興奮關(guān)鍵在于這種模型吸收了以往組件技術(shù)的精華，并有很大發(fā)展，使人們看到了強健的商業(yè)組件制造成本降低的期望，特別是跨越平臺的可裝配性和移植性，這是軟件工程界一直的夢想，因為這意味著企業(yè)端計算程序設(shè)計工業(yè)化和細致分工也許要成為可能。這種思想目前也影響了界面一級的應(yīng)用，例如所謂的Portlet技術(shù)，IBM公司的WebSphere平臺的技術(shù)也許不是可怕的，但是有幾十個合作伙伴事實上給它提供了類似的合作，這才真正是讓對手感到害怕的。因此我們談?wù)揈JB的時候，談?wù)撍膬r值和作用，脫離了它的設(shè)計目標也就失去了更大的意義，以下的商業(yè)環(huán)境和軟件技術(shù)瓶頸應(yīng)該重新被審視：
1． 軟件工程就重用領(lǐng)域來講是否超越了組件時代，或者說已經(jīng)不需要組件了？
2． 軟件的重用是否只需要互調(diào)用而不需要重復(fù)裝配，乃至裝配到不同的部位？
3． 商業(yè)邏輯是否仍然需要封裝，并保持強健的特性，不間斷地服務(wù)
4． 組件和強健和可用性是互聯(lián)特性能取代的嗎？
5． 是否有更廉價的組件形式超越EJB并同樣獲得眾多的支持？
6． .NET的組件標準和EJB是否有可比性，或者說什么組件形式和EJB才有可比性？
當(dāng)冷靜地思考的時候就知道，技術(shù)不應(yīng)該被當(dāng)作明星吹捧，但同樣也沒有容易倒下的軟件技術(shù)。EJB不成熟，但不等于可以輕易被否定。是EJB使得很多普通的程序員能夠介入原來貴族似的組件開發(fā)，甚至是簡單的Windows上面開發(fā)UNIX上的組件，EJB的歷史問題大多數(shù)在于將這種技術(shù)錯誤地濫用：一個瀏覽人數(shù)少的可憐廣告瀏覽程序也要用組件，對于一個只想簡單算出庫存的客戶設(shè)計了所謂N年后才需要的擴展性。同樣現(xiàn)實中在這一技術(shù)擅長的領(lǐng)域，至少目前還無法找到更強大的競爭者。技術(shù)選擇是應(yīng)用型的技術(shù)人員永恒的主題，類似的困惑會不斷的出現(xiàn)，最重要的是認同它們的理想和目標，保持對它們客觀清醒的認識。放到擅長的領(lǐng)域的技術(shù)才是最優(yōu)美的，這和人生沒有什么兩樣。
jsp技術(shù)：EJB組件與可重用性的矛盾，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
