通過為你的企業建立一個公共的應用程序結構框架來提高.net應用程序的開發效率。

　　作者：rao chejarla （印度）

　　涉及技術：ado.net、asp.net

　　開發企業應用程序是個復雜的過程。你可以運用microsoft .net技術的許多工具來使這個過程變得更快更容易，但由于.net的復雜性，選擇最直接的方法是很難的。如果沒有明確的標準和方針用來開發應用程序，企業中的每個開發小組就可能在安全、數據庫訪問策略和測試過程上進行重復開發。雖然每個小組都可能在這些領域中開發出有效的方法，但會導致不必要的重復工作。而且在重要的安全性方面，如果每個開發小組都確定各自的安全實現方法，那么應用程序可能變得很容易受到攻擊。

　　如果你在it集團公司工作，這種情況的確很常見。幸運的是，你可以把事情簡單化。雖然企業中開發的每個應用程序都解決一個獨特的商業問題，但你可以將所有的應用程序建立在同樣的底層框架組件上。通過開發標準和公從命名慣例到用來強化應用程序結構的預裝組件的最好方法。共應用程序結構組件，你的開發小組就可以節省時間、確保應用程序是安全的、并改善各小組間的協作。標準的范圍很廣，在本文中，我將探討在企業中實現一個公共應用程序結構框架的最好的方法。我將特別關注三個主要的方面：應用程序安全性、數據庫訪問策略和測試過程。我將講述驗證你的用戶的身份、用四個層來構建你的企業級應用程序、還將講述一下microsoft的兩個新的對象——dataset和datareader——它們是ado.net的一部分，可以幫你分離各個層。

　　運用預裝組件是加強應用程序結構并提供一般服務的一個好方法。因為應用程序結構是個企業級的問題，你現有的企業組織結構中可能并沒有一個小組來承擔這項工作。然而，形成這樣一個小組是很簡單的，你只需要重新編制各個小組，然后分配一些技術很強的人員（已經在你們公司中）來從事應用程序結構方面的工作。

　　你在引進一個公共底層框架應用程序時，各小組可能主要關注商業問題，而不是擔心結構問題。這就使我們對做每個應用程序的開發人員的技術要求并不高。因此，開發進度就會縮短，可以更好地響應市場情況。所有這些因素的結合就會減少開發和維護方面的投資，最終提高你們公司的贏利。然而，你首先需要在三個主要方面建立一個公共底層框架：應用程序安全性、數據庫訪問策略和測試過程。

　　安全是很重要的，你應該從開發的早期階段就控制應用程序結構的這個方面。適當的用戶身份驗證和授權可以保證一個應用程序的安全。在沒有集中的安全組件的時候，每個小組編寫它自己的安全代碼，這是很危險的。一個中心安全策略不僅可以使開發人員避免重復勞動，為企業中所有的應用程序提供同樣級別的保護，還可以創建一個結構，使所有的修改都在一個地方進行，而且不會產生新的安全漏洞。安全結構中首要的一步就是用戶身份驗證。

　　驗證你的用戶身份

　　一個典型的企業需要驗證兩類用戶的身份：內部用戶（雇員）和外部用戶（供應商和客戶）。你的企業應該建立統一的策略來驗證這兩類用戶的身份并對他們授權。

　　在傳統的asp中，如果你不用集成的windows驗證，用戶身份驗證和授權是很難實現的。例如，確定每個用戶身份都經過了驗證并不容易。每個asp頁面都需要代碼來檢驗用戶身份驗證cookie并證明用戶身份得到了確定。在asp.net中，身份驗證和授權比在傳統的asp中要容易多了。在asp.net中，有三種形式的身份驗證：windows驗證、passport驗證和forms驗證。

　　windows驗證很簡單，用于簡單的應用程序。它根據當前域的active directory（ad）來驗證用戶身份。用戶組被當作角色來進行基于角色的驗證。用戶組的角色可能不像應用程序需要的那么細化，所以它們必須存在另一個數據庫或自己的ad中；windows驗證不能改變這些角色。

　　passport驗證是microsoft的.net my services策略的一部分，用來驗證internet程序中的用戶。passport是個單點登錄（sso）服務，允許注冊用戶用一個單一的用戶id和密碼來訪問相關的網站。microsoft passport服務器負責維護用戶身份信息并提供一個驗證機制。passport的wallet功能給用戶提供了選項來存儲他們的信用卡信息并與網站共享。如果網站需要更多的信息，它們可以在它們自己的數據庫中得到那個信息，并將它同passport用戶id結合起來。這對用戶是有好處的，因為她的信息是集中存儲的，她不需要訪問每個網站時都重復輸入信息。對于企業來說，這種驗證有不好的地方，因為它們必須相信一個數據庫，而它們對這個庫卻無法控制。到目前為止，passport驗證很難被人們廣泛采用而成為一種可行的驗證方法。

　　與passport驗證不同，forms驗證具有靈活性，你可以插入定制的驗證代碼，并開發公共的安全組件。你可以在服務器端machine.config中配置它，一旦完成配置，組件就自動插入那個服務器上的所有應用程序中了。

　　研究安全組件

　　asp.net提供了一個很好的方法用httpmodule在請求執行的路徑中插入新的功能。開發人員可以創建定制的httpmodule，用來驗證內部/外部用戶，建立用戶角色并創建一個定制的主要對象。關于一個簡單的定制httpmodule，你可以下載代碼樣例（見列表1）。

　　你也可能想考慮你的安全組件的一些其它的功能。例如，擁有一個安全管理控制臺會很好。這樣就提供了設施來定義應用程序角色，給角色授權（urls和操作），并給用戶授予角色。當你有一個控制臺應用程序時，你可以委派管理責任，包括安全設置。人們改變角色時，對于一個給定的角色來說，應用程序功能就改變了，這時候組件很有用，

　　你可能想擴展安全模塊來查看url和它的操作代碼，并查看用戶是否被授權了。應用程序中的每個資源或url可以有多個操作過程，如查看、創建、更新和刪除。如果你可以在操作上（而不是資源上）控制用戶的訪問，這會很有用。這就使asp.net頁面可以為相關用戶得到操作清單，而不用擔心用戶擁有什么角色。最后，考慮提供asp.net服務器端組件個性化，根據用戶能力來實施應用程序菜單。

　　一旦你得到了適當的安全組件，你就做好準備研究你的數據訪問方法了。人們在這方面常犯的錯誤就是在顯示層開發所有的東西，包括你的商業邏輯和數據訪問組件。這種開發就導致了很難維護的像意大利面條一樣的代碼（見資源）。它也使改變數據庫的計劃或者改變到一個全新的數據庫變得很難、很昂貴，因為你必須找到散布在你的應用程序中的所有的單獨的數據訪問調用指令。用四個層來構建你的企業級的應用程序——顯示層、工作流層、商業層和數據訪問層——可以使應用程序更容易維護、更具擴展性。

　　關于這個話題，我將重點講述數據訪問層。應用程序需要將數據訪問層同商業對象明顯分離開。你不想讓sql語句散布在從顯示層到商業層的所有代碼中。這些層不需要知道數據是如何得到的，從哪里得到的。

　　microsoft包含兩個新的對象——dataset和datareader——它們作為ado.net的一部分來分離各個層。dataset對象對于一個不連接的應用程序模式是很有用的，而datareader對象則用于連接的應用程序。然而，這些對象都有一個缺點：當你訪問屬性的值時，它們或者通過名字或者通過列號來查找。在通過列的名字訪問數據的情況下，如果在這些名字中有一個typo，在編譯時就不會被檢測出來。當列名散布在你的代碼中時，就很難在以后改變它們的名字了。如果你通過列號來訪問數據，代碼更難讀，而且你需要知道列在dataset或datareader中出現的順序。

　　運用strongly typed datasets

　　強類型（strongly typed) datasets解決了這個問題，但你不能總用dataset對象。當你運用dataset對象時，它把所有記錄都讀進內存中，在大量的應用程序中，服務器資源會用盡。但如果用datareader，就沒有一個等同于strongly typed row的對象。一種方法就是反復運用dataset和datareader，這樣會形成強類型的對象，是很理想的。

　　我用的一種方法就是對每個表用一個proxy對象和一個domain對象。proxy對象包含sql語句或存儲過程調用指令來得到或保存域對象。domain對象包含屬性來體現表的特性。商業邏輯組件與proxy對象交互，并在domain對象上執行商業邏輯。這種方法為proxy對象限制了sql語句或過程名字的內容。它提供了一個統一的數據訪問策略，提高了應用程序代碼的可讀性，減少了運行時的錯誤，并提供了靈活性，如果它有必要轉換到一個不同的數據庫層的話（見圖1）。

　　你應該用松散藕合的層來構建應用程序。這樣可以提高應用程序的可維護性、可擴展性和重用性。這種方法包含用于每個表的一個proxy對象和一個domain對象。proxy對象包含sql語句或存儲過程調用來得到或保存domain對象。domain對象包含屬性來呈現表的特性。

　　我們有必要探討一下關于proxy對象更多的細節問題。一個引起人們爭議的問題就是在proxy對象中是運用sql語句還是運用存儲過程調用。運用存儲過程比sql語句更有效。因此一些公司更喜歡用存儲過程，但你應該選用更適合你公司的方法。不管你采用什么方法，避免割裂存儲過程和商業邏輯組件之間的商業邏輯。我喜歡把商業邏輯保存在商業對象中。作為例子，我提供了一個c#代碼列表，它顯示了一個authors表的proxy和domain類（見列表2）。

　　你需要考慮的應用程序結構框架中的最后一步就是測試過程。測試在開發階段很重要，因為它是證明軟件可行的唯一的方式。然而，在時間緊迫的情況下，比如發行日期快到了，測試通常似乎處于一個次要位置。而且在大多數情況下，測試這項工作需要人們精力集中、擔負責任。每次代碼改變時，都需要人們嚴格地重復測試過程。

　　一種新的軟件開發方法學，極端編程（extreme programming），引進了一個嚴格的軟件開發方法，這種方法牢記使最終產品可以交付、使用戶滿意并質量合格（見資源）。它是建立在一個基于測試的開發理念上的，鼓勵開發人員在編寫實際的功能代碼前，編寫測試用例。所有的測試用例都作為類來開發，它們測試商業功能類的功能性。

　　一旦將測試用例作為類，你就可以在任何時候重復測試。如果所有的測試用例都不能運行，你就會知道有問題。當現有的代碼被改變時（很可能有些東西被破壞），這種測試方法尤其有效。

　　為了使測試更容易，極端編程方法的創立人kent beck創建了一種簡單的稱為junit的框架，使人們可以用java編寫測試用例。作為.net程序的“工廠”，你可以運用同等的公開的資源nunit（見資源）。它是建立在junit的最初觀念上的，你可以把它同visual studio .net（vs.net）集成起來。它可以讓你在同一個項目中包含測試類和功能類。在相同的項目中擁有測試類和功能類就可以進行有效的測試。每次當一個功能類改變時，你不需要轉換項目來測試。在開發周期中，你將測試方法添加到測試用例類，并添加功能到商業類，然后運行測試用例。測試類也同商業類一起集成在visual sourcesafe中。當你將測試作為開發過程的一個不可分割的部分時，你的代碼質量就提高了，重復測試很簡單。它也消除了由于改變代碼而引起的恐懼。

　　現在你已經知道了建立一個公共的應用程序結構的步驟，你已經做好準備將它們用于你的企業了。建立一個積極的小組，讓它們負責公共的底層框架及其前景。每個企業都會構建自己的應用程序并為此投資。創建一個公共的底層框架可以幫你更快地開發更高質量的應用程序，而且投資更少。

　　關于作者:

　　rao chejarla是一個獨立的軟件咨詢者。他主要關注軟件工程方法學和運用.net framework和j2ee的應用程序結構。他在軟件開發、設計和結構方面已有12年的經驗了。他的聯系方式是[email protected]