C＃.net - Dll在接口/實現方案中的命名約定

Question

如果存在以下場景的任何命名約定，我需要一些巧妙命名dll和/或提示的建議。

我有一個接口定義和封裝在一個DLL中的接口定義使用的幾種類型。然後我在另一個dll中實現了這個接口。 關於這種情況的「特殊」事情是，我不開發應用程序，而是更多地收集我的公司的多個應用程序使用的功能集合（aka框架）。這些功能是通過MEF的接口定義來訪問的，所以這個框架的用戶通常不知道，對他來說也不是很重要，在哪個dll實現中（因爲他只需要知道並引用包含接口定義的dll ）。只是在非常罕見的情況下，他可能想知道dll（包含實現的那個）是如何命名的，因爲他想用自己的實現替換實現。

我創造了我的DLL命名一些要求：需要很好地命名，因爲這是用戶所引用的DLL

• 與接口定義的DLL。
• 接口定義dll的命名空間需要命名得很好（並且非常直觀），因此用戶確實希望在此命名空間中使用此定義，而命名空間最好與解決方案結構相同。
• 實現DLL必須命名得非常清晰，以便用戶可以識別工作目錄中的dll以將其刪除並安裝自己的實現。
• 實現的名稱空間並不重要，因爲它只在內部使用。
• 該dll名稱不應該太長。

首先，我想出了一個主意，組中的一個DLL中的特定類型的所有接口定義，這將創造一個非常良好命名的命名空間，因爲我可以在例如一個DLL的所有「服務」名爲myCompany組.Services.dll，將所有定義和類型放入該根目錄（它創建名稱空間MyCompany.Services），並因此保持解決方案結構與命名空間相同（如果這很有用或不可用，可能會在此討論）。

但是，這產生一個很大的問題：

如果我簽名的DLL和改變的東西在我的MyCompany.Services.dll，我必須重新編譯所有的DLL執行即使這種變化隻影響該n dll的一個。在那時，我考慮將每個接口定義和ity類型放入一個自己的dll中（如本文開頭所述）。

Answer 1

我的2美分的價值：

• 使用常見的頂級命名空間，所以一切這是你的框架的一部分，可以很容易地識別。你可能不「需要」它，但它似乎不傻。
• 使用描述性名稱。像Basti.SpecialFramework.Interfaces.DataAccess.Customer這樣的東西對我來說會很有意義。
• 圍繞您的系統的結構/體系結構構建命名空間使得批次有意義。
• 有一個結構良好的命名空間樹將有助於解釋同一地點的關鍵作品/術語，g：Basti.SpecialFramework.Interfaces.DataAccess.Customer vs Basti.SpecialFramework.BaseImplementations.DataAccess.Customer
• 對待它有點像開發信息架構或進行可用性測試：想出一組名稱草案並查看你的朋友是否可以弄清楚。做一個Card Sorting練習的等價性 - 你的結構是：[Layer]。[Interface/BaseImplementation]還是[Interface/BaseImplementation]。[Layer]？ （我不確定你將如何做卡片分類練習，但我可以看到一些強大的相似之處）。
• 描述性的名字往往很長，這是aganist你的最後一點;我同意長名稱可能不是「容易」和「方便」，但如果他們清楚地傳達我需要知道的事情，我會很好。

順便說一句：我確定命名約定存在DLL和Assembilies - 我只是不知道他們的頭頂。我想我可以Google/Bing他們，但我想你已經做到了。