常用的命名空间命名建议

Question

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

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

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

我考虑更改App.Objects的名称。这样就不会有重复的" Objects "单词了。但我似乎找不到任何可用的单词。而且我不想使用类似DTO或BO的缩写。

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

- Robert Koritnik

Answer 1

我是“框架设计准则”(Brad Abrams等人编写的)的拥趸，这将为您提供以下内容:

- 用 YourCompany.BusinessArea 表示您的业务对象 - 用 YourCompany.BusinessArea.Web 表示您的 Web 层。 - 我记得还有一个准则，即对象不应该依赖于嵌套命名空间 (但可以依赖于父命名空间)。

- Rowland Shaw

Answer 2

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

就实际比较而言，对于许多业务应用程序来说，业务对象类似于在 System 中保存常见类型。它们是普遍存在的。

- Rex M

---

谢谢。这真的很有道理，因为所有其他层都依赖于这一层。所以它位于它们之上。 - Robert Koritnik

Answer 3

我会进行以下更改。

App.Core => App.Services

App.Objects => App.Core

或者

App.Objects => App.Model

- NerdFury

Answer 4

这里有一些建议：

• App.Contracts
• App.Entities

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

“当我使用一个词时，”亨普蒂·韦尔士以相当轻蔑的口吻说，“它的意思就是我选择的意思——既不多也不少。”——Lewis Caroll

- Andrew Hare

Answer 5

我通常自由地使用常见的缩写（因此我个人不介意使用App.BO），但如果您始终在子命名空间中具有Objects后缀，我认为App.Business读起来很好，例如那个“business [something] objects”短语的App.Business.KeywordObjects。（如果您不总是对子命名空间使用Objects后缀，则此建议效果不佳，因为事情会读起来奇怪）。

- Alex Martelli

Answer 6

App.Business？

- Christopher Karper