你在VB.NET中使用'My'命名空间吗？

VB.NET有"我的"命名空间,但有多少VB.NET开发人员实际使用它？

如果你不这样做,为什么？

如果你正在使用它,为什么？

我正在考虑为VB.NET构建一个框架,并使用My命名空间将其插入VB似乎是一个合理的想法.是吗？

据我所知,My的目的是成为常见但难以查找或难以使用的某些API任务的简便快捷方式.您可能不应该完全包含My下的框架.(首先,使用你的框架的C#人可能会感到不高兴.)

相反,您应该将其设计为普通框架.完成后,列出一些人们可能想要使用框架的常见任务.看看在My下是否有任何有用的东西,特别是在有多种方法可以使用的类或方法的情况下,但它们有一两个真正常用的用法,可以用My缩写.

本文将介绍如何扩展My,最后有一节介绍了一些要遵循的设计准则: 通过自定义My Namespace简化常见任务

至于你的主要问题,当在VB .NET中编码时,我尽可能经常使用My.它将一些操作减少到一行代码.

我非常喜欢VB.NET中的"我的"命名空间,我总是在我的WindowsForms应用程序中使用它,因为它非常直观.

我主要使用这些类别:

My.Computer:主要用于文件系统和网络目的

My.Application:版本号,当前目录

My.Resources:以强类型方式访问驻留在资源文件中的应用程序所使用的资源.

My.Settings:非常方便

我认为,如果你的框架My的扩展适合,那么很多VB.NET程序员都会欣赏它们.

我们在一些代码中使用它,但犹豫不决.确实,My通常有助于使代码更具可读性.例如,Environment.SpecialFolder枚举奇怪地缺少一个Temp成员,而My.Computer.FileSystem.SpecialDirectories有一个(Path.GetTempPath()也会这样做,但与其他特殊文件夹相比并不直观).

但My仅在这种情况下才有用,因为现有的API设计得很糟糕,而不是因为My本质上更好.像JAGregory一样,我强烈建议尽可能避免扩展My- 或任何其他类型的全局命名空间,变量等.这个想法不适合干净的OOP架构.