在過去，我一直走了，叫我的名字空間的特定項目一樣的項目（和原理類），例如最好的事情：什麼是打電話給你的命名空間的.Net
namespace KeepAlive
{
public partial class KeepAlive : ServiceBase
{...
然後從每當我調用這個類的其他項目的始終是：
KeepAlive.KeepAlive()...
現在我開始認爲這可能不是一個好主意，但我有點難倒什麼實際打電話給我命名空間。其他人做什麼？你是否只有一個名稱空間用於所有項目？
我們有這個簡單的方案：
CompanyName.ProductName
然後應用層，例如
CompanyName.ProductName.Data
CompanyName.ProductName.Web
等
而且內部劃分每個模塊和/或功能，這通常對應於文件夾
CompanyName.ProductName.Web.Shop
CompanyName.ProductName.Web.Newsletter
等
BTW：你可以找到答案類似的問題這裏：
我用名稱空間中所有事物的通用描述符命名我的名稱空間。
將類的名稱與命名空間相同是一個壞主意 - 在我看來，在某些情況下引用正確的東西非常棘手。
我通常會調用項目（和名稱空間）一個合適的名稱，然後在適當的位置爲入口點提供「EntryPoint」或「Program」。在你的例子中，我可能會調用類「KeepAliveService」。
CompanyName.ProductName.AreaOfSystem.SubAreaOfSystem
從來沒有打電話給他們相同的名稱爲一類。
我們的領域包括了諸如：
子區是謹慎使用，但如果相關：
我們不對應於文件夾，因爲在邏輯上可能不是這種情況。爲了緩解解決方案瀏覽器的導航，我們可能在文件夾部分關閉某些位，但這並不一定意味着該命名空間應遵循的文件夾結構。特別是如果文件夾中只有少量文件（一個類型很少的命名空間通常很愚蠢）。
我喜歡的java包方式：com.stackoverflow.Data（或whatwever貴公司的主域名而定）。
這樣，你的命名空間也不會含糊。
我們堅持到老
uk.co.company.system.layer
方案這樣，我們不斷的衝突降到miniumum因爲我們使用了很多的MS服務器產品，它可以幫助概念seperations 。
例如。
uk.co.acme.biztalk.bizutils。
我們非常相似。 +1！當該公司名稱變更，有合併或產品名稱的變化 – 2008-11-14 12:57:13