我知道这有点主观，但我想知道是否有一个普遍接受的标准来命名包含一些“核心”功能的程序集。
假设您有一个更大的项目，其中包含类似的程序集
并且您有一堆“核心”类，例如全局错误处理程序、全局日志记录功能等。
这样的程序集一般会如何命名？以下是我想到的一些事情：
现在，虽然“只选择一个并继续”不会导致世界末日，但我仍然想知道是否有一种“公认”的方式来命名这些程序集。
【问题讨论】：
标签： .net
所有这些“root”、“core”、“common”等等，可能不是最好的命名约定。
通用的东西应该位于根命名空间中，例如 .NET、string、int 和其他“核心”或“通用”的东西位于根 System-命名空间中。
不要使用命名空间来更轻松地折叠 Visual Studio 中的文件夹，而是根据它包含的内容和用途来构建它。
System.Security 包含常见的安全信息，例如 System.Xml 不需要知道，除非您明确需要该功能。
System.Security.Cryptography是一个子命名空间。加密就是安全，但安全并不是明确的加密。
这样System.Security.Cryptography 可以全面了解其父命名空间，并且可以隐式使用其父命名空间内的所有类。
我会说System.Core.dll 是微软方面的失误。他们一定是用完了想法或 DLL 名称。
更新：MSDN 有一些更新的article that tries to explain Microsoft's thinking on the subject。
【讨论】：
使用 .Net，这相对容易更改，所以我会很方便。
更少、更大的程序集比许多小型程序集编译得更快，所以我会从您的“核心”内容开始，将其作为 Company.Product.dll 中的命名空间，如果需要，稍后再将其拆分。
【讨论】：
我通常喜欢描述每个程序集内部内容的名称。
您会看到，如果您将某个东西命名为 .Core，那么在一个大型团队中，它可以非常迅速地发展，因为人们会考虑将非常常见的东西放入该程序集中。
所以，我认为不应该真的只有一个核心组件。
【讨论】：
我使用过 .Core、.Framework 和 .Common。
【讨论】：
我们使用这个模型：
等等
【讨论】：
我总是使用 .Core.dll。
【讨论】：
我最常用并且似乎很喜欢的一个，因为我没有看到其他人使用它是Root
我通常会这样做
CompanyName.Root
或
SomethingMeaningfulToMe.Root
【讨论】：
这是其中一个取决于问题的问题。如果它是您的代码并且您在一个小团队中工作，我会使用任何对您有意义的命名约定。然而，我在大型代码库中看到命名空间允许下游开发人员在不需要文档或培训的情况下发现功能。我们使用模型。标准化命名空间使开发人员更容易在团队之间移动。
业务名称.Division.Layer
【讨论】：
我也使用了 .Core，尤其是 .dll
这完全是个人喜好问题，如果根命名空间是公司名称，我觉得 .Core/framework/common 比公司名称更具描述性。
但是，如果您正在处理诸如 dll/命名空间的名称也是项目名称的开源项目，那么 .Core/../ 可能有点多余。
.net 框架和其他微软库中有许多使用这两种约定的示例。例如有一个 System.dll 和一个 System.Core.dll :)
【讨论】：
Core 是非常有意义且易于理解的命名约定，并且它不会与任何 .net 框架命名空间冲突，因此这是非常好的做法。
我强烈建议在每个程序集中封装它应该提供给使用它的应用程序的服务，而不是在一个程序集中混合不同的功能域。
我们正在使用
CSG.Core
CSG.Data
CSG.Services
...
在核心中，我们包含了可能在我们所有产品中使用的类：日志记录、集合扩展、泛型、配置扩展、安全性、验证等。
虽然编译多个程序集比编译更少和更大的程序集要慢，但它优化了您的部署，因为您只部署了系统使用的类，而不包含许多仅仅因为您想节省编译时间而未使用的类。
当您命名命名空间时，我强烈建议避免在命名空间的不同级别重复相同的词。例如，避免以下情况：
YourCompany.Core
YourCompany.YourProduct.Core
将核心放在 YourCompany 或 Myproduct 中，但不要同时放在两者中。例如，如果您的 using 看起来像： 使用您的公司； 使用 YourCompany.YourProduct;
当您键入 Core.SomeClass 时，这个类的来源会非常混乱，如果您有 2 个同名的类，则会导致冲突。
【讨论】：