One of the language enhancements in .NET 2.0—available in both VB.NET 2005 and C# 2.0—is support for partial classes. In a nutshell, partial classes mean that your class definition can be split into multiple physical files. Logically, partial classes do not make any difference to the compiler. During compile time, it simply groups all the various partial classes and treats them as a single entity.
One of the greatest benefits of partial classes is that it allows a clean separation of business logic and the user interface (in particular the code that is generated by the visual designer). Using partial classes, the UI code can be hidden from the developer, who usually has no need to access it anyway. Partial classes will also make debugging easier, as the code is partitioned into separate files.
In this article, I will examine the use of partial classes in more detail and discuss how Visual Studio 2005 makes use of partial classes.
Using Partial Classes
Listing 1 contains two class definitions written in VB.NET, with the second class definition starting with the partial keyword. Both class definitions may reside in two different physical files. Functionally, Listing 1 is equivalent to Listing 2.
Listing 1
'---File1.vb---
Public Class Class1
Public Sub method1()
End Sub
End Class
File2.vb
Partial Public Class Class1
Public Sub method2()
End Sub
End Class
Listing 2
'---File1.vb---
Public Class Class1
Public Sub method1()
End Sub
Public Sub method2()
End Sub
End Class
So, what are the uses for partial classes?
Here are some good reasons to use partial classes:
They allow programmers on your team to work on different parts of a class without needing to share the same physical file. While this is useful for projects that involve big class files, be wary: If you find your class file getting too large, it may well signal a design fault and refactoring may be required.
The most compelling reason for using partial class is to separate your application business logic from the designer-generated code. For example, the code generated by Visual Studio 2005 for a Windows Form is kept separate from your business logic (we will discuss this in a later section). This will prevent developers from messing with the code that is used for the UI. At the same time, it will prevent you from losing your changes to the designer-generated code when you change the UI.
The "partial" keyword in VB.NET used to be called "expands" in pre-beta versions of Visual Studio 2005.
Examining Partial Classes
The following code sample shows the class definition of MyClass1. I declared all my properties in this file. To avoid confusion, I named my class file MyClass1.Properties.vb, in order to make it obvious that this file contains a properties definition.
'---MyClass1.Properties.vb
'---one of the classes need not have the Partial keyword
Public Class MyClass1
Private pX As Integer
Private py As Integer
Property x() As Integer
Get
Return pX
End Get
Set(ByVal value As Integer)
pX = value
End Set
End Property
Property y() As Integer
Get
Return py
End Get
Set(ByVal value As Integer)
py = value
End Set
End Property
End Class
In another file, named MyClass1.Methods.vb, I provide the methods implementation of MyClass1. I used the Partial keyword to indicate that this definition should be combined with the original MyClass1 definition.
'---MyClass1.Methods.vb
'---must have the Partial keyword
Partial Public Class MyClass1
Private py As Integer
Public Sub method1()
' implementation here
End Sub
Public Sub method3(ByVal x As Integer, ByVal y As Integer)
' implementation here
End Sub
Public Sub method2()
' implementation here
End Sub
End Class
In reality, you can mix and match properties and method definitions in any of the files, but for clarity it is a good idea to group properties definitions in one file and methods definitions in another. The usual rules of OO apply: If there is a method1 in both files, then both method1s must have unique signatures.
The syntax of partial classes in VB.NET and C# differs slightly. The following shows the implementation of partial classes in C#:
// In C#, the partial keyword must
// appear in all class definitions
public partial class MyClass1
{
public MyClass1()
{
//implementation here
}
}
public partial class MyClass1
{
//implementation here
}
Besides the order in which the "partial" keyword is placed, the most significant difference is the strict enforcement of the use of the "partial" keyword in all partial classes in C#. It is mandatory, whereas in VB.NET, not all of the partial classes have to have the "partial" keyword. This has caused a significant amount of newsgroup discussion about the rationale for the difference. My advice is that you should always prefix partial classes with the "partial" keyword. At least this will give you a visual clue that part of the implementation of the class lies somewhere else, and it is definitely useful when it comes to debugging.
While partial classes allow you to split the definition of a class into multiple files, you cannot mix languages. That is, all partial classes must be written in the same language. Besides using the "partial" keyword for classes, you can also use it for structures and interfaces.
If your class implements multiple interfaces, it is a good idea to use partial classes to contain the implementation for each interface.
Hide-protecting code is one of the best uses of partial classes; you can prevent mishaps and provide useful code-layer abstraction at the same time. In Visual Studio 2005, Microsoft uses partial classes to hide designer-generated code. For example, in Visual Studio .NET 2003, the designer-generated code for a Windows form is encapsulated within the region "Windows Form Designer generated code"Very often, developers will accidentally modify the code within this region and cause the form to display incorrectly.
In Visual Studio 2005 however, the designer-generated code is no longer visible in the Code View window (see Figure 2). Instead, it is hidden within Solution Explorer.
To see the designer-generated code, go to Solution Explorer and click on the Show All Files button (see Figure 3). Under the name of the Windows form, you will see a file post fixed with the "Designer.vb" name. Double-clicking on Form1.Designer.vb will reveal the designer-generated code:
Partial Public Class Form1
Inherits System.Windows.Forms.Form
_
Public Sub New()
MyBase.New()
'This call is required by the
' Windows Form Designer.
InitializeComponent()
...
Notice that the Form1.Designer.vb file appears under the Form1.vb file in Solution Explorer. This is a good way to represent the relationship between the two files. So what does Visual Studio do to represent this relationship? The answer lies in the .vbproj or .csproj (for C# projects) file. Open the file in Notepad and use Ctrl + F to locate theelement:
...
Form
Form1.vb
Form
...
As you can see, theelement indicates that Form1.Designer.vb is dependent on Form1.vb. So how is this information useful to us?
Recall that earlier in this article I mentioned two partial classes, MyClass1.methods.vb and MyClass1.properties.vb. Assume that these two classes serve as a template and contain general-purpose functions (and you generally would not make changes to these two classes). You may add a third partial class to add business-specific functions. And so, it would be useful to hide the first two partial classes in Solution Explorer by modifying the .vbproj/.csproj file:
MyClass1
MyClass1.vb
MyClass1
MyClass1.vb
MyClass1
When the project is loaded in Visual Studio 2005, you should see the two partial classes hidden
Unfortunately, at this moment you need to manually modify the project file in order to hide partial classes. Hopefully in the next beta Microsoft will build this function into Visual Studio. Or someone else will write a plugin for that.
In this article, you have seen how to split the definitions of a class into multiple classes using the "partial" keyword. The greatest use of partial classes is undoubtedly the separation of UI and business logic. I am interested to know how else you may be using partial classes.
One of the greatest benefits of partial classes is that it allows a clean separation of business logic and the user interface (in particular the code that is generated by the visual designer). Using partial classes, the UI code can be hidden from the developer, who usually has no need to access it anyway. Partial classes will also make debugging easier, as the code is partitioned into separate files.
In this article, I will examine the use of partial classes in more detail and discuss how Visual Studio 2005 makes use of partial classes.
Using Partial Classes
Listing 1 contains two class definitions written in VB.NET, with the second class definition starting with the partial keyword. Both class definitions may reside in two different physical files. Functionally, Listing 1 is equivalent to Listing 2.
Listing 1
'---File1.vb---
Public Class Class1
Public Sub method1()
End Sub
End Class
File2.vb
Partial Public Class Class1
Public Sub method2()
End Sub
End Class
Listing 2
'---File1.vb---
Public Class Class1
Public Sub method1()
End Sub
Public Sub method2()
End Sub
End Class
So, what are the uses for partial classes?
Here are some good reasons to use partial classes:
They allow programmers on your team to work on different parts of a class without needing to share the same physical file. While this is useful for projects that involve big class files, be wary: If you find your class file getting too large, it may well signal a design fault and refactoring may be required.
The most compelling reason for using partial class is to separate your application business logic from the designer-generated code. For example, the code generated by Visual Studio 2005 for a Windows Form is kept separate from your business logic (we will discuss this in a later section). This will prevent developers from messing with the code that is used for the UI. At the same time, it will prevent you from losing your changes to the designer-generated code when you change the UI.
The "partial" keyword in VB.NET used to be called "expands" in pre-beta versions of Visual Studio 2005.
Examining Partial Classes
The following code sample shows the class definition of MyClass1. I declared all my properties in this file. To avoid confusion, I named my class file MyClass1.Properties.vb, in order to make it obvious that this file contains a properties definition.
'---MyClass1.Properties.vb
'---one of the classes need not have the Partial keyword
Public Class MyClass1
Private pX As Integer
Private py As Integer
Property x() As Integer
Get
Return pX
End Get
Set(ByVal value As Integer)
pX = value
End Set
End Property
Property y() As Integer
Get
Return py
End Get
Set(ByVal value As Integer)
py = value
End Set
End Property
End Class
In another file, named MyClass1.Methods.vb, I provide the methods implementation of MyClass1. I used the Partial keyword to indicate that this definition should be combined with the original MyClass1 definition.
'---MyClass1.Methods.vb
'---must have the Partial keyword
Partial Public Class MyClass1
Private py As Integer
Public Sub method1()
' implementation here
End Sub
Public Sub method3(ByVal x As Integer, ByVal y As Integer)
' implementation here
End Sub
Public Sub method2()
' implementation here
End Sub
End Class
In reality, you can mix and match properties and method definitions in any of the files, but for clarity it is a good idea to group properties definitions in one file and methods definitions in another. The usual rules of OO apply: If there is a method1 in both files, then both method1s must have unique signatures.
The syntax of partial classes in VB.NET and C# differs slightly. The following shows the implementation of partial classes in C#:
// In C#, the partial keyword must
// appear in all class definitions
public partial class MyClass1
{
public MyClass1()
{
//implementation here
}
}
public partial class MyClass1
{
//implementation here
}
Besides the order in which the "partial" keyword is placed, the most significant difference is the strict enforcement of the use of the "partial" keyword in all partial classes in C#. It is mandatory, whereas in VB.NET, not all of the partial classes have to have the "partial" keyword. This has caused a significant amount of newsgroup discussion about the rationale for the difference. My advice is that you should always prefix partial classes with the "partial" keyword. At least this will give you a visual clue that part of the implementation of the class lies somewhere else, and it is definitely useful when it comes to debugging.
While partial classes allow you to split the definition of a class into multiple files, you cannot mix languages. That is, all partial classes must be written in the same language. Besides using the "partial" keyword for classes, you can also use it for structures and interfaces.
If your class implements multiple interfaces, it is a good idea to use partial classes to contain the implementation for each interface.
Hide-protecting code is one of the best uses of partial classes; you can prevent mishaps and provide useful code-layer abstraction at the same time. In Visual Studio 2005, Microsoft uses partial classes to hide designer-generated code. For example, in Visual Studio .NET 2003, the designer-generated code for a Windows form is encapsulated within the region "Windows Form Designer generated code"Very often, developers will accidentally modify the code within this region and cause the form to display incorrectly.
In Visual Studio 2005 however, the designer-generated code is no longer visible in the Code View window (see Figure 2). Instead, it is hidden within Solution Explorer.
To see the designer-generated code, go to Solution Explorer and click on the Show All Files button (see Figure 3). Under the name of the Windows form, you will see a file post fixed with the "Designer.vb" name. Double-clicking on Form1.Designer.vb will reveal the designer-generated code:
Partial Public Class Form1
Inherits System.Windows.Forms.Form
Public Sub New()
MyBase.New()
'This call is required by the
' Windows Form Designer.
InitializeComponent()
...
Notice that the Form1.Designer.vb file appears under the Form1.vb file in Solution Explorer. This is a good way to represent the relationship between the two files. So what does Visual Studio do to represent this relationship? The answer lies in the .vbproj or .csproj (for C# projects) file. Open the file in Notepad and use Ctrl + F to locate the
...
...
As you can see, the
Recall that earlier in this article I mentioned two partial classes, MyClass1.methods.vb and MyClass1.properties.vb. Assume that these two classes serve as a template and contain general-purpose functions (and you generally would not make changes to these two classes). You may add a third partial class to add business-specific functions. And so, it would be useful to hide the first two partial classes in Solution Explorer by modifying the .vbproj/.csproj file:
When the project is loaded in Visual Studio 2005, you should see the two partial classes hidden
Unfortunately, at this moment you need to manually modify the project file in order to hide partial classes. Hopefully in the next beta Microsoft will build this function into Visual Studio. Or someone else will write a plugin for that.
In this article, you have seen how to split the definitions of a class into multiple classes using the "partial" keyword. The greatest use of partial classes is undoubtedly the separation of UI and business logic. I am interested to know how else you may be using partial classes.
