常用命名空间命名建议

Question

我有一个带命名空间的分层应用程序：

• App.Core - 业务层逻辑服务
• App.Data - 数据访问层存储类和数据访问对象
• App.Web - 用户界面层

我也有业务对象/ DTO。它们位于App.Objects命名空间中，但我不喜欢这种命名约定。为什么？因为此命名空间还将具有后缀 Objects 的子名称空间，如App.Objects.KeywordObjects。这些子名称空间不能没有 Objects 后缀，因为其中一些还包含具有相同名称的类（App.Objects.KeywordObjects将包含Keyword和Keywords类）。

我在考虑将App.Objects更改为其他内容。所以我没有重复的“对象”字样。但我似乎找不到任何有用的词。而且我不想使用像DTO或BO这样的首字母缩略词。

您通常如何命名您的命名空间，在这种情况下您建议我应该使用什么。

Answer 1

我是Brad Abrams et Al的“框架设计指南”中的指南的粉丝，它会给你：

YourCompany.BusinessArea代表您的业务对象，YourCompany.BusinessArea.Web代表您的网络图层。我似乎记得还有一个指南，即对象不应该依赖于嵌套的命名空间（但你可以依赖于父命名空间）

Answer 2

命名空间深度应与使用频率相关联。为什么不将它们放在App中？如果您的应用程序围绕业务对象，那么将它们保留在根目录或附近是有意义的。

对于实际比较，对于许多业务应用程序，业务对象类似于在System中保留常见类型。它们很普遍。

Answer 3

以下是一些建议：

• App.Contracts
• App.Entities

给一个好名字很难做到。我能提出的最好的建议是找到适合你的东西，并尽力保持风格和语气的一致性。这说起来容易做起来难。

  

“当我用一个词时，”Humpty Dumpty用一种轻蔑的语气说，“这意味着我选择它的意思 - 既不多也不少。” - Lewis Caroll

Answer 4

我通常会自由地使用常见的首字母缩略词（所以我不介意亲自使用App.BO），但如果你在子名称空间中始终有Objects后缀，我认为App.Business读得很好例如App.Business.KeywordObjects带有“business [something] objects”短语。 （如果你没有总是为子命名空间设置Objects后缀，那么这个建议就行不通了，因为事情会读得很奇怪。）

Answer 5

我会做出以下更改

App.Core => App.Services

App.Objects => App.Core

或

App.Objects => App.Model

Answer 6

App.Business？