前言
N層的應用軟件系統，由於其眾多的優點，已經成為典型的軟件系統架構，也已經為廣大開發人員所熟知。在一個典型的三層應用軟件系統中，應用系統通常被劃分成以下三個層次：數據庫層、應用服務層和用戶界面層。如下圖所示：
其中，應用服務層集中了系統的業務邏輯的處理，因此，可以說是應用軟件系統中的核心部分。軟件系統的健壯性、靈活性、可重用性、可升級性和可維護性，在很大程度上取決於應用服務層的設計。因此，如何構建一個良好架構的應用服務層，是應用軟件開發者需要著重解決的問題。
為了使應用服務層的設計達到最好的效果，我們通常還需要對應用服務層作進一步的職能分析和層次細分。很多開發者在構建應用服務層的時候，把數據庫操縱、業務邏輯處理甚至界面顯示夾雜在一起，或者，把業務邏輯處理等同於數據庫操縱，等等，這些，都是有缺陷的做法。本文，就在這個方面進行設計時可采用的方案進行一些探討。
為了使討論更具有針對性，本文會討論一些比較流行的系統架構，例如J2EE架構，以及JDO。在微軟的.Net平台上，將以Websharp中間件為例。Websharp中間件是筆者開發的一個構建在微軟.Net平台之上的一個中間件系統，也是實現文章所述的系統架構的支撐系統。選用這些架構做例子，也是因為.Net出現的時間比較短，目前在這個平台上沒有成熟統一的架構，而J2EE是目前最成熟的構建企業應用的平台。
自本人的《 利用.Net框架開發應用系統》和《 實戰揭秘：開發.Net平台應用系統框架》兩篇文章發表以來，收到很多反饋和來信，提出了很多問題。因為時間的關系，不能一一回復，因此，也借本文給大家一些解答。需要說明的是，原來的Jobsinfo現在已經做了升級，名稱變更為Websharp。
設計的原則和評判標准
同軟件工程的原則一樣，應用服務層的設計，必須遵循的最重要的原則就是高內聚和低耦合。軟件分層的本來目的，就是提高軟件的可維護性和可重用性，而高內聚和低耦合正是達成這一目標必須遵循的原則。盡量降低系統各個部分之間的耦合度，是應用服務層設計中需要重點考慮的問題。
內聚和耦合，包含了橫向和縱向的關系。功能內聚和數據耦合，是我們需要達成的目標。橫向的內聚和耦合，通常體現在系統的各個模塊、類之間的關系，而縱向的耦合，體現在系統的各個層次之間的關系。
系統的框架，通常包含了一系列規范、約定和支撐類庫、服務。
對於如何判斷一個軟件的系統框架的優劣，筆者認為，可以從以下幾個方面來評判：
◆ 系統的內聚和耦合度
這是保證一個系統的架構是否符合軟件工程原則的首要標准。
◆ 層次的清晰和簡潔性
系統每個部分完成功能和目標必須是明確的，同樣的功能，應該只在一個地方實現。如果某個功能可以在系統不同的地方實現，那麼，將會給後來的開發和維護帶來問題。
系統應該簡單明了，過於復雜的系統架構，會帶來不必要的成本和維護難度。在盡可能的情況下，一個部分應該完成一個單獨並且完整的功能。
◆ 易於實現性
如果系統架構的實現非常困難，甚至超出團隊現有的技術能力，那麼，團隊不得不花很多的精力用於架構的開發，這對於整個項目來說，可能會得不償失。簡單就是美。
◆ 可升級和可擴充性
一個系統框架，受設計時技術條件的限制，或者設計者本人對系統認識的局限，可能不會考慮到今後所有的變化。但是，系統必須為將來可能的變化做好准備，能夠在今後，在目前已有的基礎上進行演進，但不會影響原有的應用。接口技術，是在這個方面普遍應用的技巧。
◆ 是否有利於團隊合作開發
一個好的系統架構，不僅僅只是從技術的角度來看，而且，它還應該適用於團隊開發模型，可以方便一個開發團隊中各個不同角色的互相協作。例如，將Web頁面和業務邏輯組件分開，可是使頁面設計人員和程序員的工作分開來同步進行而不會互相影響。
◆ 性能
性能對於軟件系統來說是很重要的，但是，有的時候，為了能讓系統得到更大的靈活性，可能不得不在性能和其他方面取得平衡。另外一個方面，由於硬件技術的飛速發展和價格的下降，性能的問題往往可以通過使用使用更好的硬件來獲得提升。
應用服務層的內容
應用服務層，通常也被稱為業務邏輯層，因為這一層，是應用軟件系統業務邏輯處理集中的部分。然而，我將這一層稱為應用服務層，而不稱業務邏輯層，因為，這一層需要處理的不僅僅是業務邏輯，還包含了其他方面的內容。
從完整的角度來說，應用服務層需要處理以下內容：
◆ 數據的表示方式
數據，是軟件處理的對象。從某種程度上來說，"軟件，就是數據結構加算法"的說法，是有一定意義的。在面向對象的系統中，數據是用類來表示的，代表了現實世界實體對象在軟件系統中的抽象。考慮所謂的MVC模式，這個部分的類屬於M--實體類的范疇。由於應用軟件通常會使用數據庫，數據庫中的數據，可以看成是對象的持久化保存。由於數據庫一般是關系型的，因此，這個部分，還需要考慮類（對象）同關系型數據的映射，即通常所說的O-R
MAP問題。
◆ 數據的存取方式
如同上述所說，軟件系統處理的實體對象數據需要持久化保存數據庫中，因此，我們必須處理系統同數據庫的交互，以及數據的存取和轉換方式的問題。
◆ 業務邏輯的組織方式
在面向對象的系統中，業務邏輯表現為對象之間的交互。有了上述的實體對象，以及對象的保存策略，就可以將這些對象組合起來，編寫我們的業務邏輯處理程序。在業務邏輯的處理中，必須保證處理的正確性和完整性，這將會涉及到事務處理。通常，我們也會把業務邏輯封裝成組件的形式，以得到最大的可重用性。
◆ 業務服務的提供方式
在我們完成系統的功能後，如何向客戶提供服務，是我們需要考慮的問題。這裡的客戶，不僅僅是指軟件的使用者，也包括調用的界面、其他程序等。例如，在一個基於Web的ASP.Net或JSP系統中，業務邏輯功能的客戶便是這些ASP.Net頁面或JSP頁面。業務邏輯組件應該通過什麼方式，直接的，或間接的，向這些客戶提供服務,是這一層需要完成的任務。
◆ 層的部署和層間交互
對於一個多層的應用軟件系統來說，尤其是大型的應用軟件系統，通常需要把不同的部分部署在不同的邏輯或物理設備上。特別是一些基於Web的應用軟件系統，其部署工作將涉及到Web服務器、組件服務器、數據庫服務器等不同的服務設備。在進行應用軟件架構的設計的時候，必須考慮各種不同的部署方案。
綜上所述，一個完整的基於Web的應用軟件系統，其架構可以用下圖來表示（Websharp推薦的應用軟件系統架構）：
對於以上各個方面來說，每個問題都可以有很多種策略和方案，但是，在一個系統中，應該盡可能的統一這些策略和方案。也就是說，在一個系統，或者一個項目中，應該統一每個解決每個問題所采用的方法。軟件的開發方法是靈活的，可以用不同的方法解決相同的問題，這會誘使開發人員采用他們認為能夠表現自己的方法，但是，從整個系統來看，這將會是災難性的。我們應該盡可能統一，就是，采用統一的數據表示方式、統一的數據存取方式、統一的業務邏輯處理方式等。
下面，將就這些部分的設計策略和可用方案進行一些比較詳細的論述。
數據實體的表示
應用軟件系統，從本質上來說，是計算機對現實世界的模擬。現實世界中的實體對象，在軟件系統中，表現為需要處理的數據。在面向對象的系統中，這是通過"類"和"對象"來表示的。
參考著名的"MVC"模式，類可以分成實體類（M）、控制類（C）、和邊界類（V），分別代表了實體對象、控制和界面顯示。系統中需要處理的數據，在面向對象的系統中，屬於實體類部分。
在考慮數據實體層的設計策略的時候，需要把握以下要點：
◆ 一致的數據表示方式。在一個系統中，數據的表示方式必須盡可能統一，同時，在處理單個數據和多個數據的時候，處理方式盡可能一致。
◆ 因為數據通常是需要存儲到數據庫中，因此，良好的映射方法是必需的。
◆ 處理好對象的粒度，即所謂的粗粒度對象、細粒度對象。
一般例子
考慮一個現實的例子，一個倉庫中的產品（Product），在系統中可以使用如下定義：
public class Product{public string Name; //名稱
public decimal Price;//價格
public int Count;//數量
}
可以按照如下方法使用Product類：
Product p=new Product();
//……處理Product
這是一個包含了三個屬性的Product類的定義。為了便於說明，在這裡，我們盡量將問題簡化了。
又例如，一張入庫單可以使用如下定義：
public class Form{public string ID; //入庫單編號
public DateTime AddTime; //入庫時間
public FormDetail[] FormDetails; //入庫單明細
}
public class FormDetail
{
public Product InProduct; //入庫產品
public int Count; //入庫數量
}
對於處理單個對象，通常采用上述的方法，但是，當我們需要處理相同類的一組對象，也就是處理一個對象集合的時候，就會有一些小小的麻煩。
如前所述，我們希望在處理單個對象和對象集合的時候，處理的方式盡量統一，這對於軟件開發的意義是很大的。常用的處理對象集合的方法有：
◆數組表示的方法
例如，上面的例子中當一張入庫單包含多條入庫單明細的時候采的方法。為了靈活性，也可以使用容器來，如Java中的Vector或C#的ArrayList(C#)。只是，在處理對象的時候，需要一個類型轉換的操作。這個問題，在支持泛型的語言中不會存在，如使用C++的標准庫的容器類。
◆ObjectCollection方法。這個方法同上面的方法類似，不同之處在於，為每個實體類設計一個Collection類。例如，可以為FormDetail設計一個FormDetailsCollection類(C#)：
public class FormDetailsCollection: ArrayList
{
public void Add(FormDetail detail)
{
base.Add(detail);
}
public new FormDetail this[int nIndex]
{
get{ return (FormDetail)base[nIndex];
}
}
}
這麼做的好處在於，在操作集合中的對象時，不必進行類型轉換的操作。
◆數據集的表示方法。
采用這種方法，通常是直接把從數據庫查詢中獲取的數據集(Recordset)作為數據處理對象。這種方法在ASP應用程序中是非常常見的做法。這種做法簡單，初學者很容易掌握，但是弊病也很多。
EJB的方法
在J2EE體系中，對實體對象的處理的典型方法是Entity Bean。J2EE中使用Entity Bean來表示數據，以及封裝數據的持久化儲存（同數據庫的交互）。由於Entity
Bean比較消耗資源，而且采用的是遠程調用的方式來訪問，因此，在需要傳遞大量數據，或者在不同的層次之間傳遞數據的時候，往往還會采用一些諸如"值對象"(Value
Object)的設計模式來提升性能。關於J2EE中的設計模式的更多內容，讀者可以參考《J2EE核心模式》一書。
JDO的方法
相對於J2EE這個昂貴的方法來說，JDO提供了一個相對"輕量級"的方案。在JDO中，你可以采用一般的做法，編寫實體類，然後，通過一些強化器對這些類進行強化，以使其符合JDO的規范，最後，你可以通過PersistenceManager來實現對象的持久化儲存。
無論是EJB還是JDO，在同數據庫進行映射的時候，都選用了XML配置文件的方式。這是一種靈活的方式。由於XML強大的表達能力，我們可以很好的用它來描述代碼中的實體類和數據庫之間的映射關系，並且，不用在代碼中進行硬編碼，這樣，在情況發生變化的時候，有可能只需要修改配置文件，而不用去修改程序的源代碼。關於EJB和JDO的配置文件的更多的信息，各位可以參考相關的文檔，這裡不再贅述了。
然而，使用XML配置文件的方式並不是唯一的方法，在微軟提供的一些案例中，如Duwamish示例，就沒有采用這種方式。至於開發人員在開發過程中具體采用哪種方式，是需要根據具體情況進行權衡和取捨的。
Websharp的方法
Websharp在數據的表現上，充分利用了.Net Framework類庫中DataSet的功能，設計了一個EntityData類。這個類繼承了DataSet，並增加了一些屬性和方法。同樣的，同數據庫的映射關系，也是采用XML配置文件的方式。
在實際的應用中，要獲取一個實體對象，可以通過如下方式取得：
EntityData Customer=EntityDataManager. GetEmptyEntity("Customer");
然後，可以通過如下方式來訪問這個對象的屬性：
string CustomerID=Customer["CustomerID"]
可以看到，這種方式同傳統的方式有點不同。在這種方式下，數據的表現形式只有一個，那就是EntityData。其好處是明顯的，不用為每個實體都單獨編寫一個類，能夠大大減少代碼的編寫量。其缺點也很明顯，那就是不能利用編譯器類型檢測的功能，如果在調用對象的屬性的時候，寫錯了屬性的名稱，就可能出錯，但是，這個問題可以通過工具來解決。
關於這個方面更加詳細的信息，可以參見拙文：
《利用.Net框架開發應用系統 》
《 實戰揭秘：開發.Net平台應用系統框架》
數據的存取方式
數據存取的目的，是持久化保存對象，以備後來的使用，如查詢、修改、統計分析等。存取的對象，可以是數據庫、普通文件、XML甚至其他任何方式，只要保證數據能夠長久保存，並且，不會受斷電、系統重起等因素的影響。在這個部分，最理想的狀況，自然是能夠支持除了數據庫以外的各種類型的存取方式，或者，至少留有接口，能夠比較方便的擴充。
因為數據庫是最常用，也是最有效的數據存儲方法，因此，支持數據庫存儲是最首先必須支持的。在不同的平台下，有不同的數據庫訪問的手段。例如，在Java平台下，有JDBC，在Windows平台下，可以使用ADO、ADO.Net等。但是，這些手段還比較接近底層，在實際操縱數據庫的時候，需要編寫大量的代碼，並且，我們還需要通過手工的方式來完成將程序中的面向對象的數據存儲到關系型數據庫的工作。這麼做，自然編程的效率不高，並且非常容易出錯。但是，不可否認，這也是一種可以選用的方式。
從另外一個方面來看，由於我們前面已經解決了數據的映射問題，因此，在數據的存取方面是非常有規律的，我們完全可以讓這個工作通過框架來執行。這樣，我們一方面可以簡化很多同數據庫交互方面的代碼編寫工作量，能夠減少出現Bug的幾率，另一方面，由於框架封裝了不同數據庫之間的差異，使得我們在編寫程序的時候，不用考慮不同數據庫之間的差異，而將這個工作交給框架去做，實現軟件的後台數據庫無關性。
在這個部分，以下兩個部分的類會顯得特別重要：
◆對象--關系映射的分析類，能夠通過既定的方案完成對象--關系的映射，確定數據存取方案
◆數據庫操縱類：根據映射關系，將數據准確的存儲到數據庫中，並且封裝不同數據庫之間的差異。
這個部分的操作過程，可以用圖大概的表示如下：
在J2EE中，這個部分比較典型的就是EntityBean中的CMP。由於在BMP中，同數據庫的交互部分需要通過手工編寫代碼的方式來實現，因此，很難享受到容器帶來的便利，只是由於EJB2.0以前的標准，CMP的功能，包括映射能力、實體關系模式等方面的功能比較弱，所以，在很多時候，我們不得不使用BMP。現在，EJB2.0，在這個方面的功能已經非常強大了，我們完全可以享受容器帶來的便利，而將大部分精力放在實現更加復雜的業務邏輯方面了。
在JDO中，您同樣可以通過PersistenceManager來實現同樣的目標，例如，您想把一個Customer對象保存到數據庫中，可以采用類似於下面的代碼：
Customer customer=new Customer(……);
PersistenceManager PM=PMFactory.initialize(……);
Pm.persist(customer);
代碼同樣非常簡明和直觀，沒有一大堆數據庫操縱的代碼，也不容易發生差錯。
Websharp的方案
Webshap為數據存取的類定義了IEntityDAO接口，該接口的定義如下：
public interface IEntityDAO
{
void InsertEntity(EntityData entity);
void UpdateEntity(EntityData entity);
void DeleteEntity(EntityData entity);
EntityData FindByPrimaryKey(object KeyValue);
}
對於每一個實體類，可以通過擴展這個接口來實現數據訪問的類。但是，由於這個接口沒有提供任何實現方法，因此，到具體每個實現類的時候，如果是直接擴展自這個接口，實現的代碼還必須手工填寫。為了提高開發效率，減少代碼編寫量和出現Bug的可能性，框架提供了AbstractSingleTableDAO和AbstractMultiTableDAO.cs類，這兩個類擴展自IEntityDAO，分別實現了針對單個數據庫表和多個數據庫表的數據庫訪問方法，並且，實現了IDisposable接口。這樣，我們在實際編寫代碼的時候，只需要繼承自這兩個類就可以了。
例如，Customer類的數據存取類可以定義如下：
public class CustomerEntityDAO:AbstractSingleTableDAO
然後，就可以在代碼中這麼使用：
Customer customer=......
using(CustomerEntityDAO CDO=new CustomerEntityDAO())
{
CDO.UpdateEntity(customer);
}
更加一般的，Wensharp也提供了PersistenceManager類，可以用於將EntityData中的數據存入數據庫。這個類包含了兩個方法：PersistEntity和DeleteEntity。如果不想為某個實體類編寫專門的DAO類，那麼，也可以使用這個類來操縱實體對象。不過，目前，只支持映射成單個表的對象的自動存貯。下面是一個例子：
PersistenceManager pm=PersistenceManager.Initial();
pm. PersistEntity(entity);
為了封裝不同數據庫的操作，統一的數據庫訪問接口是必須的。關於編寫通用數據庫訪問類的內容，可以參見拙作：《 使用設計模式構建通用數據庫訪問類》。
在這個部分，另外需要注意的是，為了保證數據存儲的完整性，應當考慮事務處理的功能。J2EE、JDO和Websharp都支持在數據存儲的時候使用事務處理。
業務邏輯的處理
有了上面的工作，我們就可以把這些對象組合起來，編寫我們的業務邏輯。在面向對象的系統中，業務邏輯表現為對象之間的交互。在一些簡單的系統中，沒有復雜的業務邏輯，只是一些數據的維護工作，那麼，有了上面兩個部分的工作，我們實際上可能已經忘成了大部分的工作。
在這個部分，由於不同系統之間業務邏輯千差萬別，基本上沒有辦法提供統一的模式。但是，應當注意的是，在同一個系統中，采用基本一致的策略是非常必要的，這有助於消除項目內部的不一致性，使項目更加可控。甚至於，這些策略可以擴展成公司部分、甚至所有項目的策略。
值得指出的是，很多人在這個部分操縱數據庫，把業務邏輯處理等同於數據庫操作，這是不可取的。在業務邏輯處理中，處理的應該是對象，而不是直接同數據庫打交道，這樣，才能獲得更好的系統結構。
在業務邏輯處理部分，框架提供一些支撐的服務是非常必要的。這其中，最重要的一點就是事務的處理。業務邏輯的處理過程，會涉及到多個對象之間的交互，以及多次同數據庫的交互。為了保證處理過程的完整性，必須使用事務處理的方法。框架必須支持事務處理。
事務處理的功能，基本上有兩種選擇：使用基於數據庫連接的事務、使用外部事物處理服務。
使用基於數據庫連接的事務，事務處理的性能相對比較高，但是，當系統涉及到多個數據庫之間的交互時，基於數據庫連接的事務便無能為力了。而使用專用的事務處理服務，能夠適應更多的情況，並且，有測試表明，隨著數據處理量的上升，兩者之間的性能差異會逐漸減小。
在J2EE中，容器提供了事務處理的能力。在.Net平台上，事務處理是通過Windows COM+服務來提供的。在Websharp中，對COM+服務做了一個簡單的封裝。同時，也能夠使用基於數據庫連接的事務。
下面是一個簡單的例子，表示了一張入庫單入庫的過程，在這個過程中，需要修改入庫單上每種產品的現有庫存量：
public void StoreIntoWarehouse(EntityData insertForm)
{
insertForm.SetCurrentTable("FormDetail");
TransactionManager transManager=new TransactionManager();
ProductEntityDAO productDAO=new ProductEntityDAO(true);
FormEntityDAO formDAO=new FormEntityDAO(true);
try
{
if(insertForm.CurrentTable.Rows.Count>0)
do
{
string productID=insertForm["ProductID"].ToString();
decimal inCount=insertForm.GetDecimal("InCount");
EntityData product=productDAO.FindByPrimaryKey(productID);
product["CurrentCount"]=product.GetDecimal("CurrentCount")+inCount;
transManager.AddMethod(
new TransactionManagedFunction(productDAO.UpdateEntity),product);
}while(insertForm.Next());
transManager.AddMethod(
new TransactionManagedFunction(formDAO.InsertEntity),insertForm);
transManager.ExecuteMethods();
}
catch(Exception ee)
{
throw ee;
}
finally
{
productDAO.Dispose();
insertForm.Dispose();
}
}
業務服務的提供
業務外觀層（Business Facade）的目的，是隔離系統功能的提供者和使用者，更明確地說，是隔離業務邏輯的軟件的用戶界面（可以參見Facade設計模式）。這一層沒有任何需要處理的邏輯，只是作為後台邏輯處理和前端用戶界面的緩沖區，以達到如下目的
◆將用戶界面和系統業務邏輯處理分開，這樣，當業務邏輯發生變化時，不用修改客戶端程序，是一種支持變化的設計方法。
◆使同一個業務邏輯能夠處理不同的客戶端請求。例如，可以將Facade設計成Web Service，這樣，可以同時為傳統的WinForm客戶端程序、Web程序以及其他外部系統提供服務，而使用相同的應用服務層，同時，也可以實現系統的分布式部署。關於如何做到這一點，可以參見本文所附的Demo程序。
◆作為系統不同模塊之間的調用接口。一個系統通常會包含很多模塊，這些模塊相對獨立，又可能互相調用。為了減少各個不同部分之間的耦合度，必須采用一定的設計方法，Facade設計模式就是非常有效的一種，也是業務外觀層的基礎。
◆有利於項目團隊的分工協作。業務外觀層作為一個訪問接口，將界面設計人員和邏輯設計人員分開，使得系統的開發可以實現縱向的分工，不同的開發人員可以關注自己的領域而不會受到干擾。
業務外觀層的代碼框架，在系統分析和設計完成後就可以完成，他需要提供的方法，就相當於在界面設計人員和邏輯設計人員之間簽訂了一個協議，他雖然沒有實現任何邏輯，但是，他的引入，能使系統的開發更加有條理，更加簡明。套用《設計模式》上的一句話，就是，"任何問題，都可以通過引入一個中間層來得到簡化"。
剪裁和取捨
以上四個層次，對於大型的應用軟件系統來說，是非常必要的。但是，對於一些小型的應用軟件系統，如果完全按照以上的層次來做，可能反而會影響工作效率。因此，針對不同的系統，可以對架構進行一定的剪裁。
數據實體層和實體控制層，是每個應用軟件系統所必需的，顯然無法裁減。對於業務邏輯層和業務外觀層，根據實體情況，可以進行如下裁減：
◆如果系統沒有復雜的業務邏輯，而只是一些數據的操作，或者業務邏輯特別少，那麼，可以省略業務邏輯層，而將相關的功能移至實體控制層。
◆如果不考慮多種客戶端的情況，也不考慮分布式部署的問題，系統的模塊又很少，不會產生模塊間緊耦合的情況，那麼，可以不使用業務外觀層，而讓用戶界面程序直接訪問業務功能。
在上面的論述中，對於每個層次，都說明了可以選擇的多種方案，每一種方案都有他的優點和缺點，在具體開發的過程中，需要根據具體情況加以取捨。
系統外的話
應用軟件系統架構，是軟件工程的重要組成部分。設計一個好的框架，其目的很明確，那就是，在目前還沒有"銀彈"之前，盡最大的可能，提高軟件開發的效率和軟件質量，把不必要的工作和容易出錯的工作，交給框架去處理。
應用服務層，在軟件系統中，是一個非常復雜的部分，乍看之下，沒有任何規律可行，給人無從下手的感覺。我們的目標，就是盡量化無規律為有規律，把有規律的東西提取出來，形成規范，從而減少今後的開發工作量。其方法，就是對系統進行合理的分層，這樣，系統的層次清晰了，每個層次完成的功能就比較單一，就意味著每個層次的都相對更有規律可循，這樣，我們就可以把這些有規律的東西交給框架去執行，或者，開發一個輔助工具，來完成這部分的代碼編寫工作。Websharp就提供了這樣一個代碼自動生成的工具。這個工具被設計成Visual
Studio.Net集成開發環境的插件，在實際開發過程中，能夠提供很多便利。這是系統層次清晰帶來的另外一個好處。
對於一個軟件公司來說，統一的系統框架的意義不僅僅在於軟件開發的本身。一個統一的系統框架，也是公司知識管理的重要組成部分。公司如果有一個或有限個數的明確的軟件框架，那麼，這些框架就可以成為凝結公司開發人員經驗、智慧的載體，並且可以在不斷的實踐中加以充實和完善。由於公司的軟件系統的框架比較統一，那麼當某個項目更換或增加開發人員的時候，後來的人也能夠比較容易接手，這對於公司的開發管理是具有非常重要的意義的。
關於系統框架同知識管理的關系的內容，因為不是本文的重點，限於篇幅的關系，所以不再贅述，會另文加以說明。
結語
應用軟件系統的應用服務層是非常復雜的，為了使得系統的結構更加清晰，找出其中規律性的東西，就需要我們對系統做進一步的層次劃分。對於每個層次，都可以有多種設計的策略，每一種策略都不可能做到盡善盡美，這就需要我們在實際中加以取捨。
限於本人的認識和水平，文章中所說觀點和方法或有不當之處，還請大家能夠指教，一起探討。
附：使用Websharp中間件開發的Demo程序一份。(孫亞民/ASPCool)
