C# .net - 接口(interface)/实现方案中的 Dll 命名约定

Question

如果存在以下场景的任何命名约定，我需要一些关于 dll 巧妙命名的建议和/或提示。

我有一个接口(interface)定义和封装在一个 dll 中的接口(interface)定义使用的几种类型。然后我在另一个 dll 中实现了这个接口(interface)。 这种情况的“特殊”之处在于我不开发应用程序，而是开发我公司的多个应用程序使用的功能集合(又名框架)。这些功能是通过 MEF 通过其接口(interface)定义访问的，因此该框架的用户通常不知道，对他来说也不重要，实现在哪个 dll 中(因为他只需要知道和引用包含接口(interface)定义的 dll ).只是在非常罕见的情况下，他可能想知道 dll(包含实现的那个)是如何命名的，因为他想用自己的实现替换实现。

我为我的 dll 命名创建了一些要求:

• 具有接口(interface)定义的 dll 需要正确命名，因为这是用户正在引用的 dll。
• 接口(interface)定义 dll 的命名空间需要很好地命名(并且非常直观)，因此用户确实希望在此命名空间中定义此定义，其中命名空间等于解决方案结构是最佳选择。
• 实现 dll 的命名必须非常清晰，以便用户可以识别工作目录中的 dll 以将其删除并安装自己的实现。
• 实现的命名空间并不重要，因为它仅在内部使用。
• dll名称不要太长。

首先，我想到了将特定类型的所有接口(interface)定义分组到一个 dll 中的想法，这将创建一个非常好的命名空间，因为我可以将例如所有“服务”分组到一个名为 MyCompany.Services 的 dll 中。 dll，将所有定义和类型放在该根目录中(创建 namespace MyCompany.Services)，因此使解决方案结构与 namespace 相同(如果有用或无用，可能会在此处讨论)。

但这会产生一个大问题:

如果我对 dll 进行签名并更改我的 MyCompany.Services.dll 中的某些内容，我必须重新编译所有实现 dll，即使此更改仅影响这 n 个 dll 之一。那时我考虑将每个接口(interface)定义和实体类型放在一个自己的 dll 中(如本文开头所述)。

Answer 1

我的 2 美分值(value):

• 使用通用的顶级命名空间，以便可以轻松识别框架中的所有内容。您可能并不“需要”它，但不这样做似乎很愚蠢。
• 使用描述性名称。 Basti.SpecialFramework.Interfaces.DataAccess.Customer 之类的东西对我来说很有意义。
• 围绕系统的结构/体系结构构建 namespace 具有很多的意义。
• 拥有结构良好的命名空间树将有助于在同一位置解释关键作品/术语，例如:Basti.SpecialFramework.Interfaces.DataAccess.Customer 与 Basti.SpecialFramework.BaseImplementations .DataAccess.客户
• 有点像开发信息架构或进行可用性测试:想出一组名称草稿，看看您的 friend 是否能弄明白。做一个 Card Sorting 的等价物练习 - 你的结构是:[Layer].[Interface/BaseImplementation] 还是 [Interface/BaseImplementation].[Layer]？ (我不确定你会如何进行卡片分类练习，但我可以看到一些强烈的相似之处)。
• 描述性名称往往很长，这与您的最后一点背道而驰；我同意长名称可能不“简单”和“方便”，但如果它们清楚地传达了我需要知道的信息，我会同意的。

顺便说一句:我确定存在 DLL 和程序集的命名约定——我只是想不起来它们。我想我可以用 Google/Bing 搜索它们，但我想你已经这样做了。