Java bean與Spring、Spring MVC關係

Java Bean

Java語言欠缺屬性、事件、多重繼承功能。因此，若是要在Java程序中實現一些面向對象編程的常見需求，只能手寫大量膠水代碼。Java Bean正是編寫這套膠水代碼的慣用模式或約定。這些約定包括getXxx、setXxx、isXxx、addXxxListener、XxxEvent等。遵照上述約定的類能夠用於若干工具或庫。

舉個例子，假若有人要用Java實現一個單向鏈表類，可能會這樣寫：

 

 

上述實現爲了可以快速獲取鏈表的大小，把鏈表大小緩存在size變量中。用法以下：

JavaIntList myList = new JavaIntList( );

System.out.println(myList.size);

要節省內存，不要緩存size變量了，把代碼改爲這樣：

 

 

發現找不到什麼size變量。若是要找到size變量，你就必須保持向後兼容性。因此Java標準庫中，絕對不會出現public int size這樣的代碼，而必定會一開始就寫成：

private int size;

public int getSize( ){return size;}

讓用戶一開始就使用getSize，以便有朝一日修改getSize實現時，不破壞向後兼容性。這種public int getSize() { return size; }的慣用手法，就是Java Bean。

JSP + Java Bean

在jsp上，  能夠用java bean 來封裝業務邏輯，保存數據到數據庫， 像這樣：

 

 

其中jsp 直接用來接受用戶的請求， 而後經過java bean 來處理業務， 具體的使用方法是：

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

只要保證 http request中的參數名和 java bean 中的屬性名是同樣的。 

這個叫作JSP Model 1 的模型受到了不少Java程序員的歡迎 ,  由於他們的應用規模都很小， 用Model 1 使得開發很快速，實際上， 這種方式和微軟的asp , 以及和開源的php 幾乎同樣。 

但在項目中頻繁使用了Model 1 致使整個系統的崩潰，由於系統中有好幾千個jsp， 這些jsp互相調用(經過GET/POST), 到了最後調用關係無人能搞懂。 

爲了解決這個問題，又推出了 ：JSP Model 2 ,    這是個模型真正的體現了Model-View-Controller的思想：

 

 

Servlet 充當Controller ,  jsp 充當 View ，Java bean 固然就是Model 了！

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

基於這個模型的擴展和改進，  不少Web開發框架開始如雨後春筍同樣出現， 其中最著名的就是 SpringMVC了。

Enterprise Java bean

愈來愈多企業程序員提出訴求：要分佈式、要安全、要事務、要高可用性。

訴求能夠歸結爲：「咱們只想關注咱們的業務邏輯， 咱們不想， 也不該該由咱們來處理‘低級’的事務， 多線程，鏈接池，以及其餘各類各類的‘低級’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 ) , 你能夠輕鬆的和一個消息隊列鏈接， 處理消息。

Spring

然而，大部分的程序員就發現，  EJB中用起來極爲繁瑣和笨重， 性能也很差， 爲了得到所謂的分佈式，反而背上了沉重的枷鎖。 

實體Bean很快沒人用了， 就連簡單的無狀態Session bean 也被你們所詬病， 其中一條罪狀就是「代碼的侵入性」。

在定義EJB的時候沒考慮那麼多，程序員在定義一個Session bean的時候，須要寫一大堆和業務徹底沒有關係的類。 

還須要被迫實現一些根本不該該實現的接口及其方法： 

 

 

他們但願這個樣子：

public class HelloworldBean{

    public String hello(){

        return "hello world"

   }

}

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

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

對於一個Bean 來講，若是你依賴別的Bean , 只須要聲明便可， spring 容器負責把依賴的bean 給「注入進去「， 起初你們稱之爲控制反轉(IoC)。

後來 Martin flower 給這種方式起來個更好的名字，叫「依賴注入」（DI）。

若是一個Bean 須要一些像事務，日誌，安全這樣的通用的服務， 也是隻須要聲明便可， spring 容器在運行時可以動態的「織入」這些服務， 這叫面向切面（AOP）。 

總之，spring和spring mvc極大的增長了Java對web開發領地的統治力。

做者：柏拉圖式Sin 連接：https://www.jianshu.com/p/e6e9762cd8e8 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。