2007年6月28日
摘要: 以下以 IE 代替 Internet Explorer，以 MF 代替 Mozzila Firefox
1. document.form.item 問題
(1)現有問題：
現有代碼中存在許多 document.formName.item("itemName") 這樣的語...
閱讀全文
OSCache是當前運用最廣的緩存方案。其主被用的最廣泛功能是緩存頁面，這里主要是用其緩存文件對象。
運用OScache的步驟：
1.取得oscache.jar 文件放到 /WEB-INF/lib 或相應類庫目錄 目錄中。
2.oscache.jar依賴commons-collections.jar包。如果你的jdk版本為1.3,
建議在lib中加入Apache Common Lib 的commons-collections.jar包。
如jdk是1.4以上則不必要。
3.src根目錄或發布環境的/WEB-INF/classes 目錄下放入oscache.properties。
cache.memory
值為true 或 false ，默認為在內存中作緩存，
如設置為false，那cache只能緩存到數據庫或硬盤中，那cache還有什么意義：）
cache.capacity
緩存元素個數
cache.persistence.class
持久化緩存類，如此類打開，則必須設置cache.path信息
cache.cluster 相關
為集群設置信息。
如cache.cluster.multicast.ip為廣播IP地址
cache.cluster.properties為集群屬性
cache.path
硬盤持久化時存放文件的目錄。如果目錄不存在OSCache會自動創建。
Windows系統：c:\\myapp\\cache。其它：/opt/myapp/cache
cache.persistence.overflow.only*
是否只有當指定的內存緩存已經滿時才進行持久化。推薦使用true，flase是為向后兼容。
cache.unlimited.disk
硬盤緩存是否有限制。缺省為cache.capacity指定的值
運用：
com.opensymphony.oscache.general.GeneralCacheAdministrator
GeneralCacheAdministrator主要對實現持久化對象的保存以及取出的相關的操作。
Object getFromCache（String key） //根據key獲取緩存對象
Object getFromCache（String key , int refreshInterval）//refreshInterval時間內，根據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 * 把文件用響應流寫出
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
首先了解一下Singleton模式通常的兩種表現形式：
第一種形式：
public class Singleton {
private Singleton(){}
//在自己內部定義自己一個實例，是不是很奇怪？
//注意這是private 只供內部調用
private static Singleton instance = new Singleton();
//這里提供了一個供外部訪問本class的靜態方法，可以直接訪問
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()可以訪問單態類。
上面第二中形式就是lazy initialization，也就是說第一次調用時初始Singleton，以后就不用再生成了。
注意到lazy initialization形式中的synchronized，這個synchronized很重要，如果沒有synchronized，那么使用getInstance()是有可能得到多個Singleton實例。
那么為什么只有使用synchronized關鍵字才可以達到單態的目的呢？synchronized到底有什么含義呢？
synchronized 關鍵字，它包括兩種用法：synchronized 方法和 synchronized 塊。
1. synchronized 方法：通過在方法聲明中加入 synchronized關鍵字來聲明 synchronized 方法。如：
public synchronized void accessVal(int newVal);
synchronized 方法控制對類成員變量的訪問：
每個類實例對應一把鎖，每個 synchronized 方法都必須獲得調用該方法的類實例的鎖方能執行，否則所屬線程阻塞，方法一旦執行，就獨占該鎖，直到從該方法返回時才將鎖釋放，此后被阻塞的線程方能獲得該鎖，重新進入可執行狀態。這種機制確保了同一時刻對于每一個類實例，其所有聲明為 synchronized 的成員函數中至多只有一個處于可執行狀態（因為至多只有一個能夠獲得該類實例對應的鎖），從而有效避免了類成員變量的訪問沖突（只要所有可能訪問類成員變量的方法均被聲明為 synchronized）。
在 Java 中，不光是類實例，每一個類也對應一把鎖，這樣我們也可將類的靜態成員函數聲明為 synchronized ，以控制其對類的靜態成員變量的訪問。
synchronized 方法的缺陷：若將一個大的方法聲明為synchronized 將會大大影響效率，典型地，若將線程類的方法 run() 聲明為 synchronized ，由于在線程的整個生命期內它一直在運行，因此將導致它對本類任何 synchronized 方法的調用都永遠不會成功。當然我們可以通過將訪問類成員變量的代碼放到專門的方法中，將其聲明為 synchronized ，并在主方法中調用來解決這一問題，但是 Java 為我們提供了更好的解決辦法，那就是 synchronized 塊。
2. synchronized 塊：通過 synchronized關鍵字來聲明synchronized 塊。語法如下：
synchronized(syncObject) {
//允許訪問控制的代碼
}
synchronized 塊是這樣一個代碼塊，其中的代碼必須獲得對象 syncObject （如前所述，可以是類實例或類）的鎖方能執行，具體機制同前所述。由于可以針對任意代碼塊，且可任意指定上鎖的對象，故靈活性較高。
對synchronized(this)的一些理解
一、當兩個并發線程訪問同一個對象object中的這個synchronized(this)同步代碼塊時，一個時間內只能有一個線程得到執行。另一個線程必須等待當前線程執行完這個代碼塊以后才能執行該代碼塊。
二、然而，當一個線程訪問object的一個synchronized(this)同步代碼塊時，另一個線程仍然可以訪問該object中的非synchronized(this)同步代碼塊。
三、尤其關鍵的是，當一個線程訪問object的一個synchronized(this)同步代碼塊時，其他線程對object中所有其它synchronized(this)同步代碼塊的訪問將被阻塞。
四、第三個例子同樣適用其它同步代碼塊。也就是說，當一個線程訪問object的一個synchronized(this)同步代碼塊時，它就獲得了這個object的對象鎖。結果，其它線程對該object對象所有同步代碼部分的訪問都被暫時阻塞。
五、以上規則對其它對象鎖同樣適用
-
切面（Aspect）： 一個關注點的模塊化，這個關注點可能會橫切多個對象。事務管理是J2EE應用中一個關于橫切關注點的很好的例子。 在Spring AOP中，切面可以使用通用類（基于模式的風格） 或者在普通類中以 @Aspect 注解（@AspectJ風格）來實現。
-
連接點（Joinpoint）： 在程序執行過程中某個特定的點，比如某方法調用的時候或者處理異常的時候。 在Spring AOP中，一個連接點 總是 代表一個方法的執行。 通過聲明一個org.aspectj.lang.JoinPoint類型的參數可以使通知（Advice）的主體部分獲得連接點信息。
-
通知（Advice）： 在切面的某個特定的連接點（Joinpoint）上執行的動作。通知有各種類型，其中包括“around”、“before”和“after”等通知。 通知的類型將在后面部分進行討論。許多AOP框架，包括Spring，都是以攔截器做通知模型， 并維護一個以連接點為中心的攔截器鏈。
-
切入點（Pointcut）： 匹配連接點（Joinpoint）的斷言。通知和一個切入點表達式關聯，并在滿足這個切入點的連接點上運行（例如，當執行某個特定名稱的方法時）。 切入點表達式如何和連接點匹配是AOP的核心：Spring缺省使用AspectJ切入點語法。
-
引入（Introduction）： （也被稱為內部類型聲明（inter-type declaration））。聲明額外的方法或者某個類型的字段。 Spring允許引入新的接口（以及一個對應的實現）到任何被代理的對象。 例如，你可以使用一個引入來使bean實現 IsModified 接口，以便簡化緩存機制。
-
目標對象（Target Object）： 被一個或者多個切面（aspect）所通知（advise）的對象。也有人把它叫做 被通知（advised） 對象。 既然Spring AOP是通過運行時代理實現的，這個對象永遠是一個 被代理（proxied） 對象。
-
AOP代理（AOP Proxy）： AOP框架創建的對象，用來實現切面契約（aspect contract）（包括通知方法執行等功能）。 在Spring中，AOP代理可以是JDK動態代理或者CGLIB代理。
-
織入（Weaving）： 把切面（aspect）連接到其它的應用程序類型或者對象上，并創建一個被通知（advised）的對象。 這些可以在編譯時（例如使用AspectJ編譯器），類加載時和運行時完成。 Spring和其他純Java AOP框架一樣，在運行時完成織入。
通知的類型：
-
前置通知（Before advice）： 在某連接點（join point）之前執行的通知，但這個通知不能阻止連接點前的執行（除非它拋出一個異常）。
-
返回后通知（After returning advice）： 在某連接點（join point）正常完成后執行的通知：例如，一個方法沒有拋出任何異常，正常返回。
-
拋出異常后通知（After throwing advice）： 在方法拋出異常退出時執行的通知。
-
后通知（After (finally) advice）： 當某連接點退出的時候執行的通知（不論是正常返回還是異常退出）。
-
環繞通知（Around Advice）： 包圍一個連接點（join point）的通知，如方法調用。這是最強大的一種通知類型。 環繞通知可以在方法調用前后完成自定義的行為。它也會選擇是否繼續執行連接點或直接返回它們自己的返回值或拋出異常來結束執行。
JAVA四種基本排序,包括冒泡法,插入法,選擇法,SHELL排序法.其中選擇法是冒泡法的改進,SHELL排序法是 插入法的改進.所以從根本上來說可以歸納為兩種不同的排序方法:即:插入法＆冒泡法
一 插入法:遍歷排序集合，每到一個元素時，都要將這個元素與所有它之前的元素遍歷比較一遍，讓符合排序順序的元素挨個移動到當前范圍內它最應該出現的位置。交換是相鄰遍歷移動，雙重循環控制實現.這種排序法屬于地頭蛇類型,在我的地牌上我要把所有的東西按一定的順序規整,過來一個,規整一個.
處理代碼如下:
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;
}
}
}
二冒泡法:比較容易，它的內層循環保證遍歷一次后，集合中最小（大）元素出現在它的正確位置，下一次就是次小元素。。。該方法在集合分布的各種情況下交換移動的次數基本不變，屬于最慢的一種排序。實現也是雙重循環控制。這種排序法屬于過江龍,就是要找到極端,但是過獎龍也有大哥,二哥等,所以他們只能是大哥挑了二哥挑.
處理代碼如下:
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;
三選擇法:該方法只是通過遍歷集合記錄最小（大）元素的位置，一次遍歷完后，再進行交換位置操作，類似冒泡，但在比較過程中，不進行交換操作，只記錄元素位置。一次遍歷只進行一次交換操作。這個對與交換次序比較費時的元素比較適合。這種排序法比冒泡法要城府要深的多,我先記住極端數據,待遍歷數據完了之后,我再處理,不像冒泡法那樣只要比自己極端一點的就要處理,選擇法只處理本身范圍內的最極端數據.
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排序：
它是對插入排序的一種改進，是考慮將集合元素按照一定的基數劃分成組去排序，讓每一組在局部范圍內先排成基本有序，最后在進行一次所有元素的插入排序。
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
越來越多人開始使用Java，但是他們大多數人沒有做好足夠的思想準備(沒有接受OO思想體系相關培訓)，以致不能很好駕馭Java項目，甚至 導致開發后的Java系統性能緩慢甚至經常當機。很多人覺得這是Java復雜導致，其實根本原因在于：我們原先掌握的關于軟件知識(OO方面)不是太貧乏就是不恰當，存在認識上和方法上的誤區。
軟件的生命性
軟件是有生命的，這可能是老調重彈了，但是因為它事關分層架構的原由，反復強調都不過分。
一個有生命的軟件首先必須有一個靈活可擴展的基礎架構，其次才是完整的功能。
目前很多人對軟件的思想還是焦點落在后者：完整的功能，覺得一個軟件功能越完整越好，其實關鍵還是架構的靈活性，就是前者，基礎架構好，功能添加只是時間和工作量問題，但是如果架構不好，功能再完整，也不可能包括未來所有功能，軟件是有生命的，在未來成長時，更多功能需要加入，但是因為基礎架構不靈活不能方便加入，死路一條。
正因為普通人對軟件存在短視誤區，對功能追求高于基礎架構，很多吃了虧的老程序員就此離開軟件行業，帶走寶貴的失敗經驗，新的盲目的年輕程序員還是使用老的思維往前沖。其實很多國外免費開源框架如ofbiz compiere和slide也存在這方面陷阱，貌似非常符合胃口，其實類似國內那些幾百元的盜版軟件，擴展性以及持續發展性嚴重不足。
那么選擇現在一些流行的框架如Hibernate、Spring/Jdonframework是否就表示基礎架構打好了呢？其實還不盡然，關鍵還是取決于你如何使用這些框架來搭建你的業務系統。
存儲過程和復雜SQL語句的陷阱
首先談談存儲過程使用的誤區，使用存儲過程架構的人以為可以解決性能問題，其實它正是導致性能問題的罪魁禍首之一，打個比喻：如果一個人頻臨死亡，打一針可以讓其延長半年，但是打了這針，其他所有醫療方案就全部失效，請問你會使用這種短視方案嗎？
為什么這樣說呢？如果存儲過程都封裝了業務過程，那么運行負載都集中在數據庫端，要中間J2EE應用服務器干什么？要中間服務器的分布式計算和集群能力做什么？只能回到過去集中式數據庫主機時代。現在軟件都是面向互聯網的，不象過去那樣局限在一個小局域網，多用戶并發訪問量都是無法確定和衡量，依靠一臺數據庫主機顯然是不能夠承受這樣惡劣的用戶訪問環境的。（當然搞數據庫集群也只是五十步和百步的區別）。
從分層角度來看，現在三層架構：表現層、業務層和持久層，三個層次應該分割明顯，職責分明：持久層職責持久化保存業務模型對象，業務層對持久層的調用只是幫助我們激活曾經委托其保管的對象，所以，不能因為持久層是保管者，我們就以其為核心圍繞其編程，除了要求其歸還模型對象外，還要求其做其做復雜的業務組合。打個比喻：你在火車站將水果和盤子兩個對象委托保管處保管，過了兩天來取時，你還要求保管處將水果去皮切成塊，放在盤子里，做成水果盤給你，合理嗎？
上面是談過分依賴持久層的一個現象，還有一個正好相反現象，持久層散發出來，開始擠占業務層，腐蝕業務層，整個業務層到處看見的是數據表的影子（包括數據表的字段），而不是業務對象。這樣程序員應該多看看OO經典PoEAA。PoEAA 認為除了持久層，不應該在其他地方看到數據表或表字段名。
當然適量使用存儲過程，使用數據庫優點也是允許的。按照Evans DDD理論，可以將SQL語句和存儲過程作為規則Specification一部分。
Hibernate等ORM問題
現在使用Hibernate人也不少，但是他們發現Hibernate性能緩慢，所以尋求解決方案，其實并不是 Hibernate性能緩慢，而是我們使用方式發生錯誤：
“最近本人正搞一個項目，項目中我們用到了struts1.2+hibernate3, 由于關系復雜表和表之間的關系很多，在很多地方把lazy都設置false，所以導致數據一加載很慢，而且查詢一條數據更是非常的慢。”
Hibernate是一個基于對象模型持久化的技術，因此，關鍵是我們需要設計出高質量的對象模型，遵循DDD領域建模原則，減少降低關聯，通過分層等有效辦法處理關聯。如果采取圍繞數據表進行設計編程，加上表之間關系復雜（沒有科學方法處理、偵察或減少這些關系），必然導致 系統運行緩慢，其實同樣問題也適用于當初對EJB的實體Bean的CMP抱怨上，實體Bean是Domain Model持久化，如果不首先設計Domain Model，而是設計數據表，和持久化工具設計目標背道而馳，能不出問題嗎？關于這個問題N多年就在Jdon爭論過。
這里同樣延伸出另外一個問題：數據庫設計問題，數據庫是否需要在項目開始設計？
如果我們進行數據庫設計，那么就產生了一系列問題：當我們使用Hibernate實現持久保存時，必須考慮事先設計好的數據庫表結構以及他們的關系如何和業務對象實現映射，這實際上是非常難實現的，這也是很多人覺得使用ORM框架棘手根本原因所在。
當然，也有腦力相當發達的人可以 實現，但是這種圍繞數據庫實現映射的結果必然扭曲業務對象，這類似于兩個板塊（數據表和業務對象）相撞，必然產生地震，地震的結果是兩敗俱傷， 軟的一方吃虧，業務對象是代碼，相當于數據表結構，屬于軟的一方，最后導致業務對象變成數據傳輸對象DTO, DTO滿天飛，性能和維護問題隨之而來。
領域建模解決了上述眾多不協調問題，特別是ORM痛苦使用問題，關于ORM/Hibernate使用還是那句老話：如果你不掌握領域建模方法，那么就不要用Hibernate，對于這個層次的你：也許No ORM 更是一個簡單之道： No ORM: The simplest solution
http://www.theserverside.com/blogs/thread.tss?thread_id=41715
Spring分層矛盾問題
Spring是以挑戰EJB面貌出現，其本身擁有的強大組件定制功能是優點，但是存在實戰的一些問題，Spring作為業務層框架，不支持業務層Session 功能。
具體舉例如下：當我們實現購物車之類業務功能時，需要將購物場合保存到Session中，由于業務層沒有方便的Session支持，我們只得將購物車保存到 HttpSession，而HttpSession只有通過HttpRequest才能獲得，再因為在Spring業務層容器中是無法訪問到HttpRequest這個對象的，所以， 最后我們只能將“購物車保存到HttpSession”這個功能放在表現層中實現，而這個功能明顯應該屬于業務層功能，這就導致我們的Java項目層次混亂，維護性差。 違背了使用Spring和分層架構最初目的。
相關案例：請教一個在完整提交前臨時保存的問題:
http://www.jdon.com/jive/article.jsp?forum=46&thread=28429
領域驅動設計DDD
現在回到我們討論的重點上來，分層架構是我們使用Java的根本原因之一，域建模專家Eric Evans在他的“Domain Model Design”一書中開篇首先強調的是分層架構，整個DDD理論實際是告訴我們如何使用模型對象oo技術和分層架構來設計實現一個Java項目。
我們現在很多人知道Java項目基本有三層：表現層 業務層和持久層，當我們執著于討論各層框架如何選擇之時，實際上我們真正的項目開發工作還沒有開始， 就是我們選定了某種框架的組合（如Struts+Spring+Hibernate或Struts+EJB或Struts+JdonFramework），我們還沒有意識到業務層工作還需要大量工作，DDD提供了在業務層中再劃分新的層次思想，如領域層和服務層，甚至再細分為作業層、能力層、策略層等等。通過層次細化方式達到復雜軟件的松耦合。DDD提供了如何細分層次的方式
當我們將精力花費在架構技術層面的討論和研究上時，我們可能忘記以何種依據選擇這些架構技術？選擇標準是什么？領域驅動設計DDD 回答了這樣的問題，DDD會告訴你如果一個框架不能協助你實現分層架構，那就拋棄它，同時，DDD也指出選擇框架的考慮目的，使得你不會 人云亦云，陷入復雜的技術細節迷霧中，迷失了架構選擇的根本方向。
現在也有些人誤以為DDD是一種新的理論，其實DDD和設計模式一樣，不是一種新的理論，而是實戰經驗的總結，它將前人 使用面向模型設計的方法經驗提煉出來，供后來者學習，以便迅速找到駕馭我們軟件項目的根本之道。
現在Evans DDD概念很火，因為它將著名的PoEAA進行了具化，實現了PoEAA可操作性，這也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微軟的.NET架構和Evans DDD比較的文章：http://weblogs.asp.net/pgielens/archive/2006/08/08/Organizing-Domain-Logic.aspx，這篇文章比較了微軟的三層服務應用架構[Microsoft TLSA]和Evans DDD的架構， 使用Microsoft .NET Pet Shop 4為例子，解釋兩個目標的區別，并且表明
微軟是如何在案例中更好地實現支持后者。這篇文章幫助哪些.NET平臺上有域設計知識的人實現更好地提高。
另外一本關于.NET的DDD書籍也已經出版，這些都說明Evans DDD這把火已經燒到.NET領域，當然DDD在Java領域生根開花多年，Evans的DDD書籍就是以Java為例子的，筆者板橋里人也率先在2005年推出DDD框架JdonFramework 1.3版本，這些都說明，Java在整個軟件業先進思想的實踐上總是領先一步。
參考文章：
面向對象與領域建模
實戰DDD(Domain-Driven Design領域驅動設計)
領域模型驅動設計(DDD)之模型提煉
數據庫時代的終結
Java EE/J2EE面向對象編程之道
更多關于DDD討論
更多關于EJB3討論
更多關于IOC討論
更多關于AOP討論
更多關于Spring討論
更多關于JdonFramework討論
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1630894