What Is a Module in .Net

What is a module in .NET?

A module is a logical collection of code within an Assembly. You can have multiple modules inside an Assembly, and each module can be written in different .NET languages (VS, as far as I'm aware, doesn't support creation of multi-module assemblies).

Assemblies contain modules.
Modules contain classes.
Classes contain functions.

Yes you can access assemblies, modules, classes, functions, properties, fields etc all via reflection at runtime.

What is the module keyword in C# .NET?

In your example module is a way to specify the attribute usage, like this:

[module: CLSCompliant(true)]
int Method1() { return 0; }

It is also called attribute target:

The target of an attribute is the entity which the attribute applies to. For example, an attribute may apply to a class, a particular method, or an entire assembly. By default, an attribute applies to the element that follows it.

For the full list of C# attribute parameters check the official documentation.

.NET Module vs Assembly

Every assembly has at least one module. It is an implementation detail that's highly invisible. But you can see it when you use Reflection.Emit. From the sample code for the AssemblyBuilder class:

AssemblyName aName = new AssemblyName("DynamicAssemblyExample");
AssemblyBuilder ab = 
    AppDomain.CurrentDomain.DefineDynamicAssembly(
        aName, 
        AssemblyBuilderAccess.RunAndSave);

// For a single-module assembly, the module name is usually
// the assembly name plus an extension.
ModuleBuilder mb = 
    ab.DefineDynamicModule(aName.Name, aName.Name + ".dll");

TypeBuilder tb = mb.DefineType(
    "MyDynamicType", 
     TypeAttributes.Public);

Note the use of the ModuleBuilder class, types are added to a module. That an assembly can contain multiple modules is pretty irrelevant, the build environment doesn't support it. Not just the IDE, MSBuild doesn't support it either. You'd have to write a build script yourself to use al.exe, the assembly linker. There are no good reasons to do this that I can think of, all .NET compilers already know how to generate a single module assembly directly. Al.exe is a typical bootstrapping tool, possibly used to build mscorlib.dll.

What are classes and modules for in C#

(Maybe I should be clear, there are no "Modules" in C# as in VB.NET's "Module")

There are no modules in C# (like the modules in VB or VB.NET). So, instead a module is one which is compiled and packaged into an assembly, it's more logical.

Whereas class is a well defined entity. A module may use a class (or classes), to function. (Again the word "module" is used logically)

The word "Module" is also used in a context quite different, in System.Reflection.Module

What is System.Reflection.Module?

An assembly can consist of multiple modules and even be split up into multiple files.

There are two primary use cases for using modules:

• Combining modules written in different languages / compiled by different compilers in one assembly
• Optimize downloading speed of an application by having a lightweight main module and loading further Types on demand.

Modules are in part an artifact of a time when the .NET team believed it was important for users to be able to download assemblies over the network to their local machine for execution.

To save bandwidth, an assembly can be split up into multiple files, each containing a module. The assembly file containing the primary or main module contains an assembly manifest that lists the location of all other assembly files. This allows a developer to ensure a fast initial download of the main assembly and the runtime loads Types or Resources from other modules in the assembly on demand.

If you're curious, you can actually instruct the C# compiler to spit out a modules and compile them manually with the assembly linker. Here's a tutorial on MSDN.

Most assemblies today are single-module assemblies containing only a main module. Unless you write code dealing with Reflection (or raw IL) for a living (I did some time back), you'll be fine if you just do assembly.MainModule whenever required. I'm pretty sure the number of people using multil-file/multi-module is ɛ​ (only marginally larger than 0).

What is the Module type?

The <Module> type is a place-holder for declarations that do not fit the CLI model. Normally relevant only in assemblies that are mixed-mode, containing both code written in a managed language as well as an unmanaged one like C or C++. It is empty for pure managed assemblies.

Those languages support free functions and global variables. The CLR does not directly support that, methods and variables must always be a member of a type. So the metadata generator uses a simple trick, it creates a fake type to be the home of such functions and variables. The name of that fake type is <Module>. It always has internal accessibility to hide the members. There is only ever one of those types, its RID is always 1.

The CLR source code calls it the "Global Class".

What is the difference between a module and a class?

A class is a type. You can use this type like any other type (String, Integer, Date, FileInfo ...) to declare variables, parameters, properties, and function return types.

Let us make a little example:

Public Class Person
    Public Property FirstName As String
    Public Property LastName As String

    Public Overridable Sub Print() 'I will explain Overridable later.
        Console.WriteLine($"{FirstName} {LastName}")
    End Sub
End Class

Now you can declare variables of type Person

Dim sue, pete As Person
Dim persons As List(Of Person)

sue = New Person()
sue.FirstName = "Susan"
sue.LastName = "Miller"

pete = New Person()
pete.FirstName = "Peter"
pete.LastName = "Smith"

persons = new List(Of Person)()
persons.Add(sue)
persons.Add(pete)

For Each person As Person In persons
    person.Print()
Next

---

Whereas modules are static. I.e. Data stored in a module exists exactly once. On the other hand, you do not have to instantiate a module with New, therefore they are often used to store global data and for methods that are available globally. For instance, you could store the persons list in a module.

---

But there is much more you can do with classes. You can derive a class from a base class. This new class inherits everything from the base class and can add more stuff to it. For instance, you could derive an Employee class from Person

Public Class Employee
    Inherits Person

    Public Property Salary As Decimal

    Public Overrides Sub Print
        Console.WriteLine($"{FirstName} {LastName}, Salary = {Salary}")
    End Sub
End Class

The Overridable keyword in Person.Print allows deriving classes to re-define (to override) the Print method. (Functions and Subs in classes are called methods.)

Employees are assignment compatible to Persons. You could add an employee to the persons list. This does not require any change in the For Each loop, i.e., the call of person.Print() automatically calls the right Print method (the first one for "normal" persons and the second one for employees).

Dim emp as Employee

emp = New Employee()
emp.FirstName = "Frank"
emp.LastName = "Taggart"
emp.Salary = 3500.00D

persons.Add(emp)

There is much more to say about classes. I hope that you got a certain idea of what you can do with classes.

See Objects and classes in Visual Basic and especially the section Differences between classes and modules.

What are managed modules?

A module is an ASP.Net component that plugs in to some point of the request pipeline; there are many "official" modules, although you can also code your own.

As you can see, modules perform a variety of functions including output caching, various kinds of authorization and authentication, and much more.

---

It's best not to run all managed modules; instead, if you can, figure out what modules a given application or platform needs. For ASP.Net MVC, that is likely the routing module: System.Web.Routing.UrlRoutingModule.

VB.NET What is the purpose of a class or module?

A module is really very similar to just a class containing only shared members. In fact, in C#, there is no such construct as a "module". You cannot write any application without having at least one module or class, so I suspect your real question is not "why use classes and modules", but rather "why use multiple classes and modules and when is it appropriate to start a new one". Since modules and classes are essentially the same thing, I'll just focus on why you would have multiple classes at all. There are essentially four main reasons to create a new class:

1. Store data in discreet items
2. Organize your code
3. Provide seams in your code
4. Divide your code into layers and support n-tiers

Now, let's look at each one in more detail:

Store Data in Discreet Items

Often times you need to store multiple data about a single item and pass that data around between methods as a single object. For instance, if you write an application which works with a person, you will likely want to store multiple data about the person, such as their name, age, and title. You could obviously store these three data as three separate variables, and pass them as separate parameters to methods, such as:

Public Sub DisplayPerson(name As String, age As Integer, title As String)
    Label1.Text = name
    Label2.Text = age.ToString()
    Label3.Text = title
End Sub

However, it's often more convenient to pass all the data as a single object, for instance, you could create a MyPersonClass, like this:

Public Class MyPersonClass
   Public Name As String
   Public Age As Integer
   Public Title As String
End Class

And then you could pass all the data about a person in a single parameter, like this:

Public Sub DisplayPerson(person As MyPersonClass)
    Label1.Text = person.Name
    Label2.Text = person.Age.ToString()
    Label3.Text = person.Title
End Sub

By doing it this way, it makes it much easier in the future to modify your person. For instance, if you needed to add the ability to store a skill for the person, and you had not put the person data in a class, you would have to go to every place in the code that passes person data and add the additional parameter. In a large project, it could be very difficult to find all of those places to fix, which could lead to bugs. However, the need for the class becomes even more apparent when you start needing to store a list of multiple people. For instance, if you need to store the data for 10 different people, you would need a list or array of variables, for instance:

Dim names(9) As String
Dim ages(9) As Integer
Dim titles(9) As String

It's of course, not at all obvious that names(3) and age(3) both store data for the same person. That is something you just have to know, or you have to write it in a comment so you don't forget. However, this is much cleaner and easier to do when you have the class to store all the data for a person:

Dim persons(9) As Person

Now, it's completely obvious that persons(3).Name and persons(3).Age are both data for the same person. In that way, it is self-documenting. No comment is needed to clarify your logic. As a result, again, the code will be less bug-prone.

Often, classes will contain not only the data for a particular item, but also the methods that act on that data. This is a convenient mechanism. For instance, you may want to add a GetDesciption method to the person class, such as:

Public Class MyPersonClass
   Public Name As String
   Public Age As Integer
   Public Title As String

   Public Function GetDescription() As String
       Return Title & " " & Name
   End Function
End Class

Then you can use it like this:

For Each person As MyPersonClass In persons
    MessageBox.Show("Hello " & person.GetDescription())
Next

Which, as I'm sure you'll agree, is much cleaner and easier than doing something like this:

For i As Integer = 0 To 9
    MessageBox.Show("Hello " & GetPersonDescription(title(i), names(i)))
Next

Now lets say you want to store multiple nicknames for each person. As you can easily see, persons(3).Nicknames(0) is far simpler than some crazy two dimensional array, such as nicknames(3)(0). And what happens if you need to store multiple data about each nickname? As you can see, not using classes would get messy very fast.

Organize Your Code

When you write a lengthy program, it can become very messy very quickly and lead to very buggy code if you do not properly organize your code. The most-important weapon you have in this battle against spaghetti-code is to create more classes. Ideally, each class will contain only the methods that are logically directly related to each other. Each new type of functionality should be broken out into a new well-named class. In a large project, these classes should be further organized into separate namespaces, but if you don't at least split them out into classes, you are really going to make a mess. For instance, lets say you have the following methods all thrown into the same module:

• GetPersonDescription
• GetProductDescription
• FirePerson
• SellProduct

I'm sure you'd agree, that it's just much easier to follow the code if these methods were broken out into separate classes, such as:

• Person
  
  • GetDescription
  • Fire
• Product
  
  • GetDescription
  • Sell

And that's just a very, very simple example. When you have thousands of methods and variables dealing with many different items and different types of items, I'm sure you can easily imagine why classes are important to help organize and self-document the code.

Provide Seams in Your Code

This one may be a bit more advanced, but it's very important, so I'll take a stab at trying to explain it in simple terms. Let's say you create a trace-logger class which writes log entries to a trace log file. For instance:

Public Class TraceLogger
    Public Sub LogEntry(text As String)
        ' Append the time-stamp to the text
        ' Write the text to the file
    End Sub
End Class

Now, lets say you want to have the logger class be able to write to a file or to a database. At this point it becomes obvious that writing the log entry to the file is really a separate type of logic which should have been in its own class all along, so you can break it out into a separate class, like this:

Public Class TextFileLogWriter
    Public Sub WriteEntry(text As String)
        ' Write to file
    End Sub
End Class

Now, you can create a common interface and share it between two different classes. Both classes will handle writing log entries, but they will each perform the functionality in entirely different ways:

Public Interface ILogWriter
    Sub WriteEntry(text As String)
End Interface

Public Class TextFileLogWriter
    Implements ILogWriter

    Public Sub WriteEntry(text As String) Implements ILogWriter.WriteEntry
        ' Write to file
    End Sub
End Class

Public Class DatabaseLogWriter
    Implements ILogWriter

    Public Sub WriteEntry(text As String) Implements ILogWriter.WriteEntry
        ' Write to database
    End Sub
End Class

Now, that you have broken that data-access logic out into its own classes, you can refactor your logger class like this:

Public Class TraceLogger
    Public Sub New(writer As ILogWriter)
        _writer = writer
    End Sub

    Private _writer As ILogWriter

    Public Sub LogEntry(text As String)
        ' Append the time-stamp to the text
        _writer.WriteEntry(text)
    End Sub
End Class

Now, you can reuse the TraceLogger class in many more situations without having to ever touch that class. For instance, you could give it an ILogWriter object that writes the entries to the windows event log, or to a spreadsheet, or even to an email--all without ever touching the original TraceLogger class. This is possible because you have created a seam in your logic between the formatting of the entries and the writing of the entries.

The formatting doesn't care how the entries get logged. All it cares about is how to format the entries. When it needs to write and entry, it just asks a separate writer object to do that part of the work. How and what that writer actually does internally is irrelevant. Similarly, the writer doesn't care how the entry is formatted, it just expects that whatever is passed to it is an already-formatted valid entry that needs to be logged.

As you may have noticed, not only is the TraceLogger now reusable to write to any kind of log, but also, the writers are reusable for writing any type of log to those types of logs. You could reuse the DatabaseLogWriter, for instance, to write both trace logs and exception logs.

A Little Rant Regarding Dependency Injection

Just humor me, a little, as I make this answer a little bit longer with a rant about something important to me... In that last example, I used a technique called dependency injection (DI). It's called dependency injection because the writer object is a dependency of the logger class and that dependency object is injected into the logger class via the constructor. You could accomplish something similar without dependency injection by doing something like this:

Public Class TraceLogger
    Public Sub New(mode As LoggerModeEnum)
        If mode = LoggerModeEnum.TextFile Then
            _writer = New TextFileLogWriter() 
        Else
            _writer = New DatabaseLogWriter() 
        End If
    End Sub

    Private _writer As ILogWriter

    Public Sub LogEntry(text As String)
        ' Append the time-stamp to the text
        _writer.WriteEntry(text)
    End Sub
End Class

However, as you can see, if you do it that way, now you'll need to modify that logger class every time you create a new type of writer. And then, just to create a logger, you have to have references every different type of writer. When you write code this way, pretty soon, any time you include one class, you suddenly have to reference the whole world just to do a simple task.

Another alternative to the dependency injection approach would be to use inheritance to create multiple TraceLogger classes, one per type of writer:

Public MustInherit Class TraceLogger
    Public Sub New()
        _writer = NewLogWriter() 
    End Sub

    Private _writer As ILogWriter

    Protected MustOverride Sub NewLogWriter()

    Public Sub LogEntry(text As String)
        ' Append the time-stamp to the text
        _writer.WriteEntry(text)
    End Sub
End Class

Public Class TextFileTraceLogger
    Inherits TraceLogger

    Protected Overrides Sub NewLogWriter()
        _Return New TextFileLogWriter() 
    End Sub
End Class

Public Class DatabaseTraceLogger
    Inherits TraceLogger

    Protected Overrides Sub NewLogWriter()
        _Return New DatabaseLogWriter() 
    End Sub
End Class

Doing it with inheritance, like that, is better than the mode-enumeration approach, because you don't have to reference all the database logic just to log to a text file, but, in my opinion, dependency injection is cleaner and more flexible.

Back to a Summary of Logic Seams

So, in summary, seams in your logic are important for reusability, flexibility, and interchangeability of your code. In small projects, these things are not of the utmost importance, but as projects grow, having clear seams can become critical.

Another big benefit of creating seams is that it makes the code more stable and testable. Once you know that the TraceLogger works, there is a big advantage to being able to extend it for future uses, such as writing logs to a spreadsheet, without having to touch the actual TraceLogger class. If you don't have to touch it, then you don't risk introducing new bugs and potentially compromising the rest of the code that already uses it. Also, it becomes far easier to test each piece of your code in isolation. For instance, if you wanted to test the TraceLogger class, you could just, for your test, make it use a fake writer object which just logs to memory, or the console, or something.

Divide Your Code Into Layers and Support N-Tiers

Once you have properly organized your code into separate classes, where each class is only responsible for one type of task, then you can start to group together your classes into layers. Layers are just a high-level organization of your code. There's nothing specific in the language that makes something technically a layer. Since there's nothing directly in the language that makes it clear where each layer starts and ends, people will often put all the classes for each layer into separate namespaces. So, for instance, you may have namespaces that look like this (where each namespace is a separate layer):

• MyProduct.Presentation
• MyProduct.Business
• MyProduct.DataAccess

Typically, you always want to have at least two layers in your code: the presentation or user-interface layer and the business-logic layer. If your application does any data access, that is typically put in its own layer as well. Each layer should be, as much as possible, independent and interchangeable. So, for instance, if our TraceLogger class in the above example is in a business layer, it should be reusable by any kind of UI.

Layers expand upon all of the previous topics by providing further organization, self-documentation, reusability, and stability. However, another major benefit for layers is that it becomes far easier to split your application into multiple tiers. For instance, if you need to move your business and data access logic into a web service, it will be very simple to do so if you have already written your code cleanly into defined layers. If, however, all of that logic is intermingled and interdependent, then it will be a nightmare to try and break just the data access and business logic out into a separate project.

The End of What I Have to Say

In short, you never need to create more than one class or module. It's always going to be possible to write your entire application in a single class or module. Entire operating systems and software suites were developed, after all, before object oriented languages were even invented. However, there is a reason why object-oriented programming (OOP) languages are so popular. For many projects, object-orientation is incredibly beneficial.

---

Related Topics