.net - 在 VB.NET 中使用模块是否被认为是不好的做法？

Question

在设计新应用程序期间，我想知道使用具有属性的模块是否被认为是一种不好的做法。

一些示例代码:

Module modSettings

   public property Setting1 as string

   public property DatabaseObject as IDatabaseObject

End Module

上面的代码只是强调我的问题的一个例子。过去，这种结构在VB6中被大量使用。过去，我也在我的 .NET 项目中使用过它。

但如今，随着依赖注入(inject)、可测试性和关注点分离等流行词的出现，上述结构闻起来很糟糕。我真的无法描述为什么，但就是感觉不对劲。我必须承认我对上面的关键字还不是很熟悉。

所以我想知道上面的代码是否真的 是 不好的做法。如果是这样，你会用什么 Module为了？

Answer 1

Centro正确的是，模块(或具有共享成员的 NotInheritable 类)是 最接近于 C# 静态类 .所以从技术上讲，它没有任何问题，因为它只是 VB 创建此类类的一种方式。例如，您不能说 Public Shared Class Settings在 VB 中，因为你不能把 Shared类的关键字。

就其本身而言，如果特定情况需要模块，我不会称其为不好的做法，但否则模块(或其他静态类等效项)可能不是您想要的具有松散耦合、可测试代码的设计选择。此外，虽然具有 Shared 成员的 NotInheritable 类比仅仅说 Module 更具描述性，但至少在一种情况下必须使用 Module。

什么时候需要在 VB.Net 中使用模块？如果您想利用 extension methods , 那么这是你唯一的选择 因为如上所述，您不能在 VB.Net 中创建共享(静态)类，也不能在 NotInheritable 类上使用扩展。您必须按如下方式使用模块:

Imports System.Runtime.CompilerServices

Public Module StringExtensions
    <Extension()> _
    Public Function Remove( _
                        ByVal input As String, _
                        ByVal subStrings As String()) As String
        Return String.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim()
    End Function
End Module

在 C# 中，您不能使用模块，必须使用静态类，如下所示:

public static class StringExtensions
{
    public string Remove(this string input, string[] subStrings)
    {
        return string.Join("", input.Split(subStrings, StringSplitOptions.None)).Trim();
    }
}