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

Question

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

• 如果你不这样做,为什么？
• 如果你正在使用它,为什么？

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

Answer 1

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

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

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

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

Answer 2

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

我主要使用这些类别:

• My.Computer:主要用于文件系统和网络目的
• My.Application:版本号,当前目录
• My.Resources:以强类型方式访问驻留在资源文件中的应用程序所使用的资源.
• My.Settings:非常方便

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

Answer 3

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

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

Answer 4

我在我的 VB.NET 项目中使用了 My，我并不为此感到内疚。我主要是一个 C# 人，但在我将我的公司转移到 C# 之前，我们是一家 VB 商店。在我看来，My 命名空间是一个很好的语法糖。正如我不会因为使用 C# 的合并运算符和其他糖而感到尴尬一样，我也不会因为使用 VB 的糖而感到尴尬。（在某种程度上；我不会使用 .NET 仍然公开的经典 VB 函数。）

也就是说，永远不要在该命名空间中放置任何东西。这是 Microsoft 的命名空间，就像您不会在 System 或 Microsoft 下放置任何内容一样，也不要在 My 下放置任何内容。它会在以后引起混乱——如果不是你，那么维护你代码的其他人。为您自己的代码创建您自己的命名空间。