怎樣使.NET命名空間符合標準_.Net教程

推薦：談ASP.NET創建Web服務的使用事務
支持XML Web服務的事務利用公共語言運行期中的支持，其是基于Microsoft Transaction Server ( MTS)和COM Services中相同的分布式事務模型。該模型基于明確的判斷一個對象是否參與一個事務，而不是編寫特定的代碼用來處理委托和回調一個事務。對于一個使用ASP

命名空間可以幫你組織企業的.NET源代碼，但要做到這一點，必須要有可靠的計劃。by Jonathan Goodyear, MCSD, MCP, CLS

還記得在COM中為企業組織源代碼有多難嗎?典型情況下，你在命名時只可以用兩個級別(level)：項目名稱和類名稱。你的ProgID通常是以下面的形式顯示的：XYZCompanyAccounting.Payroll。顯然，這種方法并不理想。如果可以更細地劃分命名空間標識符就更好了。例如，在.NET中，ProgID可以表示成：XYZCompany.Accounting.Payroll。在這個例子中，兩者的差別并不大，但當你在定義層次更多的項目時，它們的差別就會很明顯了。

實際上，.NET Framework可以讓你創建更深層嵌套的命名空間，這種功能會使編程工作更順利(或更糟)。要運用深層嵌套的命名空間需要我們更仔細地做計劃，并需要企業各開發小組的配合。本文提供了一些有用的建議，講述了如何以命名空間的形式來組織源代碼，以及如何在Visual SourceSafe(VSS)項目中組織企業的.NET源代碼。

構建你的命名空間

作為出發點，你為一個源代碼單元分配的每個命名空間都應該以公司標識符開頭，這是很有用的。例如，在前面的例子中，我是以“XYZCompany”開頭的。命名空間的下一部分取決于代碼的目的范圍。如果你的代碼是包含商業邏輯的一個特定項目，那么命名空間的下一部分就應該是你的項目的名稱（例子中的“Accounting”）。接下來是細分你的項目（例子中的“Payroll”）。因此，你的特定項目的命名空間就應該是：XYZCompany.Accounting.Payroll

然后，你可以在XYZCompany.Accounting.Payroll命名空間中為手頭更具體的任務來定制類。通過在更細的基礎上劃分商業邏輯命名空間，你就可以在VSS中將代碼分成更具體的項目單元（我在后面會更詳細地對此加以講述）。

ASP.NET Web項目和Web services項目是特定項目命名空間的特殊的例子。對于ASP.NET Web項目來說，一個很好的命名標準就是CompanyName.ProjectName.Website。同樣，Web services項目的一個很好的命名標準就是CompanyName.ProjectName.WebServices。

根據該語法，用于XYZCompany的帳目網站和Web services的命名空間就會是：XYZCompany.Accounting.Website
XYZCompany.Accounting.WebService

你運用的命名空間方案可以根據源代碼的目的范圍改變。如果你打算讓代碼跨企業共享，那么在命名空間中就不要放項目的名稱。我還建議你不要創建自己的命名標準。作為替代，你應該遵循Microsoft已經為.NET Framework建立的標準。例如，如果XYZCompany的開發人員要構建一個企業類庫來將數據訪問封裝到SQL Server中，那么他們應該用下面的命名空間：XYZCompany.Data.SqlClient

該命名空間模擬了.NET Framework中的System.Data.SqlClient命名空間結構。同樣，如果XYZCompany的開發人員要構建一個類庫來封裝他們自定義的事件日志（event logging），那么下面的命名空間就會很適合：XYZCompany.Diagnostics

在你的命名空間中創建唯一的類名總是很好的。通過這種方法，當有必要讓你的代碼同時運用.NET Framework命名空間和特定企業的命名空間時，就不會出現類名沖突的現象。例如，你應該將自定義的事件日志類命名為EventLogger或XYZEventLog，而不是EventLog。我更喜歡用前面提到的建議，因為在一個完全形式的（fully-qualified）類名中不只一次地列出公司名稱會很啰唆。

出于幾個原因，以這種格式構建你的命名空間是很重要的。首先，通過建立一個公司名形式的根命名空間，我們在以后購買第三方產品時就避免了可能出現的命名空間沖突現象。第二，通過采用與.NET Framework一樣的命名空間結構，你就可以讓開發人員更容易地在企業底層架構中找到為他們所需要的功能提供了支持的類。Microsoft的類編目系統可能并不完善，但是讓開發人員去學習另外一個特定于你的企業的編目系統并沒有意義。第三，通過為企業構建命名空間層次，你就可以很容易地用一個文件生成工具（如NDoc）為整個類庫編譯一個單獨的MSDN形式的文件了。

構建你的項目
在構建好命名空間格式后，我們就可以考慮如何在VSS中構建項目了。我建議在你的VSS樹狀目錄結構的頂層中運用兩個項目節點：XYZ Enterprise .NET Class Library
XYZ Project .NET Class Library

這兩個項目節點可以讓你創建兩個單獨的文件（一個用于特定項目代碼，另一個用于企業代碼）。在每個頂層節點下，以公司名的形式創建一個項目節點（本例中的XYZCompany）。這就是你的根命名空間。至于VSS項目樹狀目錄結構的其它部分，我們可以復制你已經創建的命名空間結構，用文件夾來替代命名空間中的圓點（.），這同Java中各層次的類的顯示形式是類似的：在代碼中以圓點顯示、

在CLASSPATH系統環境變量中用文件夾顯示。記住，我們總是需要用完全形式的、完整的命名空間名稱來命名你的項目文件。

提到命名標準，我建議你遵循Microsoft已經建立的一些類名后綴。例如，屬性類都應該是以單詞“Attribute”結尾的，異常類都應該以“Exception”結尾。這就是說，你在決定為準備構建的類命名時，先要確定它屬于哪種類型的類，并查看.NET Framework類庫，看看是否已經有命名標準了。如果有，就遵循該命名標準。

我所講述的命名空間結構只是為了幫你組織企業的.NET源代碼。對于大多數公司來說，.NET還是項很新的技術，所以現在運用一個組織好的編目系統正是時候。通過本文，我們就會意識到為你的命名空間建立一個標準的命名結構的重要性。否則，你的.NET代碼就會是個混亂的、深層嵌套的ProgID代碼庫，你在運用它時，就會很費勁。

分享：談ASP.NET創建XML Web服務全接觸
XML Web服務描述 XML Web服務基礎結構創建在使用遵循一個公布的服務描述的基于XML的消息的通信的基礎上。服務描述是一個使用WSDL語言的XML語法編寫的XML文檔，定義了XML Web服務能理解的XML Web服務消息格式。服務描述起一個協定的作用，用來定義一個XML Web