Placing custom code in a System namespace(将自定义代码放在系统命名空间中)
问题描述
是否有任何最佳实践表明不应将自定义代码放置在 System
命名空间中?System
及其子项是否应保留给 Microsoft 代码?
Are there any best-practices that state custom code shouldn't be placed in a System
namespace? Should System
and its children be reserved for Microsoft code?
我问是因为我正在编写一个将在许多项目中使用的类库,我想通过将它放在 System.InteropServices
中来保持一致性(因为它处理 P/调用).
I ask because I'm writing a class library that will be used across many projects and I'd like to keep things consistent by placing it in System.InteropServices
(since it deals with P/Invoke).
推荐答案
这不是一个好主意,因为它破坏了命名空间的主要好处之一:防止名称冲突.如果较新版本的框架在该命名空间中引入了同名类型怎么办?
It's not a good idea because it defeats one of the primary benefits of namespaces: preventing name clashes. What if a newer version of the framework introduced an identically named type in that namespace?
这对于 System
命名空间尤其不利,因为它们是通过 using
指令导入到许多其他代码段中,并且在这些命名空间中引入自定义类型会污染其他命名空间的命名范围带有意外标识符的源文件.
This is particularly bad for System
namespaces since they are imported in many other pieces of code with using
directives and introducing custom types in those namespaces pollutes the naming scope of other source files with unexpected identifiers.
要对您的自定义互操作相关类型进行分类,您可以创建一个新的命名空间,例如 MyProduct.InteropServices
.
To categorize your custom interop related types, you can create a new namespace like MyProduct.InteropServices
.
这篇关于将自定义代码放在系统命名空间中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:将自定义代码放在系统命名空间中


基础教程推荐
- 错误“此流不支持搜索操作"在 C# 中 2022-01-01
- JSON.NET 中基于属性的类型解析 2022-01-01
- 是否可以在 asp classic 和 asp.net 之间共享会话状态 2022-01-01
- 经典 Asp 中的 ResolveUrl/Url.Content 等效项 2022-01-01
- 在 VS2010 中的 Post Build 事件中将 bin 文件复制到物 2022-01-01
- 将事件 TextChanged 分配给表单中的所有文本框 2022-01-01
- 从 VS 2017 .NET Core 项目的发布目录中排除文件 2022-01-01
- 首先创建代码,多对多,关联表中的附加字段 2022-01-01
- 如何动态获取文本框中datagridview列的总和 2022-01-01
- 全局 ASAX - 获取服务器名称 2022-01-01