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

Question

我需要對dll進行巧妙命名的一些建議和/或以下情況下是否存在任何命名約定的提示。

我有一個接口定義，並且該接口定義使用的幾種類型封裝在一個dll中。 然后，我在另一個dll中實現了該接口。 關於這種情況的“特殊”之處在於，我不開發應用程序，而是開發了公司的多個應用程序使用的功能（又稱為框架）的集合。 這些功能是通過MEF通過其接口定義訪問的，因此，該框架的用戶通常不知道該實現在哪個dll中，也不重要（因為他只需要知道並引用包含該接口定義的dll）即可。 ）。 只是在非常罕見的情況下，他可能想知道dll（包含實現的那個）的命名方式，因為他想用自己的替換實現。

我為dll命名創建了一些要求：

• 需要對具有接口定義的dll進行好命名，因為這是用戶正在引用的dll。
• 接口定義dll的名稱空間需要很好地命名（並且非常直觀），因此用戶確實希望在該名稱空間中使用此定義，這是使名稱空間等於解決方案結構的最佳選擇。
• 必須將實現dll命名為非常清晰，以便用戶可以在工作目錄中標識該dll，以將其刪除並安裝自己的實現。
• 實現的名稱空間並不重要，因為它僅在內部使用。
• dll名稱不應太長。

首先，我想到了將一個特定類型的所有接口定義分組到一個dll中的想法，這將創建一個命名很好的名稱空間，因為我可以將所有“服務”分組到一個名為MyCompany.Services.dll的dll中，該根目錄中的所有定義和類型（這將創建名稱空間MyCompany.Services），因此使解決方案結構與名稱空間相同（如果有用或無效，在此也可以進行討論）。

但這產生了一個大問題：

如果我對dll進行簽名並更改MyCompany.Services.dll中的某些內容，則即使該更改僅影響這n個dll中的一個，我也必須重新編譯所有實現dll。 那時，我考慮過將每個接口定義和ity類型放在一個自己的dll中（如本文開頭所述）。

Answer 1

我的2美分價值：

• 使用通用的頂級名稱空間，以便輕松識別框架中的所有內容。 您可能不需要“需要”它，但是似乎很愚蠢。
• 使用描述性名稱。 像Basti.SpecialFramework.Interfaces.DataAccess.Customer這樣的東西對我來說很有意義。
• 圍繞構建系統的結構/架構的命名空間，使大量的意義。
• 具有結構良好的名稱空間樹將有助於在同一位置解釋關鍵作品/術語，例如： Basti.SpecialFramework.Interfaces.DataAccess.Customer與Basti.SpecialFramework.BaseImplementations.DataAccess.Customer
• 像開發信息體系結構或進行可用性測試一樣對待它：提出一組名稱草稿，看看您的朋友是否可以解決。 是否進行卡片排序練習的等效性-您是否構造了它：[Layer]。[Interface / BaseImplementation]或[Interface / BaseImplementation]。[Layer]？ （我不確定您將如何進行卡片分類練習，但是我可以看到一些相似之處）。
• 描述性名稱往往很長，這是您最后的觀點。 我同意長名稱可能不是“簡單”和“方便”的，但是如果它們清楚地傳達了我需要知道的信息，我會同意的。

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