命名空间和类名称准则

当涉及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％，因为在其他服务中可能会有更多的DateValidator，这很容易导致不需要的引用。

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

这是域模型。

来源

2011-09-07 Mattias

AppName.Services.Events.EventService.cs //(the actual service) 
AppName.Services.Events.ParticipantValidator.cs 
AppName.Services.Events.ParticipantCoordinator.cs 
AppName.Validators.DateValidator.cs 
AppName.Text.Extensions.cs

点：

添加扩展到命名空间描述他们正在扩展
加入通用的校验做一般的命名空间
使用应用程序的名称作为顶级（Microsoft建议公司名称按照他们的指导原则）
如果只有少数人，我不会把协调员放在单独的名称空间中。

微软指南可以在这里找到：Framework Design Guidelines

来源

2011-10-05 09:26:51 jgauffin

你可以把验证（其他类）是在多个服务使用名为例如单独的命名空间。 CommonValidators。
您可以更改名称EventService.cs而不是更改名称空间的名称 - 也许Main.cs或Default.cs？
我认为你的服务在接口中有一个合同，所以这将表明服务合同的主要/默认实现。

来源

2011-10-05 09:18:52 Mic

命名空间和类名称准则

回答

相关问题