Are using modules in VB.NET considered bad practice?

During the design of a new application I was wondering if using a module with properties is considered to be a bad practice.

Some example code:

Module modSettings

   public property Setting1 as string

   public property DatabaseObject as IDatabaseObject

End Module

The code above is just an example to emphasize my question. In the past, this structure was used a lot in VB6. In the past I used it as well in my .NET projects.

But nowadays with buzzwords like Dependency Injection, Testabilit开发者_开发百科y and Separation of Concerns the above structure smells bad. I can't really describe why, but it just feels wrong. I must admit I'm not very familiar with the keywords above, yet.

So I'm wondering whether the above code really is a bad practice. If so, what would you use a Module for?

Centro is right that a Module (or a NotInheritable Class with Shared members) is the closest equivalent to a C# static class. So technically, nothing is wrong with it as it's just one of VB's ways of creating this type of class. For example, you cannot say Public Shared Class Settings in VB as you cannot put the Shared keyword on a class.

On its own I wouldn't call it bad practice if a specific circumstance calls for a Module, but otherwise a Module (or other static class equivalents) likely is not the design choice you want for having loosely coupled, testable code. Additionally, while a NotInheritable Class with Shared members is more descriptive than just saying Module, there is at least one circumstance where a Module must be used instead.

When would you need to use Modules in VB.Net? If you want to take advantage of extension methods, then it's your only option since as mentioned, you cannot create a shared (static) class in VB.Net, neither can you use extensions on NotInheritable Classes. You must use a module as follows:

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

In C# you can't use modules and must use static classes as follows:

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

The keyword Module in VB.NET came from VB 6. Actually it is compiled as NotInheritable Class with making all members static, in C# it is as sealed class with static members.

I think it is a bad practice since it is not quite clear that it is actually a class with static members.

There is nothing wrong with properties. In fact, to implement binding you need properties and to implement the INotifyPropertyChanged interface. I think I would prefer classes over modules though, but I'm a C# guy mainly.

Although it is possible to do this I must admit I have never seen it done in practise. In my opinion it is easier to read in a class as this declaration is explicit and using a class allows you to convert to a class later on if the need arises. So I can't think of any reason why you would want to do this over a class with a shared member