我來說說Bean的使用方法

2019-11-18 12:03:14

字體：大中小

來源：轉載

供稿：網友

　　最近討論主要圍繞在公共構造函數以及工廠模式身上。我在此分貼，說說我對 Bean的看法。因為最近項目使用到了webwork，sPRing，hibernate。我主要結合這些框架來談談我個人對pojo bean的熟悉。
　　bean的規范使得對象屬性填充得到動態支持，Bean的規范使得對象圖的建立非常清楚。OGNL正是基于此實現。
　　在對bean屬性賦值與 bean的定義之間插入一個中間層OGNL，得到最大限度的靈活。我們舉一個比較極端但確實經常發生的例子（順帶狠狠批一下Struts）。
　　
　　java代碼:
　　
　　1
　　2　 // 持久層entity:
　　3　public class BeanA{
　　...}
　　4　　private String name;
　　5　　private int number;
　　6　　public BeanA(){
　　...}
　　7　　}
　　8　　public String getName(){
　　...}
　　9return name;
　　10　 }
　　11　 public void setName(String name){
　　...}
　　12　　 this.name=name;
　　13　 }
　　14　 public int getNumber(){
　　...}
　　15　　 return number;
　　16　 }
　　17　 public void setNumber(int num){
　　...}
　　18　　 number=num;
　　19　 }
　　20 }
　　21
　　22 //視圖層form:
　　23 Struts:
　　24 public class BeanAForm{
　　...}
　　25　 private String name;
　　26　 private String number;
　　27　 public BeanA(){
　　...}
　　28　 }
　　29　 public String getName(){
　　...}
　　30　　 return name;
　　31　 }
　　32　 public void setName(String name){
　　...}
　　33　　 this.name=name;
　　34　 }
　　35　 public String getNumber(){
　　...}
　　36　　 return number;
　　37　 }
　　38　 public void setNumber(String num){
　　...}
　　39　　 number=num;
　　40　 }
　　41 }
　　42
　　
　　struts通過form定義利用bean的特性達到form的自動填充，然后通過beanutil將form轉到entity或者DTO。
　　某天，客戶覺得需要修改entity，增多一個字段bar，struts的做法是修改form，修改entity，修改配置文件的form定義，修改客戶端jsp文件等等，然后編譯通過，update database schema。
　　webwork的做法就非常簡單了，在open session in filter模式下，只需改動
　　entity的定義即可，ognl將所有的問題變得簡單得可怕。
　　OGNL完全將客戶端到服務器端的參數傳遞代理了，只要你在你的action定義相應的name setter，ognl自動識別到這個setter，自動將參數傳遞進來。
　　對于多層關聯的情況，最極端的如下：
　　
　　java代碼:
　　1
　　2　public class A{
　　...}
　　3　　private B b;
　　4　　//getter
　　5　　//setter
　　6　};
　　7　public class B{
　　...}
　　8　　private C c;
　　9　　//getter setter
　　10 };
　　11 public class C{
　　...}
　　12　 String name;
　　13
　　14 };
　　
　　你在視圖層只暴露了A對象，而需要通過form修改C對象的值，這種情況在struts我不知道它怎么實現，但是在webwork下，依靠OGNL，您要做的僅僅寫下這么一句：name="a.b.c.name" 。Ognl自動將name的值填充到c的屬性。
　　討論了這么多，回過頭來看，是什么東西使得我們web開發變得簡單了呢？是OGNL，那么OGNL為什么這么強大呢？因為OGNL是基于Bean的對象圖尋找方式?。?br />　　到這里，我們看到了Bean是一切的基礎，沒有bean就沒有OGNL。
　　同樣，看看IoC容器，一樣的道理，沒有Bean就沒有IoC容器的實現。假如采用bean的格式定義你的組件，那么意味著你的組件是可裝配的，假如采用bean定義的entity，意味著你的entity是可以自動填充的。
　　現在評價一個軟件好壞，可裝配性是一個重要目標。假設一個較復雜得系統，我們分析一下它的運作：
　　A系統由子系統C 子系統B 構成，子系統C 由C1,C2,C3等等服務組件構成，每個服務組件又需要調用多個基本服務類來協作。子系統B同樣構架。
　　
　　系統啟動過程：
　　bootrap啟動服務守護引擎，引擎讀取配置文件，相關初始化。
　　
　　服務過程：
　　一個請求上來，守護引擎根據請求映射，需要調用C子系統的服務接口，C子系統的服務接口未裝載，請求beanfactory裝載C子系統的服務接口，beanfactory讀取C系統接口配置，發現這個接口具體實現類，以及這個具體實現類需要到的C1，C2，C3組件，又根據引用讀取C1等的配置信息，知道最后的服務類是最簡單的POJO bean。逐一初始化所有需要用到的類，然后調用已經實例化的接口，完成服務。
　　
　　改動過程：
　　C1，C2組件需要改善功能，增加C4，C5組件。寫代碼，編譯打包，修改配置文件，發布。
　　服務過程如上
　　
　　這個系統是完全可插入的，因為它所有的服務過程都是基于組件的，組件是可裝配的。試想一下，假如其中的C1或者C2不是Bean格式，也就是說沒有公開構造器，那么這一切優雅的實現就斷節了，就算要實現這么一個類似的實現，也要需要花費大量的精力物力來填補構造器的模式。

上一篇：Log信息獲取調用類和調用方法名的實現原理

下一篇：試簡單概括面向對象接口編程