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
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。