命名空间和类名称准则

当涉及到utils和其他帮助类时，我在正确命名类和服务时遇到问题。

您将如何构造以下内容：

EventService.cs
EventServiceUtils.cs
EventServiceValidators.cs
EventServiceCoordinator.cs

等等...

我有与上述服务具有相同需求的多种服务。一种想法是将所有这些都分离到合适的名称空间中，使其看起来像这样：

Services.EventService.EventService.cs //(the actual service)
Services.EventService.Validators.DateValidator.cs
Services.EventService.Validators.ParticipantValidator.cs
Services.EventService.Coordinators.ParticipantCoordinator.cs
Services.EventService.ExtensionMethods.Extensions.cs

等等。每个命名空间当然都是一个单独的文件夹。但这并不是100％，因为DateValidators其他服务中可能还有更多，这很容易导致不必要的引用。

并且还在Services.EventService.EventService.cs名称空间中包含类名称，这也不好。您可以使用Services.Event.EventService.cs，但是当然已经有一个具有该名称的实体。

这是领域模型。

我认为您可以在此处改善命名空间的最大一件事就是Service从EventService名称空间中删除。我还将调整名称空间，使其更像这样：

Services.Events.EventService.cs //(the actual service)
Services.Events.EventExtensions.cs
Services.Events.ParticipantCoordinator.cs
Services.Validators.DateValidator.cs
Services.Validators.ParticipantValidator.cs

我仍然认为这可以使用一些改进。

我曾经喜欢命名空间，但如今我认为少即是多。深度嵌套您的名称空间会使您的代码过于冗长，将内容分解到很远会降低您的继承能力。例如，在您的代码中，一个DateValidator类可以轻松地在其他地方使用，因此它上面不应有太多的命名空间，因为EventService以外的服务现在可以利用DateValidator类。扩展方法也相同。没有时间（我可以看到），您不需要同时查看所有扩展方法，因此将其与相关的东西组合在一起更有意义。在这种情况下，EventExtensions可能链接到your EventService，因此从逻辑上讲，我认为它们应该放在一起。

您为什么不阅读Microsoft的通用命名准则和命名空间命名准则来遵循通用模式？

我认为该公式<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]效果很好。

正确的名称空间设计将考虑逻辑和物理设计。

尽管最初使用名称空间的理由主要是为了防止对象和方法名称之间的名称冲突，但它已成为整个解决方案体系结构和设计中的重要元素。您不仅希望概念层次结构和逻辑设计有意义，还可能希望将代码整齐地打包在设计良好且易于重用的库中，这些库以后可以轻松捆绑到其他项目和产品中。这也许是更好的物理设计所期望的结果。

查看.NET Framework，以及如何在合理大小的程序集中为您提供相关功能的单元。您可以放入参考和using语句，然后突然有了可用的相关功能，而不必拖入任何数量的厨房水槽。这是因为.NET Framework的物理设计（包括智能命名空间）已将与逻辑相关的代码打包在与物理相关的可部署单元中。通过在命名空间和程序集之间创建出色的映射，Microsoft .NET框架的架构师和开发人员使您的工作变得更加轻松（当然有些人可能会反对，但我对他们的工作感到满意）。

实际上，C＃中的命名空间相当随意。您可以将名称空间放在彼此最远离的程序集中的最奇怪的位置。这方面的任何有用学科实际上都是您对组织良好的软件产品的个人贡献。在每种情况下，我都不敢向您提供确切的建议。在这个答案中，我希望完成的工作是让您在定义名称空间时考虑物理设计以及逻辑设计。越多的东西使逻辑上相关并且可部署（物理上）捆绑在一起，对于您和其他某天可能需要处理您的代码的人来说，事情就越容易实现。

因此，请务必考虑解决命名空间问题时如何将代码打包在程序集和组件中！