国产精品伊人色,久久精品国产一区二区电影,国产视色精品亚洲一区二区

2007年4月18日

Javascript的IE和Firefox兼容性匯編

摘要: 以下以 IE 代替 Internet Explorer，以 MF 代替 Mozzila Firefox 1. document.form.item 問題 (1)現(xiàn)有問題：現(xiàn)有代碼中存在許多 document.formName.item("itemName") 這樣的語... 閱讀全文

posted @ 2007-09-06 09:26 萬博閱讀(1664) | 評(píng)論 (0) | 編輯收藏

OSCache是當(dāng)前運(yùn)用最廣的緩存方案。其主被用的最廣泛功能是緩存頁面，這里主要是用其緩存文件對(duì)象。
運(yùn)用OScache的步驟：
1.取得oscache.jar 文件放到 /WEB-INF/lib 或相應(yīng)類庫目錄目錄中。
2.oscache.jar依賴commons-collections.jar包。如果你的jdk版本為1.3,
   建議在lib中加入Apache Common Lib 的commons-collections.jar包。
   如jdk是1.4以上則不必要。
3.src根目錄或發(fā)布環(huán)境的/WEB-INF/classes 目錄下放入oscache.properties。

cache.memory
值為true 或 false ，默認(rèn)為在內(nèi)存中作緩存，
如設(shè)置為false，那cache只能緩存到數(shù)據(jù)庫或硬盤中，那cache還有什么意義：）

cache.capacity
緩存元素個(gè)數(shù)

cache.persistence.class
持久化緩存類，如此類打開，則必須設(shè)置cache.path信息

cache.cluster 相關(guān)
為集群設(shè)置信息。
如cache.cluster.multicast.ip為廣播IP地址
   cache.cluster.properties為集群屬性

cache.path
硬盤持久化時(shí)存放文件的目錄。如果目錄不存在OSCache會(huì)自動(dòng)創(chuàng)建。
Windows系統(tǒng)：c:\\myapp\\cache。其它：/opt/myapp/cache

cache.persistence.overflow.only*
是否只有當(dāng)指定的內(nèi)存緩存已經(jīng)滿時(shí)才進(jìn)行持久化。推薦使用true，flase是為向后兼容。

cache.unlimited.disk
硬盤緩存是否有限制。缺省為cache.capacity指定的值

運(yùn)用：
    com.opensymphony.oscache.general.GeneralCacheAdministrator
GeneralCacheAdministrator主要對(duì)實(shí)現(xiàn)持久化對(duì)象的保存以及取出的相關(guān)的操作。

Object getFromCache（String key）    //根據(jù)key獲取緩存對(duì)象
Object getFromCache（String key , int refreshInterval）//refreshInterval時(shí)間內(nèi)，根據(jù)key獲取緩存對(duì)象
void putInCache(String key ,Object obj) //保存被緩存對(duì)象
void flushAll()                                          //刪除所有被緩存的對(duì)象
void flushAll(Date date)                        //在指定的時(shí)間去刪除所有被緩存的對(duì)象
void cancelUpdate(String key)                //取消未確定的更新

Java代碼

1 package com.iflytek;
2
3 import java.io.BufferedInputStream;
4 import java.io.BufferedOutputStream;
5 import java.io.File;
6 import java.io.FileInputStream;
7 import java.io.IOException;
8 import java.text.SimpleDateFormat;
9 import java.util.Date;
10
11 import javax.servlet.ServletException;
12 import javax.servlet.http.HttpServlet;
13 import javax.servlet.http.HttpServletRequest;
14 import javax.servlet.http.HttpServletResponse;
15 import javax.servlet.http.HttpSession;
16
17 import com.opensymphony.oscache.base.NeedsRefreshException;
18 import com.opensymphony.oscache.general.GeneralCacheAdministrator;
19
20
21 public class DisplayChart extends HttpServlet {
22
23     /**
24      * Default constructor.
25      */
26     public DisplayChart() {
27         super();
28     }
29
30     /**
31      * Init method.
32      *
33      * @throws ServletException never.
34      */
35     public void init() throws ServletException {
36         return;
37     }
38
39
40     public static GeneralCacheAdministrator cacheAdmin = new GeneralCacheAdministrator();
41     public void service(HttpServletRequest request,
42                         HttpServletResponse response)
43             throws ServletException, IOException {
44
45         String path = getServletContext().getRealPath("/");
46         File file = null;
47         SimpleDateFormat sdf= new SimpleDateFormat("hh-mm-ss");
48         try {
49             file = (File)cacheAdmin.getFromCache(sdf.format(new Date()));
50             System.out.println("來自緩存!"+ sdf.format(new Date()));
51         } catch (NeedsRefreshException e) {
52             file = new File(path+"xmls\\Pipe11.xml");
53             cacheAdmin.putInCache(sdf.format(new Date()), file);
54             System.out.println("--緩存沒有!"+sdf.format(new Date()));
55         }
56         sendResponse(file,response);
57         return;
58     }
59     /**
60      * 把文件用響應(yīng)流寫出
61      * @param file
62      * @param response
63      * @throws IOException
64      */
65     public void sendResponse(File file,HttpServletResponse response) throws IOException{
66         BufferedInputStream  bis = new BufferedInputStream(new FileInputStream(file));
67         BufferedOutputStream bos = new BufferedOutputStream(response.getOutputStream());
68         byte[] input = new byte[1024];
69         boolean eof = false;
70         while (!eof) {
71             int length = bis.read(input);
72             if (length == -1) {
73                 eof = true;
74             }
75             else {
76                 bos.write(input, 0, length);
77             }
78         }
79         bos.flush();
80         bis.close();
81         bos.close();
82     }
83
84 }
85

posted @ 2007-07-26 15:58 萬博閱讀(1969) | 評(píng)論 (0) | 編輯收藏

lazy initialization 實(shí)現(xiàn) Singleton 時(shí) synchronized 的必要性說明

首先了解一下Singleton模式通常的兩種表現(xiàn)形式：
第一種形式：

public class Singleton {
    private Singleton(){}
    //在自己內(nèi)部定義自己一個(gè)實(shí)例，是不是很奇怪？
    //注意這是private 只供內(nèi)部調(diào)用
    private static Singleton instance = new Singleton();
    //這里提供了一個(gè)供外部訪問本class的靜態(tài)方法，可以直接訪問
    public static Singleton getInstance() {
       return instance;
    }
}

第二種形式：

public class Singleton {
   private static Singleton instance = null;
   public static synchronized Singleton getInstance() {
      //這個(gè)方法比上面有所改進(jìn)，不用每次都進(jìn)行生成對(duì)象，只是第一次
      //使用時(shí)生成實(shí)例，提高了效率！
      if (instance==null) instance＝new Singleton();
      return instance;
   }
}

使用Singleton.getInstance()可以訪問單態(tài)類。
   上面第二中形式就是lazy initialization，也就是說第一次調(diào)用時(shí)初始Singleton，以后就不用再生成了。
   注意到lazy initialization形式中的synchronized，這個(gè)synchronized很重要，如果沒有synchronized，那么使用getInstance()是有可能得到多個(gè)Singleton實(shí)例。

   那么為什么只有使用synchronized關(guān)鍵字才可以達(dá)到單態(tài)的目的呢？synchronized到底有什么含義呢？
   synchronized 關(guān)鍵字，它包括兩種用法：synchronized 方法和 synchronized 塊。
1. synchronized 方法：通過在方法聲明中加入 synchronized關(guān)鍵字來聲明 synchronized 方法。如：

public synchronized void accessVal(int newVal);

   synchronized 方法控制對(duì)類成員變量的訪問：每個(gè)類實(shí)例對(duì)應(yīng)一把鎖，每個(gè) synchronized 方法都必須獲得調(diào)用該方法的類實(shí)例的鎖方能執(zhí)行，否則所屬線程阻塞，方法一旦執(zhí)行，就獨(dú)占該鎖，直到從該方法返回時(shí)才將鎖釋放，此后被阻塞的線程方能獲得該鎖，重新進(jìn)入可執(zhí)行狀態(tài)。這種機(jī)制確保了同一時(shí)刻對(duì)于每一個(gè)類實(shí)例，其所有聲明為 synchronized 的成員函數(shù)中至多只有一個(gè)處于可執(zhí)行狀態(tài)（因?yàn)橹炼嘀挥幸粋€(gè)能夠獲得該類實(shí)例對(duì)應(yīng)的鎖），從而有效避免了類成員變量的訪問沖突（只要所有可能訪問類成員變量的方法均被聲明為 synchronized）。
   在 Java 中，不光是類實(shí)例，每一個(gè)類也對(duì)應(yīng)一把鎖，這樣我們也可將類的靜態(tài)成員函數(shù)聲明為 synchronized ，以控制其對(duì)類的靜態(tài)成員變量的訪問。
   synchronized 方法的缺陷：若將一個(gè)大的方法聲明為synchronized 將會(huì)大大影響效率，典型地，若將線程類的方法 run() 聲明為 synchronized ，由于在線程的整個(gè)生命期內(nèi)它一直在運(yùn)行，因此將導(dǎo)致它對(duì)本類任何 synchronized 方法的調(diào)用都永遠(yuǎn)不會(huì)成功。當(dāng)然我們可以通過將訪問類成員變量的代碼放到專門的方法中，將其聲明為 synchronized ，并在主方法中調(diào)用來解決這一問題，但是 Java 為我們提供了更好的解決辦法，那就是 synchronized 塊。
2. synchronized 塊：通過 synchronized關(guān)鍵字來聲明synchronized 塊。語法如下：

synchronized(syncObject) {
//允許訪問控制的代碼
}

synchronized 塊是這樣一個(gè)代碼塊，其中的代碼必須獲得對(duì)象 syncObject （如前所述，可以是類實(shí)例或類）的鎖方能執(zhí)行，具體機(jī)制同前所述。由于可以針對(duì)任意代碼塊，且可任意指定上鎖的對(duì)象，故靈活性較高。

對(duì)synchronized(this)的一些理解

一、當(dāng)兩個(gè)并發(fā)線程訪問同一個(gè)對(duì)象object中的這個(gè)synchronized(this)同步代碼塊時(shí)，一個(gè)時(shí)間內(nèi)只能有一個(gè)線程得到執(zhí)行。另一個(gè)線程必須等待當(dāng)前線程執(zhí)行完這個(gè)代碼塊以后才能執(zhí)行該代碼塊。

二、然而，當(dāng)一個(gè)線程訪問object的一個(gè)synchronized(this)同步代碼塊時(shí)，另一個(gè)線程仍然可以訪問該object中的非synchronized(this)同步代碼塊。

三、尤其關(guān)鍵的是，當(dāng)一個(gè)線程訪問object的一個(gè)synchronized(this)同步代碼塊時(shí)，其他線程對(duì)object中所有其它synchronized(this)同步代碼塊的訪問將被阻塞。

四、第三個(gè)例子同樣適用其它同步代碼塊。也就是說，當(dāng)一個(gè)線程訪問object的一個(gè)synchronized(this)同步代碼塊時(shí)，它就獲得了這個(gè)object的對(duì)象鎖。結(jié)果，其它線程對(duì)該object對(duì)象所有同步代碼部分的訪問都被暫時(shí)阻塞。

五、以上規(guī)則對(duì)其它對(duì)象鎖同樣適用

posted @ 2007-07-25 14:14 萬博閱讀(475) | 評(píng)論 (0) | 編輯收藏

AOP的基本概念

切面（Aspect）：一個(gè)關(guān)注點(diǎn)的模塊化，這個(gè)關(guān)注點(diǎn)可能會(huì)橫切多個(gè)對(duì)象。事務(wù)管理是J2EE應(yīng)用中一個(gè)關(guān)于橫切關(guān)注點(diǎn)的很好的例子。在Spring AOP中，切面可以使用通用類（基于模式的風(fēng)格）或者在普通類中以 @Aspect 注解（@AspectJ風(fēng)格）來實(shí)現(xiàn)。
連接點(diǎn)（Joinpoint）：在程序執(zhí)行過程中某個(gè)特定的點(diǎn)，比如某方法調(diào)用的時(shí)候或者處理異常的時(shí)候。在Spring AOP中，一個(gè)連接點(diǎn) 總是代表一個(gè)方法的執(zhí)行。通過聲明一個(gè)org.aspectj.lang.JoinPoint類型的參數(shù)可以使通知（Advice）的主體部分獲得連接點(diǎn)信息。
通知（Advice）：在切面的某個(gè)特定的連接點(diǎn)（Joinpoint）上執(zhí)行的動(dòng)作。通知有各種類型，其中包括“around”、“before”和“after”等通知。通知的類型將在后面部分進(jìn)行討論。許多AOP框架，包括Spring，都是以攔截器做通知模型，并維護(hù)一個(gè)以連接點(diǎn)為中心的攔截器鏈。
切入點(diǎn)（Pointcut）：匹配連接點(diǎn)（Joinpoint）的斷言。通知和一個(gè)切入點(diǎn)表達(dá)式關(guān)聯(lián)，并在滿足這個(gè)切入點(diǎn)的連接點(diǎn)上運(yùn)行（例如，當(dāng)執(zhí)行某個(gè)特定名稱的方法時(shí)）。切入點(diǎn)表達(dá)式如何和連接點(diǎn)匹配是AOP的核心：Spring缺省使用AspectJ切入點(diǎn)語法。
引入（Introduction）：（也被稱為內(nèi)部類型聲明（inter-type declaration））。聲明額外的方法或者某個(gè)類型的字段。 Spring允許引入新的接口（以及一個(gè)對(duì)應(yīng)的實(shí)現(xiàn)）到任何被代理的對(duì)象。例如，你可以使用一個(gè)引入來使bean實(shí)現(xiàn) IsModified 接口，以便簡(jiǎn)化緩存機(jī)制。
目標(biāo)對(duì)象（Target Object）：被一個(gè)或者多個(gè)切面（aspect）所通知（advise）的對(duì)象。也有人把它叫做 被通知（advised） 對(duì)象。既然Spring AOP是通過運(yùn)行時(shí)代理實(shí)現(xiàn)的，這個(gè)對(duì)象永遠(yuǎn)是一個(gè) 被代理（proxied） 對(duì)象。
AOP代理（AOP Proxy）： AOP框架創(chuàng)建的對(duì)象，用來實(shí)現(xiàn)切面契約（aspect contract）（包括通知方法執(zhí)行等功能）。在Spring中，AOP代理可以是JDK動(dòng)態(tài)代理或者CGLIB代理。注意：Spring 2.0最新引入的基于模式（schema-based）風(fēng)格和@AspectJ注解風(fēng)格的切面聲明，對(duì)于使用這些風(fēng)格的用戶來說，代理的創(chuàng)建是透明的。
織入（Weaving）：把切面（aspect）連接到其它的應(yīng)用程序類型或者對(duì)象上，并創(chuàng)建一個(gè)被通知（advised）的對(duì)象。這些可以在編譯時(shí)（例如使用AspectJ編譯器），類加載時(shí)和運(yùn)行時(shí)完成。 Spring和其他純Java AOP框架一樣，在運(yùn)行時(shí)完成織入。

通知的類型：

前置通知（Before advice）：在某連接點(diǎn)（join point）之前執(zhí)行的通知，但這個(gè)通知不能阻止連接點(diǎn)前的執(zhí)行（除非它拋出一個(gè)異常）。
返回后通知（After returning advice）：在某連接點(diǎn)（join point）正常完成后執(zhí)行的通知：例如，一個(gè)方法沒有拋出任何異常，正常返回。
拋出異常后通知（After throwing advice）：在方法拋出異常退出時(shí)執(zhí)行的通知。
后通知（After (finally) advice）：當(dāng)某連接點(diǎn)退出的時(shí)候執(zhí)行的通知（不論是正常返回還是異常退出）。
環(huán)繞通知（Around Advice）：包圍一個(gè)連接點(diǎn)（join point）的通知，如方法調(diào)用。這是最強(qiáng)大的一種通知類型。環(huán)繞通知可以在方法調(diào)用前后完成自定義的行為。它也會(huì)選擇是否繼續(xù)執(zhí)行連接點(diǎn)或直接返回它們自己的返回值或拋出異常來結(jié)束執(zhí)行。

posted @ 2007-07-13 10:42 萬博閱讀(497) | 評(píng)論 (0) | 編輯收藏

JAVA四種基本排序的總結(jié)

JAVA四種基本排序,包括冒泡法,插入法,選擇法,SHELL排序法.其中選擇法是冒泡法的改進(jìn),SHELL排序法是插入法的改進(jìn).所以從根本上來說可以歸納為兩種不同的排序方法:即:插入法＆冒泡法

一插入法:遍歷排序集合，每到一個(gè)元素時(shí)，都要將這個(gè)元素與所有它之前的元素遍歷比較一遍，讓符合排序順序的元素挨個(gè)移動(dòng)到當(dāng)前范圍內(nèi)它最應(yīng)該出現(xiàn)的位置。交換是相鄰遍歷移動(dòng)，雙重循環(huán)控制實(shí)現(xiàn).這種排序法屬于地頭蛇類型,在我的地牌上我要把所有的東西按一定的順序規(guī)整,過來一個(gè),規(guī)整一個(gè).
處理代碼如下:

public void sort(int[] data) {
   int temp;
   for(int i=1; i〈data.length; i++){
      for(int j=i; (j〉0)&&(data[j]〉data[j-1]); j--){
         temp=date[j];
         data[j]=data[j-1];
         data[j-1]=temp;
      }
   }
}

二冒泡法:比較容易，它的內(nèi)層循環(huán)保證遍歷一次后，集合中最小（大）元素出現(xiàn)在它的正確位置，下一次就是次小元素。。。該方法在集合分布的各種情況下交換移動(dòng)的次數(shù)基本不變，屬于最慢的一種排序。實(shí)現(xiàn)也是雙重循環(huán)控制。這種排序法屬于過江龍,就是要找到極端,但是過獎(jiǎng)龍也有大哥,二哥等,所以他們只能是大哥挑了二哥挑.
處理代碼如下:

public static int [] maopao(int[] data) {
   int temp;
   for(int i=0; i〈data.length-1; i++){
      for(int j=i+1; j〈data.length; j++){
      if(data[i]〈data[j]){
         temp=data[i];
         data[i]=data[j];
         data[j]=temp;
      }
   }
}
return data;

三選擇法:該方法只是通過遍歷集合記錄最小（大）元素的位置，一次遍歷完后，再進(jìn)行交換位置操作，類似冒泡，但在比較過程中，不進(jìn)行交換操作，只記錄元素位置。一次遍歷只進(jìn)行一次交換操作。這個(gè)對(duì)與交換次序比較費(fèi)時(shí)的元素比較適合。這種排序法比冒泡法要城府要深的多,我先記住極端數(shù)據(jù),待遍歷數(shù)據(jù)完了之后,我再處理,不像冒泡法那樣只要比自己極端一點(diǎn)的就要處理,選擇法只處理本身范圍內(nèi)的最極端數(shù)據(jù).

public static void xuanze(int[] data) {
   int temp;
   for (int i = 0; i 〈 data.length; i++) {
      int lowIndex = i;
      for (int j = data.length - 1; j 〉 i; j--) {
         if (data[j] 〉 data[lowIndex]) {
            lowIndex = j;
         }
      }
      temp=data[i];
      data[i]=data[lowIndex];
      data[lowIndex]=temp;
   }
}

四 Shell排序：
它是對(duì)插入排序的一種改進(jìn)，是考慮將集合元素按照一定的基數(shù)劃分成組去排序，讓每一組在局部范圍內(nèi)先排成基本有序，最后在進(jìn)行一次所有元素的插入排序。

public void sort(int[] data) {
   for(int i=data.length/2; i〉2; i/=2){
      for(int j=0; j〈i; j++){
         insertSort(data,j,i);
      }
   }
   insertSort(data,0,1);
}

private void insertSort(int[] data, int start, int inc) {
   int temp;
   for(int i=start+inc; i〈data.length; i+=inc){
      for(int j=i; (j〉=inc)&&(data[j]〈data[j-inc]); j-=inc){
         temp=data[j];
         data[j]=data[j-inc]
         data[j-inc]=temp;
      }
   }
}

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1630773

posted @ 2007-06-28 11:06 萬博閱讀(288) | 評(píng)論 (0) | 編輯收藏

當(dāng)前Java軟件開發(fā)中幾種認(rèn)識(shí)誤區(qū)

　　越來越多人開始使用Java，但是他們大多數(shù)人沒有做好足夠的思想準(zhǔn)備(沒有接受OO思想體系相關(guān)培訓(xùn))，以致不能很好駕馭Java項(xiàng)目，甚至導(dǎo)致開發(fā)后的Java系統(tǒng)性能緩慢甚至經(jīng)常當(dāng)機(jī)。很多人覺得這是Java復(fù)雜導(dǎo)致，其實(shí)根本原因在于：我們?cè)日莆盏年P(guān)于軟件知識(shí)(OO方面)不是太貧乏就是不恰當(dāng)，存在認(rèn)識(shí)上和方法上的誤區(qū)。

軟件的生命性

　　軟件是有生命的，這可能是老調(diào)重彈了，但是因?yàn)樗玛P(guān)分層架構(gòu)的原由，反復(fù)強(qiáng)調(diào)都不過分。

　　一個(gè)有生命的軟件首先必須有一個(gè)靈活可擴(kuò)展的基礎(chǔ)架構(gòu)，其次才是完整的功能。

　　目前很多人對(duì)軟件的思想還是焦點(diǎn)落在后者：完整的功能，覺得一個(gè)軟件功能越完整越好，其實(shí)關(guān)鍵還是架構(gòu)的靈活性，就是前者，基礎(chǔ)架構(gòu)好，功能添加只是時(shí)間和工作量問題，但是如果架構(gòu)不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長(zhǎng)時(shí)，更多功能需要加入，但是因?yàn)榛A(chǔ)架構(gòu)不靈活不能方便加入，死路一條。

　　正因?yàn)槠胀ㄈ藢?duì)軟件存在短視誤區(qū)，對(duì)功能追求高于基礎(chǔ)架構(gòu)，很多吃了虧的老程序員就此離開軟件行業(yè)，帶走寶貴的失敗經(jīng)驗(yàn)，新的盲目的年輕程序員還是使用老的思維往前沖。其實(shí)很多國(guó)外免費(fèi)開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實(shí)類似國(guó)內(nèi)那些幾百元的盜版軟件，擴(kuò)展性以及持續(xù)發(fā)展性嚴(yán)重不足。

　　那么選擇現(xiàn)在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎(chǔ)架構(gòu)打好了呢？其實(shí)還不盡然，關(guān)鍵還是取決于你如何使用這些框架來搭建你的業(yè)務(wù)系統(tǒng)。

存儲(chǔ)過程和復(fù)雜SQL語句的陷阱

　　首先談?wù)劥鎯?chǔ)過程使用的誤區(qū)，使用存儲(chǔ)過程架構(gòu)的人以為可以解決性能問題，其實(shí)它正是導(dǎo)致性能問題的罪魁禍?zhǔn)字唬騻€(gè)比喻：如果一個(gè)人頻臨死亡，打一針可以讓其延長(zhǎng)半年，但是打了這針，其他所有醫(yī)療方案就全部失效，請(qǐng)問你會(huì)使用這種短視方案嗎？

　　為什么這樣說呢？如果存儲(chǔ)過程都封裝了業(yè)務(wù)過程，那么運(yùn)行負(fù)載都集中在數(shù)據(jù)庫端，要中間J2EE應(yīng)用服務(wù)器干什么？要中間服務(wù)器的分布式計(jì)算和集群能力做什么？只能回到過去集中式數(shù)據(jù)庫主機(jī)時(shí)代。現(xiàn)在軟件都是面向互聯(lián)網(wǎng)的，不象過去那樣局限在一個(gè)小局域網(wǎng)，多用戶并發(fā)訪問量都是無法確定和衡量，依靠一臺(tái)數(shù)據(jù)庫主機(jī)顯然是不能夠承受這樣惡劣的用戶訪問環(huán)境的。（當(dāng)然搞數(shù)據(jù)庫集群也只是五十步和百步的區(qū)別）。

　　從分層角度來看，現(xiàn)在三層架構(gòu)：表現(xiàn)層、業(yè)務(wù)層和持久層，三個(gè)層次應(yīng)該分割明顯，職責(zé)分明：持久層職責(zé)持久化保存業(yè)務(wù)模型對(duì)象，業(yè)務(wù)層對(duì)持久層的調(diào)用只是幫助我們激活曾經(jīng)委托其保管的對(duì)象，所以，不能因?yàn)槌志脤邮潜９苷?，我們就以其為核心圍繞其編程，除了要求其歸還模型對(duì)象外，還要求其做其做復(fù)雜的業(yè)務(wù)組合。打個(gè)比喻：你在火車站將水果和盤子兩個(gè)對(duì)象委托保管處保管，過了兩天來取時(shí)，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給你，合理嗎？

　　上面是談過分依賴持久層的一個(gè)現(xiàn)象，還有一個(gè)正好相反現(xiàn)象，持久層散發(fā)出來，開始擠占業(yè)務(wù)層，腐蝕業(yè)務(wù)層，整個(gè)業(yè)務(wù)層到處看見的是數(shù)據(jù)表的影子（包括數(shù)據(jù)表的字段），而不是業(yè)務(wù)對(duì)象。這樣程序員應(yīng)該多看看OO經(jīng)典PoEAA。PoEAA 認(rèn)為除了持久層，不應(yīng)該在其他地方看到數(shù)據(jù)表或表字段名。

　　當(dāng)然適量使用存儲(chǔ)過程，使用數(shù)據(jù)庫優(yōu)點(diǎn)也是允許的。按照Evans DDD理論，可以將SQL語句和存儲(chǔ)過程作為規(guī)則Specification一部分。

Hibernate等ORM問題
　　現(xiàn)在使用Hibernate人也不少，但是他們發(fā)現(xiàn)Hibernate性能緩慢，所以尋求解決方案，其實(shí)并不是 Hibernate性能緩慢，而是我們使用方式發(fā)生錯(cuò)誤：

　　“最近本人正搞一個(gè)項(xiàng)目，項(xiàng)目中我們用到了struts1.2+hibernate3, 由于關(guān)系復(fù)雜表和表之間的關(guān)系很多，在很多地方把lazy都設(shè)置false，所以導(dǎo)致數(shù)據(jù)一加載很慢，而且查詢一條數(shù)據(jù)更是非常的慢。”

　　Hibernate是一個(gè)基于對(duì)象模型持久化的技術(shù)，因此，關(guān)鍵是我們需要設(shè)計(jì)出高質(zhì)量的對(duì)象模型，遵循DDD領(lǐng)域建模原則，減少降低關(guān)聯(lián)，通過分層等有效辦法處理關(guān)聯(lián)。如果采取圍繞數(shù)據(jù)表進(jìn)行設(shè)計(jì)編程，加上表之間關(guān)系復(fù)雜（沒有科學(xué)方法處理、偵察或減少這些關(guān)系），必然導(dǎo)致系統(tǒng)運(yùn)行緩慢，其實(shí)同樣問題也適用于當(dāng)初對(duì)EJB的實(shí)體Bean的CMP抱怨上，實(shí)體Bean是Domain Model持久化，如果不首先設(shè)計(jì)Domain Model，而是設(shè)計(jì)數(shù)據(jù)表，和持久化工具設(shè)計(jì)目標(biāo)背道而馳，能不出問題嗎？關(guān)于這個(gè)問題N多年就在Jdon爭(zhēng)論過。

　　這里同樣延伸出另外一個(gè)問題：數(shù)據(jù)庫設(shè)計(jì)問題，數(shù)據(jù)庫是否需要在項(xiàng)目開始設(shè)計(jì)？
如果我們進(jìn)行數(shù)據(jù)庫設(shè)計(jì)，那么就產(chǎn)生了一系列問題：當(dāng)我們使用Hibernate實(shí)現(xiàn)持久保存時(shí)，必須考慮事先設(shè)計(jì)好的數(shù)據(jù)庫表結(jié)構(gòu)以及他們的關(guān)系如何和業(yè)務(wù)對(duì)象實(shí)現(xiàn)映射，這實(shí)際上是非常難實(shí)現(xiàn)的，這也是很多人覺得使用ORM框架棘手根本原因所在。

　　當(dāng)然，也有腦力相當(dāng)發(fā)達(dá)的人可以實(shí)現(xiàn)，但是這種圍繞數(shù)據(jù)庫實(shí)現(xiàn)映射的結(jié)果必然扭曲業(yè)務(wù)對(duì)象，這類似于兩個(gè)板塊（數(shù)據(jù)表和業(yè)務(wù)對(duì)象）相撞，必然產(chǎn)生地震，地震的結(jié)果是兩敗俱傷，軟的一方吃虧，業(yè)務(wù)對(duì)象是代碼，相當(dāng)于數(shù)據(jù)表結(jié)構(gòu)，屬于軟的一方，最后導(dǎo)致業(yè)務(wù)對(duì)象變成數(shù)據(jù)傳輸對(duì)象DTO, DTO滿天飛，性能和維護(hù)問題隨之而來。

　　領(lǐng)域建模解決了上述眾多不協(xié)調(diào)問題，特別是ORM痛苦使用問題，關(guān)于ORM/Hibernate使用還是那句老話：如果你不掌握領(lǐng)域建模方法，那么就不要用Hibernate，對(duì)于這個(gè)層次的你：也許No ORM 更是一個(gè)簡(jiǎn)單之道： No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715

Spring分層矛盾問題
　　Spring是以挑戰(zhàn)EJB面貌出現(xiàn)，其本身擁有的強(qiáng)大組件定制功能是優(yōu)點(diǎn)，但是存在實(shí)戰(zhàn)的一些問題，Spring作為業(yè)務(wù)層框架，不支持業(yè)務(wù)層Session 功能。

　　具體舉例如下：當(dāng)我們實(shí)現(xiàn)購物車之類業(yè)務(wù)功能時(shí)，需要將購物場(chǎng)合保存到Session中，由于業(yè)務(wù)層沒有方便的Session支持，我們只得將購物車保存到 HttpSession，而HttpSession只有通過HttpRequest才能獲得，再因?yàn)樵赟pring業(yè)務(wù)層容器中是無法訪問到HttpRequest這個(gè)對(duì)象的，所以，最后我們只能將“購物車保存到HttpSession”這個(gè)功能放在表現(xiàn)層中實(shí)現(xiàn)，而這個(gè)功能明顯應(yīng)該屬于業(yè)務(wù)層功能，這就導(dǎo)致我們的Java項(xiàng)目層次混亂，維護(hù)性差。違背了使用Spring和分層架構(gòu)最初目的。

　　相關(guān)案例：請(qǐng)教一個(gè)在完整提交前臨時(shí)保存的問題:
　　http://www.jdon.com/jive/article.jsp?forum=46&thread=28429

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD
　　現(xiàn)在回到我們討論的重點(diǎn)上來，分層架構(gòu)是我們使用Java的根本原因之一，域建模專家Eric Evans在他的“Domain Model Design”一書中開篇首先強(qiáng)調(diào)的是分層架構(gòu)，整個(gè)DDD理論實(shí)際是告訴我們?nèi)绾问褂媚Ｐ蛯?duì)象oo技術(shù)和分層架構(gòu)來設(shè)計(jì)實(shí)現(xiàn)一個(gè)Java項(xiàng)目。

　　我們現(xiàn)在很多人知道Java項(xiàng)目基本有三層：表現(xiàn)層　業(yè)務(wù)層和持久層，當(dāng)我們執(zhí)著于討論各層框架如何選擇之時(shí)，實(shí)際上我們真正的項(xiàng)目開發(fā)工作還沒有開始，就是我們選定了某種框架的組合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我們還沒有意識(shí)到業(yè)務(wù)層工作還需要大量工作，DDD提供了在業(yè)務(wù)層中再劃分新的層次思想，如領(lǐng)域?qū)雍头?wù)層，甚至再細(xì)分為作業(yè)層、能力層、策略層等等。通過層次細(xì)化方式達(dá)到復(fù)雜軟件的松耦合。DDD提供了如何細(xì)分層次的方式

　　當(dāng)我們將精力花費(fèi)在架構(gòu)技術(shù)層面的討論和研究上時(shí)，我們可能忘記以何種依據(jù)選擇這些架構(gòu)技術(shù)？選擇標(biāo)準(zhǔn)是什么？領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)DDD 回答了這樣的問題，DDD會(huì)告訴你如果一個(gè)框架不能協(xié)助你實(shí)現(xiàn)分層架構(gòu)，那就拋棄它，同時(shí)，DDD也指出選擇框架的考慮目的，使得你不會(huì) 人云亦云，陷入復(fù)雜的技術(shù)細(xì)節(jié)迷霧中，迷失了架構(gòu)選擇的根本方向。

　　現(xiàn)在也有些人誤以為DDD是一種新的理論，其實(shí)DDD和設(shè)計(jì)模式一樣，不是一種新的理論，而是實(shí)戰(zhàn)經(jīng)驗(yàn)的總結(jié)，它將前人使用面向模型設(shè)計(jì)的方法經(jīng)驗(yàn)提煉出來，供后來者學(xué)習(xí)，以便迅速找到駕馭我們軟件項(xiàng)目的根本之道。

　　現(xiàn)在Evans　DDD概念很火，因?yàn)樗鼘⒅?a target=_blank>PoEAA進(jìn)行了具化，實(shí)現(xiàn)了PoEAA可操作性，這也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微軟的.NET架構(gòu)和Evans DDD比較的文章：http://weblogs.asp.net/pgielens/archive/2006/08/08/Organizing-Domain-Logic.aspx，這篇文章比較了微軟的三層服務(wù)應(yīng)用架構(gòu)[Microsoft TLSA]和Evans DDD的架構(gòu)，使用Microsoft .NET Pet Shop 4為例子，解釋兩個(gè)目標(biāo)的區(qū)別，并且表明
微軟是如何在案例中更好地實(shí)現(xiàn)支持后者。這篇文章幫助哪些.NET平臺(tái)上有域設(shè)計(jì)知識(shí)的人實(shí)現(xiàn)更好地提高。

　　另外一本關(guān)于.NET的DDD書籍也已經(jīng)出版，這些都說明Evans DDD這把火已經(jīng)燒到.NET領(lǐng)域，當(dāng)然DDD在Java領(lǐng)域生根開花多年，Evans的DDD書籍就是以Java為例子的，筆者板橋里人也率先在2005年推出DDD框架JdonFramework 1.3版本，這些都說明，Java在整個(gè)軟件業(yè)先進(jìn)思想的實(shí)踐上總是領(lǐng)先一步。

參考文章：

面向?qū)ο笈c領(lǐng)域建模

實(shí)戰(zhàn)DDD(Domain-Driven Design領(lǐng)域驅(qū)動(dòng)設(shè)計(jì))

領(lǐng)域模型驅(qū)動(dòng)設(shè)計(jì)(DDD)之模型提煉

數(shù)據(jù)庫時(shí)代的終結(jié)

Java EE/J2EE面向?qū)ο缶幊讨?/strong>

更多關(guān)于DDD討論

更多關(guān)于EJB3討論

更多關(guān)于IOC討論

更多關(guān)于AOP討論

更多關(guān)于Spring討論

更多關(guān)于JdonFramework討論

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1630894

posted @ 2007-06-28 09:30 萬博閱讀(256) | 評(píng)論 (0) | 編輯收藏

Hibernate的主鍵生成器使用總結(jié)
摘要: 總結(jié)了Hibernate提供的所有主鍵生成器，比較個(gè)生成器使用時(shí)機(jī)，并且列舉一個(gè)自定義主鍵生成器實(shí)例。閱讀全文
posted @ 2007-04-18 20:19 萬博閱讀(2753) | 評(píng)論 (0) | 編輯收藏

Powered by:
BlogJava
Copyright © 萬博

Javascript的IE和Firefox兼容性匯編

OSCache 緩存對(duì)象的總結(jié)

lazy initialization 實(shí)現(xiàn) Singleton 時(shí) synchronized 的必要性說明

AOP的基本概念

JAVA四種基本排序的總結(jié)

當(dāng)前Java軟件開發(fā)中幾種認(rèn)識(shí)誤區(qū)

Hibernate的主鍵生成器使用總結(jié)

導(dǎo)航

統(tǒng)計(jì)

留言簿(1)

隨筆檔案(13)

搜索

積分與排名

最新隨筆

最新評(píng)論

閱讀排行榜

評(píng)論排行榜