Question

摘要

哪个名字更好？

Domain.PersonService
DomainServices.PersonService
DomainServices.PersonDomainService（考虑一些较长的名称，如PersonDomainServiceModelDecorator）

或其他什么？

情况

我们有一个框架，每个层都有一些基类。防爆。存储库，域服务，UI等

每个逻辑层都有一个名称，用作名称空间：

包含存储库的数据层的“数据”;防爆。 Fx.Data.DbContextRepository
域（非Web）服务层的“服务”;防爆。 Fx.Services.CrudService
Web UI层的“Web.UI”;防爆。 Fx.Web.UI.Controllers.CrudController

对于有一些额外层的终端项目，我们也遵循相同的规则：

“数据”Ex。 Project.Data.PersonRepository
“服务”Ex。 Project.Services.PersonService
“Web.UI”Ex。 Project.Web.UI.Controllers.PersonController
代码优先实体的“实体”;防爆。 Entities.Person
对象模型的“模型”;防爆。 Models.Person.Criteria，Models.Person.PersonDeleteModel

我的重点是“域名服务”层，但欢迎任何关于其他层的想法。

我们最终得出的结论是“服务”不是“域名服务”的合适名称，因为它可能会导致“Web服务”或“域名服务”层之间的歧义。

现在我们将“Services”命名空间更改为“Domain”或“DomainServices”。但我们还有另一个问题。我们为每个域服务类（例如PersonService）添加了“服务”后缀。现在，使用“DomainService”后缀（例如DomainServices.PersonDomainServer或DomainServices.DomainPersonService）似乎很难看。

因此，使用“Domain”作为名称空间可以更漂亮，而类名称显示它们是域命名空间下的服务（例如Domain.PersonService）。

Answer 1

我会提出两个简单的想法：

尝试在没有的情况下定义全名（名称空间+类型名称）冗余（同名部分 - 域，人，服务，模型，控制器，...... - 不应该出现两次）
从.NET框架本身获取灵感。那里有more than 40000 classes！打开所有 .NET Reflector或ILSpy等工具中的程序集小心翼翼。

我想出这样的事情：

Domain
 + Person
 + PersonService // Domain service
Domain.Data
 + PersonRepository
Domain.ServiceModel // WCF, etc. I chose the same namespace as .NET Framework
 + PersonService // Service implementation, this is really a service so "service" redundancy seems unavoidable here
Domain.Web.UI
 + PersonController

好的，它显然不方便在层次结构中多次出现相同的类型名称。好吧，但这也是名称空间（和命名空间别名）也存在的原因。我认为这不是什么大问题。

Answer 2

您认为项目中Domain和DomainServices之间有什么区别吗？如果您希望将服务和其他域实体保留在不同的命名空间中，我相信您需要将PersonService移动到DomainServices命名空间。

大多数时候我们不查看命名空间，我们只提到类，这就是为什么我认为拥有DomainServices命名空间是好的。如果您在整个应用程序中拥有单个域并且没有计划将其分开，我认为最好将其称为Domain.PersonService

关于类名中的'Doman'这个词，我真的不喜欢这个，因为它增加了名称的复杂性。您应该尝试以这种方式构建应用程序，以确保在打开PersonService时，您应该100％确定它是域服务。您知道，当您打开PersonRepository时，它是Data图层，域名相同。

Answer 3

我会用以下两种方式之一做到这一点：

1）为什么没有Services的子名称空间：

Services.Web用于网络服务
Services.Domain域名服务

另一方面，我会从Web删除Web.UI（假设您只有基于网络的用户界面）。

2）如果Web服务实际上存在于Web层中，那么它们可能位于Web.Services命名空间中Web.UI也是可接受的。域服务只能在Services命名空间中生存。

Answer 4

我的建议是把它作为的 <Company>.<Component>.<SubComponent>.<Module>.DLL**。 Microsoft建议在此链接上使用类似的内容http://msdn.microsoft.com/en-us/library/vstudio/ms229048(v=vs.100).aspx，示例将为** Microsoft.Practices.EnterpriseLibrary.Security.Dll

因此，您可能希望使用Company.Domain.PersonService

域服务层的良好命名

摘要

情况

4 个答案: