您如何为命名空间命名?

发布于 2024-07-08 15:14:25 字数 881 浏览 6 评论 0原文

我会先说我通常在 C#/.Net 中工作。

通常,我使用一种命名方案,将常见的、可重用的组件放入反映我们组织的命名空间中,并将特定于项目的组件放入与项目绑定的命名空间中。 我这样做的原因之一是我有时与部门外但组织内部的其他人共享我的组件。 特定于项目的命名空间通常以部门的名称或缩写开头。 当我在项目之间重用代码时,我通常会将其迁移到基于组织的命名空间之一。

例如:

UIOWA.DirectoryServices 包含处理 Active Directory 的特定实现的类。

UIOWA.Calendar 包含处理大学主日历的类。

LST.Inventory.Datalayer 包含实现学习空间技术组库存应用程序的数据层的类。

我现在正在为一个实体开展一个项目,该实体与大学(一个举办慈善活动的学生团体)有着模糊的联系,该实体有可能在我们大学之外出售,因此,它并不真正适合按照我的正常命名约定,即该部门只是可能使用该项目的许多潜在客户中的第一个客户。

我倾向于采用组织命名路线并为此应用程序创建一个“组织项目”名称空间。 我想听听其他人如何处理这个问题以及您可能有的建议。

谢谢。

另请参阅有关命名空间组织的相关问题。

编辑

我最终创建了组织/项目命名空间UIOWA.MasterEvent并从那里派生出更多命名空间。 仍然对未来项目的其他意见感兴趣。

I'll preface this by saying that I usually work in C#/.Net.

Normally, I use a naming scheme that puts common, reusable components into a namespace that reflects our organization and project-specific components into a namespace tied to the project. One of the reasons I do this is that I sometimes share my components with others outside my department, but within the organization. Project-specific namespaces are typically prefaced with the name or abbreviation of the department. When I reuse code between projects, I typically migrate it into one of the organization-based namespaces.

For example:

UIOWA.DirectoryServices contains classes that deal with the specific implementation of our Active Directory.

UIOWA.Calendar contains classes that deal with the University's master calendar.

LST.Inventory.Datalayer holds the classes implementing the data layer of the Learning Spaces Technology group inventory application.

I'm embarking on a project now for an entity that has a fuzzier connection to the Unviersity (a student group that runs a charity event) that has the potential to be sold outside of our University and, thus, it doesn't really fit into my normal naming conventions, i.e., the department is only the first customer of potentially many that might use the project.

My inclination is to go the organization naming route and create an "organizational project" name space for this application. I'd like to hear how others handle this and any advice you might have.

Thanks.

See also this related question about namespace organization.

EDIT

I ended up creating the org/project namespace UIOWA.MasterEvent and deriving further namespaces from there. Still interested in other opinions for future projects.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

不再让梦枯萎 2024-07-15 15:14:25

我的部门在过去五年里改了三次名字,所以我们都很高兴有人决定不使用带有组织名称的命名空间……

我们的命名空间是按项目名称组织的。 可重用的东西被放入Toolbox命名空间中。 也许有点粗糙,但到目前为止效果很好。

My department got his name changed thrice in the last five years, so we're all glad that someone decided against using namespaces with organisational names...

Our namespaces are organised by project names. Reusable stuff is put into the Toolbox namespace. Perhaps a bit crude, but it works quite well so far.

猥琐帝 2024-07-15 15:14:25

我是一名 .NET 开发人员,我总是使用组织项目命名空间 (com.bolidian.projectspace),因为它保证了唯一性。

I'm a .NET developer, and I always use the organisational project namespace (com.bolidian.projectspace) because it guarantees uniqueness.

你的笑 2024-07-15 15:14:25

我使用该组织,然后使用产品,例如 Acme.Crm。 将类分组到子命名空间中时,始终使用复数或操作,这样就不会与类发生冲突。 例如

  • Acme.Crm.Letters
  • Acme.Crm.Invoicing

我遵循 Microsoft 的惯例,不将首字母缩略词大写,例如用 Crm 代替 CRM,用 Sql 代替 SQL - 但这更多是个人喜好。

I use the organisation, followed by the product eg Acme.Crm. When grouping classes together in a subnamespace always use a plural or action so that it cant clash with a class. eg

  • Acme.Crm.Letters
  • Acme.Crm.Invoicing

I follow Microsoft's convention by not capitalising acronyms eg Crm instead of CRM, Sql instead of SQL - but that's more a personal preference.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文