還記得在COM中為企業組織源代碼有多難嗎?典型情況下,你在命名時只可以用兩個級別(level):項目名稱和類名稱。你的ProgID通常是以下面的形式顯示的:
clearcase/" target="_blank" >cc>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.WebServices |
你運用的命名空間方案可以根據源代碼的目的范圍改變。如果你打算讓代碼跨企業共享,那么在命名空間中就不要放項目的名稱。我還建議你不要創建自己的命名標準。作為替代,你應該遵循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 |
![]() |
|
提到命名標準,我建議你遵循Microsoft已經建立的一些類名后綴。例如,屬性類都應該是以單詞“Attribute”結尾的,異常類都應該以“Exception”結尾。這就是說,你在決定為準備構建的類命名時,先要確定它屬于哪種類型的類,并查看vbcon/html/vxoriusingnetframeworkinvisualstudio.asp" target=_blank>.NET Framework類庫,看看是否已經有命名標準了。如果有,就遵循該命名標準。
我所講述的命名空間結構只是為了幫你組織企業的.NET源代碼。對于大多數公司來說,.NET還是項很新的技術,所以現在運用一個組織好的編目系統正是時候。通過本文,我們就會意識到為你的命名空間建立一個標準的命名結構的重要性。否則,你的.NET代碼就會是個混亂的、深層嵌套的ProgID代碼庫,你在運用它時,就會很費勁。
關于作者:
Jonathan Goodyear是ASPSoft(www.aspsoft.com)的總裁,這是個位于Orlando,Fla.的一家Internet咨詢公司。他是位MCSD,是Debugging ASP.NET(New Riders)一書的作者,你可以在www.debuggingasp.net找到它。你可以通過jon@aspsoft.com與他聯系,或者通過他在www.angryCoder.com上的angryCoder eZine同他聯系。
圖1. 命名你的項目節點
運用Visual SourceSafe項目樹來創建你的命名空間結構,在這里,我們用文件夾替代了命名空間中的圓點。
原文轉自:http://www.anti-gravitydesign.com