上一篇提到Java bean 的規范雖然定義的不錯, 但卻沒有獲得意料中的成功, 尤其是Java帝國所期待的桌面開發組件化市場上。

  我和小碼哥多么期待CSDN也能出一期《程序員大本營》, 里邊包含成千上萬的java bean 組件啊。

  不要幻想了, 趕緊把java bean 應用在服務器端才是正事。

  JSP + Java Bean

  小碼哥建議先用在jsp上試試,  可以用java bean 來封裝業務邏輯,保存數據到數據庫, 像這樣:

Java bean的前世今生(下)

注: 這其實叫做JSP Model 1

  其中jsp 直接用來接受用戶的請求, 然后通過java bean 來處理業務, 具體的使用方法是:

  <jsp:useBean id="user" scope="page" class="com.coderising.User"/>

  <jsp:setProperty property="userName" name="user" param="userName"/>

  <jsp:setProperty property="password" name="user" param="password"/>

  這就能把HTTP request中的所有參數都設置到 user 這個java bean 對應的屬性上去。

  如果想偷懶, 還可以這樣:

  <jsp:setProperty name="user" property="*"/>

  當然要保證 http request中的參數名和 java bean 中的屬性名是一樣的。

  這個叫做JSP Model 1 的模型受到了很多Java程序員的歡迎 ,  因為他們的應用規模都很小, 用Model 1 使得開發很快速。

  實際上, 這種方式和微軟帝國的asp , 以及和開源的php 幾乎一樣。

  但很快就有人來找我抱怨了, 說他們的項目中使用了Model 1 導致整個系統的崩潰。

  他說: “你知道嗎? 我們的系統中有好幾千個jsp, 這些jsp互相調用(通過GET/POST), 到了最后調用關系無人能搞懂。 ”

  其實我們已經預料到了, 小碼哥對此有個形象的比喻:意大利面條

Java bean的前世今生(下)

  這幾千個JSP 就像這碗面條一樣,攪在一起, 根本理不清楚。

  為了解決這個問題,小碼哥又推出了 :JSP Model 2 ,    這是個模型真正的體現了Model-View-Controller的思想:

Java bean的前世今生(下)

  Servlet 充當Controller ,  jsp 充當 View

  Java bean 當然就是Model 了!

  業務邏輯, 頁面顯示, 和處理過程做了很好的分離。

  基于這個模型的擴展和改進,  很多Web開發框架開始如雨后春筍一樣出現, 其中最著名的就是Struts, SpringMVC 了。

  Java Web開發迅速的繁榮了。

  我們再一次體會到了開放的好處 !

  Enterprise Java bean

  但是好景不長, 自從Java帝國統治了所謂的“企業級應用”開發領地, 各種各樣的游行和抗議層出不窮:

  “我們要分布式”

  “我們要安全”

  “我們要事務”

  “我們要高可用性”

  “......”

  帝國分析了一下, 其實這些程序員的訴求可以歸結為:

  “我們只想關注我們的業務邏輯, 我們不想, 也不應該由我們來處理‘低級’的事務, 多線程,連接池,以及其他各種各種的‘低級’API, 此外Java帝國一定得提供集群功能, 這樣我們的一臺機器死機以后,整個系統還能運轉。 ”

  我們不能坐著不管, 企業級應用是我們的命根子。

  小碼哥徹夜工作, 最終拿出了一個叫做J2EE的東西, 像Java bean 一樣, 這還是一個規范, 但是比Java bean 復雜的多, 其中有:

  JDBC:  Java 數據庫連接, 沒有數據庫的支持怎么能叫企業級應用?

  JNDI :  Java 命名和目錄接口, 通過一個名稱就可以定位到一個數據源, 連jdbc連接都不用了

  RMI:  遠程過程調用,  讓一個機器上的java 對象可以調用另外一個機器上的java 對象 , 你們不是要分布式嗎?

  JMS :   Java 消息服務,  可以使用消息隊列了, 這不是企業級應用非常需要的嗎?

  JTA:  Java 事務管理, 支持分布式事務, 能在訪問、更新多個數據庫的時候,仍然保證事務, 還是分布式。

  Java mail : 收發郵件也是必不可少的啊。

注:  J2EE 后來改成了Java EE。

  當然還有最最最重要的升級, 小碼哥把java bean 變成了 Enterprise Java bean , 簡稱 EJB。

  小碼哥宣稱:

  使用了EJB, 你就可以把精力只放在業務上了, 那些煩人的事務管理, 安全管理,線程 統統交給容器(應用服務器)來處理吧。

  我們還提供了額外的福利, 只要你的應用服務器是由多個機器組成的集群, EJB就可以無縫的運行在這個集群上, 你完全不用考慮一個機器死掉了應用該怎么辦。我們都幫你搞定了。

  使用Session Bean , 可以輕松的處理你的業務。

  使用實體Bean (Entity bean ) , 你和數據庫打交道會變得極為輕松, 甚至sql 都不用寫了。

  使用消息驅動Bean(Message Driven bean ) , 你可以輕松的和一個消息隊列連接, 處理消息。

  聽起來很美好是不是?

  企業級開發領地的程序員們歡呼雀躍, 坐上了J2EE這條船,似乎一下子高貴起來, 開始鄙視微軟的ASP, 開源的PHP, Python 等“不入流”的語言了 。

  Weblogic , Websphere等符合J2EE規范的應用服務器趁勢而上, 搖旗吶喊, 仿佛一個新的時代要來臨了, 當然他們在背后一直悶聲發大財。

  Spring

  有句古話是對的, 捧的越高, 跌的越慘。

  很快,大部分的程序員就發現, 美好的前景并沒有實現, EJB中用起來極為繁瑣和笨重, 性能也不好, 為了獲得所謂的分布式,反而背上了沉重的枷鎖。

  實體Bean很快沒人用了, 就連簡單的無狀態Session bean 也被大家所詬病, 其中一條罪狀就是“代碼的侵入性”。

  也是, 小碼哥定義EJB的時候沒考慮那么多,程序員在定義一個Session bean的時候,需要寫一大堆和業務完全沒有關系的類。

  還需要被迫實現一些根本不應該實現的接口及其方法:

Java bean的前世今生(下)

  為了哪怕一點點業務邏輯, 我們都得寫這么多無用的代碼 ! 程序員們出離憤怒了!

  他們發起了一場叫做POJO (Plain Old Java Object)的運動, 高唱這POJO之歌, 要求我們整改。

  他們希望這個樣子:

Java代碼
  1. public class HelloworldBean{  
  2.     public String hello(){  
  3.         return "hello world"  
  4.     }  
  5. }  

  與此同時,他們還過分的要求保留事務了, 安全了這些必備的東西。

  程序員確實不好伺候,   但是我們已經被Weblogic, Websphere這些大佬們“綁架”, 想改動談何容易 !

  2002年, 小碼哥看到了Rod Johnson寫的一本書《Expert one on one J2EE development withoutEJB》 , 趕緊跑來找我:

  “老大, 壞了壞了, 你快看看這本書吧, 這個叫Rod的家伙寫的這本書直擊我們的命門,這廝要搞without EJB”

Java bean的前世今生(下)

注: 雖然這本書翻譯的很差,但由于是spring的開山之作,還是值得讀一下, 最好中英文對照

  豈止是without EJB,  他還“偷偷的”推出了一個叫什么Spring的框架, 已經迅速的流行開了。

  Spring 框架順應了POJO的潮流, 提供了一個spring 的容器來管理這些POJO, 好玩的是也叫做bean 。

  看來我們的java bean 走了一圈又回到了原點。

  對于一個Bean 來說,如果你依賴別的Bean , 只需要聲明即可, spring 容器負責把依賴的bean 給“注入進去“, 起初大家稱之為控制反轉(IoC)

  后來 Martin flower 給這種方式起來個更好的名字,叫“依賴注入”。

  如果一個Bean 需要一些像事務,日志,安全這樣的通用的服務, 也是只需要聲明即可, spring 容器在運行時能夠動態的“織入”這些服務, 這叫AOP。

  后來我和小碼哥商量, 我們EJB也學習Spring , 簡化開發和配置, 但是為時已晚, Spring 已經成為事實上的標準了!程序員已經被spring 拉走了!

  不過令我們欣慰的是, spring和spring mvc極大的增加了我們對web開發領地的統治力, java 帝國更加強盛了。

原作者:碼農翻身

原文鏈接:http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513118&idx=1&sn=487fefb8fa7efd59de6f37043eb21799&scene=1&srcid=0908B6FAflO9xghunxispJ9q#rd

碼農翻身公眾號由工作15年的前IBM架構師創建,分享編程和職場的經驗教訓。

碼農翻身二維碼:

除非特別注明,雞啄米文章均為原創
轉載請標明本文地址:http://www.028keji.com/software/586.html
2016年5月30日
作者:雞啄米 分類:軟件開發 瀏覽: 評論:0