欧美日产国产成人免费图片,91精品国产自产观看在线,精品视频一区在线

2007年4月14日

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 萬博閱讀(1669) | 評論 (0) | 編輯收藏

OSCache是當前運用最廣的緩存方案。其主被用的最廣泛功能是緩存頁面，這里主要是用其緩存文件對象。
運用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 ，默認為在內(nèi)存中作緩存，
如設(shè)置為false，那cache只能緩存到數(shù)據(jù)庫或硬盤中，那cache還有什么意義：）

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

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

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

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

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

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

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

Object getFromCache（String key）    //根據(jù)key獲取緩存對象
Object getFromCache（String key , int refreshInterval）//refreshInterval時間內(nèi)，根據(jù)key獲取緩存對象
void putInCache(String key ,Object obj) //保存被緩存對象
void flushAll()                                          //刪除所有被緩存的對象
void flushAll(Date date)                        //在指定的時間去刪除所有被緩存的對象
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 萬博閱讀(1972) | 評論 (0) | 編輯收藏

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

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

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

第二種形式：

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

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

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

public synchronized void accessVal(int newVal);

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

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

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

對synchronized(this)的一些理解

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

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

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

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

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

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

AOP的基本概念

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

通知的類型：

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

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

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

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

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

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)在它的正確位置，下一次就是次小元素。。。該方法在集合分布的各種情況下交換移動的次數(shù)基本不變，屬于最慢的一種排序。實現(xiàn)也是雙重循環(huán)控制。這種排序法屬于過江龍,就是要找到極端,但是過獎龍也有大哥,二哥等,所以他們只能是大哥挑了二哥挑.
處理代碼如下:

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;

三選擇法:該方法只是通過遍歷集合記錄最小（大）元素的位置，一次遍歷完后，再進行交換位置操作，類似冒泡，但在比較過程中，不進行交換操作，只記錄元素位置。一次遍歷只進行一次交換操作。這個對與交換次序比較費時的元素比較適合。這種排序法比冒泡法要城府要深的多,我先記住極端數(shù)據(jù),待遍歷數(shù)據(jù)完了之后,我再處理,不像冒泡法那樣只要比自己極端一點的就要處理,選擇法只處理本身范圍內(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排序：
它是對插入排序的一種改進，是考慮將集合元素按照一定的基數(shù)劃分成組去排序，讓每一組在局部范圍內(nèi)先排成基本有序，最后在進行一次所有元素的插入排序。

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 萬博閱讀(292) | 評論 (0) | 編輯收藏

當前Java軟件開發(fā)中幾種認識誤區(qū)

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

軟件的生命性

　　軟件是有生命的，這可能是老調(diào)重彈了，但是因為它事關(guān)分層架構(gòu)的原由，反復(fù)強調(diào)都不過分。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　現(xiàn)在Evans　DDD概念很火，因為它將著名的PoEAA進行了具化，實現(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為例子，解釋兩個目標的區(qū)別，并且表明
微軟是如何在案例中更好地實現(xiàn)支持后者。這篇文章幫助哪些.NET平臺上有域設(shè)計知識的人實現(xiàn)更好地提高。

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

參考文章：

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

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

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

數(shù)據(jù)庫時代的終結(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 萬博閱讀(261) | 評論 (0) | 編輯收藏

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

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——4
     摘要: 4：數(shù)據(jù)和處理程序要盡可能靠近  閱讀全文
posted @ 2007-04-16 23:56 萬博閱讀(195) | 評論 (0) | 編輯收藏

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——3
     摘要: 3：區(qū)分邏輯層（layer）和物理層（tier）  閱讀全文
posted @ 2007-04-16 20:59 萬博閱讀(248) | 評論 (0) | 編輯收藏

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——2
     摘要: 2：跨越組件邊界優(yōu)先采用松耦合  閱讀全文
posted @ 2007-04-14 19:34 萬博閱讀(305) | 評論 (0) | 編輯收藏

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——1
     摘要: 1：優(yōu)先采用組件作為開發(fā)、部署和重用的核心元素  閱讀全文
posted @ 2007-04-14 19:28 萬博閱讀(158) | 評論 (0) | 編輯收藏

Powered by:
BlogJava
Copyright © 萬博

Javascript的IE和Firefox兼容性匯編

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

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

AOP的基本概念

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

當前Java軟件開發(fā)中幾種認識誤區(qū)

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

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——4

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——3

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——2

構(gòu)建高效的企業(yè)級Java應(yīng)用系列（一）架構(gòu)篇——1

導(dǎo)航

統(tǒng)計

留言簿(1)

隨筆檔案(13)

搜索

積分與排名

最新隨筆

最新評論

閱讀排行榜

評論排行榜