Creating the Shared Objects

To begin, you need to create the interfaces and structures that will allow your objects to communicate across the network. Then you can start building the data-centric objects. You will build this application vertically (that is, one piece of functionality at a time), so you need to start with the Region objects, then build the Territory objects, and finally build the Employee objects.

In the VS .NET Integrated Development Environment (IDE), select the Class1.vb file from the NorthwindShared project. Rename the file to Structures.vb and delete the class definition that is in the file by default. Now you should have a blank code module.

Option Explicit and Option Strict

Option Explicit requires that all variables be declared before they are used. This ensures that there are no untyped variables floating around.

Option Strict ensures that all values are explicitly cast from one type to another. For example, intNum = "5" would work with Option Strict off, but with Option Strict on, the code would read intNum = Convert.ToInt32("5"). This enforces type casting at design-time rather than having an error occur during runtime.

In VB6, Option Explicit needed to appear at the head of every code module. In .NET they do not. There is a setting for each of these options in the Options dialog box of VS .NET (under the Projects node), and they apply to all modules in a project. However, under certain circumstances this is not desirable (when using reflection specifically) and so you will need to add these declarations at the head of every module.

To declare these values, use the following syntax:

 Option Explicit On Option Strict On 

Building the Structure

Next, let's create the structure used by the Region objects. Enter the following code in the Structures.vb code module:

 Public Structure structRegion     Public RegionID As Integer     Public RegionDescription As String End Structure 

Note

I have named the structure structRegion, which follows my naming convention. It does not matter what naming convention you use; what is important is that you use the same naming convention everywhere and that the convention is well documented. It also helps if it makes sense….

Now you need to make a slight change to your structure. Change the structure declaration line to read as follows:

 <Serializable()> Public Structure structRegion 

The Serializable attribute allows the Common Language Runtime (CLR) to handle object serialization for you. You do not have to write your own routine to serialize the data in your object—the .NET Framework handles it all for you. Finally, you need to start organizing your code into namespaces. Namespaces make finding pieces of code easy and help speed up developer productivity. As you saw in Chapter 2, "Building an N-Tier Application," you can set the root namespace in the properties for a project, so now you will create additional namespaces within the project. You will create a new namespace called Structures, which contains all of your shared structures. Your code should look like Listing 3-2 when you are done.

Listing 3-2: The Structures Code Module

 Option Explicit On Option Strict On Namespace Structures     <Serializable()> Public Structure structRegion         Public RegionID As Integer         Public RegionDescription As String     End Structure End Namespace 

Building the Interface

Now, add another code module to the NorthwindShared project called Interfaces. To do this, right-click the NorthwindShared project in the Solution Explorer and select Add Add Class and change the name to Interfaces. When the code module loads, delete the class declaration created by default. Enter the code in Listing 3-3 into the Interfaces code module.

Listing 3-3: The Interfaces Code Module

 Option Explicit On Option Strict On Imports NorthwindTraders.NorthwindShared.Structures Namespace Interfaces     Public Interface IRegion         Function LoadProxy() As DataSet         Function LoadRecord(ByVal intID As Integer) As structRegion         Sub Save(ByVal sRegion As structRegion, ByRef intID As Integer)         Sub Delete(ByVal intID As Integer)     End Interface End Namespace 

Let's look at each of these method signatures because they will form the basis of all of the communication across the network.

The LoadProxy method simply returns a dataset with all of the rows in a table. It may or may not return all of the columns of data—this depends on how many columns there are. You will look at this in more depth when you create the user interface.

The LoadRecord method returns the Region structure, which contains one entire record from the database. It accepts an ID as an argument because this is the type of value that is the key on the Regions table.

The Save method saves a single record. It takes a structure and an ID as arguments. You might be curious about the intID argument. You could return the ID by turning the Save method into a function as opposed to a subroutine. However, you will be modifying this routine to return a different type of value, which saves you from having to do more work than necessary.

The Delete method accepts a table key and deletes a record from the database.

Note

Many people use the terms argument and parameter interchangeably, but there is subtle difference between the two. A parameter is the type of variable that a method takes and is part of the method signature. An argument is the actual value passed to the method.

The Imports line allows you to avoid fully qualifying your structRegion reference. Without the imports line, you would have to enter the line to look like the following:

 Function LoadRecord(ByVal intID As Integer) As Structures.structRegion 

This could get tedious after a while, so use the imports line where it is needed to cut down on the amount of code you need to enter.

At this point, you have enough information to communicate across the network, so it is time to build the stored procedures and the data-centric business objects.