良好命名空間命名約定

Question

我正在爲CRUD業務應用程序創建類庫。業務對象（以及相關的數據訪問層對象）的主要「類別」分別是：

• 維護（在數據庫與主工作 表（主表）
• 事件（最對象涉及到一個真正的-world事件）
• 搜索（明顯）

截至目前，我的命名空間設置如下：

個
• BusinessObjects.Maintenance.Contacts
• BusinessObjects.Maintenance.Products
• BusinessObjects.Maintenance.Classifications
• 。
• BusinessObjects.Incidents.Contacts
• BusinessObjects.Incidents.Products
• BusinessObjects.Incidents.Classifications
• 。
• BusinessObjects.Search.Contacts
• BusinessObjects.Search.Products
• BusinessObjects.Search.Classifications
• 。
• Dal.Maintenance.Contacts
• Dal.Maintenance.Products
• Dal.Maintenance.Classifications
• 。
• Dal.Incidents.Contacts
• Dal.Incidents.Products
• Dal.Incidents.Classifications
• 。
• Dal.Search.Contacts
• Dal.Search.Products

注意，每個類別的同名結束。

這是好的形式嗎？

這個命名空間約定是否有問題？任何可能混淆的另一個人看/使用此代碼？

我知道在表單代碼中，一個缺點是我必須限定所有具有名稱空間的對象。對我來說，這不是什麼大不了的事情。如果這只是一個字，我通常更喜歡一點清楚。

Answer 1

無論如何，這似乎還好吧。儘管我會避免使用縮寫，但這會讓人感到困惑，並迫使人們不得不知道縮寫或查找它們。他們也變得難以理解，無法形容。你可能會遇到

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..." 

的一個問題是細微的差別名稱。由於名字的長度是一個可能的問題，你的眼睛可能會掩蓋整個事物，並且只能拾取其中的一部分。將來我會有這個地方發生？：

BusinessObjects.Incidents.Classifications 
BusinessObjects.Classifications.Incidents 

或

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP 
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP 

那做作的例子可能會出現問題的情況下。

Answer 2

我覺得這個項目會從一些縮寫中受益。當我遇到過這樣的問題時，我通常會用一些文檔來解釋一些縮寫作爲命名空間。我通常將這些縮短的名稱限制爲3-5個字符。這不僅增加了表單代碼中的通用代碼可讀性，而且我還發現，較短的名稱可以減少與其他編碼人員的混淆。

我希望有幫助。在一天結束時，這真的只是取決於你的團隊的偏好...

Answer 3

在經歷了這麼多之後，我們試圖保持命名空間的數量很少（對於一個非常大的項目，少於幾十個），並且命名空間的深度較短（少於5個）。從消費角度來看（使用我們的代碼庫的開發人員），這是一個開銷，幾乎沒有什麼好處，不得不跟蹤大量名稱空間，而只有很少的類。

我們還根據使用情況分組，喜歡like。如果一個開發人員很可能總是與其他人一起使用某些類，儘管（在你的例子中）可能與維護有關，而另一個不是，如果它們在邏輯上，操作上或程序上相關，我們將它們放在相同的名稱空間中。獨立的功能（例如，特定於維護的邏輯）使用提供者模型分解爲另一個名稱空間。由於開發人員不太可能需要修改提供程序包含的功能，因此需要更深入，獨立的名稱空間。

Answer 4

我爲每個庫使用一個名稱空間，每個可執行源代碼集使用一個名稱空間。名字總是很短。例如，在我目前工作的可執行文件，我有：

• ALib - 我一般工具庫
• 蒙戈 - 我的迷你Web服務器庫
• DBLite - 我的sqlite3的包裝器&簡單 持久性層
• TRACK1 - 可執行文件（實際上是一個 夫婦可執行文件）

這似乎是工作得很好。我發現應該避免使用非常複雜的命名空間方案，就像非常複雜的，深層次的階層應該一樣。

Answer 5

您的命名空間層次結構看起來類似於稱爲嵌套泛化的條件。這是當你有類派生多種不同的方式。

想象一下，一個類層次結構如下：

class Vehicle 

class Car : Vehicle 
class CarRed : Car 
class CarBlue : Car 

class Truck : Vehicle 
class TruckRed : Truck 
class TruckBlue : Truck 

注意，車輛可以是汽車或卡車。此外，車輛可以是紅色或藍色。這很好地工作，但是當您想要添加新的顏色或車輛類型時會出現問題，因爲修改的負擔會以二次方式增長。

這個問題是由GOF設計模式書描述的 - 特別是橋模式。

雖然它沒有具體解決對命名空間的擔憂，但我的直覺告訴我情況是相似的。我會說，如果你能避免這種情況，那麼你應該。

Answer 6

在實現任何特定模式之後，不要將您的包命名，而是將其命名爲業務或功能域。

即：

Org.MyCompany.BusinessObjects.Maintenance.Contacts 
Org.MyCompany.BusinessObjects.Incidents.Contacts 
Org.MyCompany.BusinessObjects.Search.Contacts 

代替：

Org.MyCompany.Contacts 

，其中將包括類/接口/對象/不管是在 「聯繫人」 執行操作。

Answer 7

也可以看看這個MSDN文章爲指導，在命名命名空間

命名空間的

名稱： http://msdn.microsoft.com/en-us/library/ms229026.aspx