Building the Business Logic Layer

If you have class, you’ve got it made. If you don’t have class, no matter what else you have, it won’t make up for it.

If you have classes in your application, you’ve got it made. If you don’t have classes, no matter what else you have, it won’t make up for it. Classes are central to development in .NET.

In fact, it is difficult to build a .NET application without using classes. If you added a form to your project, you have already created a class. A form is just a class that inherits from the .NET Framework System. Windows.Forms.Form class, which gives the class the attributes and behaviors of a form.

In the preceding chapter, you saw how to use classes to build the user interface layer. This chapter shows you how to build classes for the business logic layer.

This chapter covers the fundamentals of creating classes and defining properties and methods. It also details more advanced topics such as using generics and building a base business object class. The Purchase Tracker sample application is used to demonstrate these techniques.

What Does This Chapter Cover?

This chapter demonstrates the following techniques:

1. Creating a class
   
2. Documenting the class with XML comments 
    
3. Adding exception classes to your class file 
    
4. Defining properties 
    
5. Defining property accessibility 
    
6. Understanding generics 
    
7. Handling Nullable types 
    
8. Defining methods 
    
9. Passing parameters ByVal or ByRef 
    
10. Overloading methods 
     
11. Marking methods as obsolete 
     
12. Creating a base business object class 
     
13. Overriding base class members

This chapter covers the basics of how to create a class and then builds on those basics to detail some of the new Visual Basic 2005 features such as XML comments and generics. If you have already been doing object-oriented programming in Visual Basic, you already know the basics. But if you want to “build along” as you read through this book, work through the basics before moving on to the more advanced features later in this chapter.

A class describes the things in your application, such as customers or products. Each piece of data associated with the class is defined as a property of the class. Each set of functionality associated with the class is defined as a method of the class.

For example, the Purchase Tracker sample application works with products. The products are described by a Product class. Each attribute of the products, such as name, number, description, price, and so on, is represented in the class as a property. Each process that must be performed for the products, such as retrieving, saving, and so on, is defined in the class as a method.

A single item, such as an individual product (a ring or sword, for example), is represented by an object created from the class. Because an object is an instance of a class, the act of creating an object from the class is called instantiation.

A common metaphor is to think of the class as the blueprint, and the object as the building constructed from the blueprint. Any number of buildings can be created from the same blueprint. Another metaphor is a cookie cutter. The class is the cookie cutter, and the objects are all the cookies created from the cookie cutter.

NOTE: The terms class and object are sometimes used interchangeably. Technically, however, the class is the data and logic that you define at design time. The objects are instances of the class created at runtime.

The phrase “business objects” is really a misnomer, because they are really “business classes.” In this book, the term “business object classes” is sometimes used to distinguish the difference.

If you are building a nontrivial application, build it as a set of layers, as described in Chapter 2, “Designing Software.” Implement each layer as a separate project in a solution, as described in Chapter 3, “Building Projects.” This gives you separately compiled components, one for each layer.

You build each layer as a set of classes. The user interface layer is comprised of a set of form classes (as shown in Chapter 4, “Building the User Interface Layer”) following the user interface design. The business logic layer (as described in this chapter) includes the set of classes you build following the implementation design. The data layer (detailed in Chapter 8, “Building the Data Access Layer”) contains classes that provide the interaction between the database and the business logic layer.

When you construct the business logic layer, it is important to define the pertinent set of classes. For each class, you define the appropriate properties and methods. This ensures that the correct set of information and logic is encapsulated in each class, making it easier to work with and maintain the class. 

NOTE: Even if you don’t go through the design phase, you need to think through the application to identify the appropriate set of classes for your business logic layer.

You normally define one class for each key thing involved with the application. For example, the Purchase Tracker sample application has products, customers, and purchases. The products map to a Product class, with properties to manage product information and methods to retrieve, save, and perform any other required processing on product information. The customers map to a Customer class, and so on. For more information on defining classes for your application, see Chapter 2.

You can also define classes for other implementation logic. For example, you could create a class to manage application logging or security. These implementation-based classes were also discussed in Chapter 2.

This section details the process of creating a class. You can use these techniques to create each class needed by your application.

There are many ways to add a class to a project. As discussed in the preceding chapter, adding a form project item actually adds two class files to the project. It adds a class in one file with a .vb extension and a partial class in another file with a .designer.vb extension.

When building the business logic layer, you normally add one class project item for each business object class (such as Product and Customer) and one for each implementation class (such as Logging and Security).

NOTE: You may want to define standard implementation classes in a separate utility component instead of in the business object component. That way, it can more readily become a part of your reusable framework, as discussed in Chapter 2.

To add a class to a project:

1. Right-click the project in Solution Explorer and select Add | New Item from the context menu, or select Project | Add New Item from the main menu bar.
   
   Alternatively, you could select Add | Class from the context menu, or select Project | Add Class from the main menu bar.
   
2. Select the Class template, name the class, and click the Add button.
   
   If you created your own class template using the steps in Chapter 3, you can use your template here.
   
   Use standard naming conventions for your class name. The most common standard is to name the class using the singular name of the business entity or implementation feature represented by the class. For products the class name would be Product, for logging the class name would be Logging, and so on.
   
   Visual Studio creates the class file with a .vb extension, adds it to Solution Explorer, and then displays the class in the Code Editor.

When Visual Studio creates the class file, it automatically generates the class declaration as follows:

Public Class Product

End Class

You can add any number of classes to your projects as needed by your application. Regardless of the class’s purpose or location, the basic process of building a class is the same.

NOTE: Throughout this chapter, classes are created in the business object Class Library project. You can use these same techniques to add classes to other parts of your application. For example, your Windows Application project may require classes to manage user interface features such as standard grid processing. Or you may create a utility or general library component that requires classes.  

Building Along

For the Purchase Tracker sample application:

• Visual Studio created a default class for you when you created the business object Class Library project (PTBO). In Solution Explorer, change the name of this default class from Class1 to Product.When you change the name of a class in Solution Explorer, Visual Studio changes the class name in the Code Editor accordingly.

NOTE: When you change the class name in Solution Explorer, Visual Studio modifies the class name in your code only if the class name matched the name defined in Solution Explorer. For example, say you don’t modify the class name in Solution Explorer, but you instead change the name directly in the class file. If you later change the name in Solution Explorer, it does not change the name you entered in the class file.

Documenting the Class

It is always a good idea to add documentation for a class immediately after adding the class. By adding the documentation right away, you focus on the class’s purpose, which helps you keep the class encapsulated. It is also much easier to document each class as you go along instead of facing the large task of going back later and documenting all the classes.

To document the class:

1. Open the class in the Code Editor. 
    

2. Move the insertion point immediately before the word Public in the Public Class statement.  

3. Type three comment markers, defined in Visual Basic as apostrophes ('''), and press the Enter key.
   
   The XML comments feature automatically creates the structure of your class documentation as follows:
   
   ''' <summary>
   '''
   ''' </summary>
   ''' <remarks></remarks>
   Public Class Product
   
   End Class

   ---

   NOTE: If you type the three comment markers in the empty line above the class definition instead of on the same line as the class definition, you don’t need to press the Enter key to generate the documentation structure. 

   ---

    

4. Type a summary of the class’s purpose between the summary tags and any remarks between the remark tags.
   
   Your documentation may be similar to this:
   
   ''' <summary>
   ''' Provides product management features such as
   ''' retrieving product data and saving product changes
   ''' </summary>
   ''' <remarks>Use this class to work with products
   ''' </remarks>

Use the summary tags to describe the class and the remarks tags to add supplemental information. The summary is the most important tag because it is the one used by Visual Studio.

When you provide a summary of the class using XML comments, your class displays documentation about itself in appropriate places within Visual Studio, such as in the List Members box, shown in Figure 5.1. Open the List Members box by typing a part of the class name in the Code Editor and pressing Ctrl+Spacebar or by selecting Edit | Intellisense | List Members from the main menu bar or by clicking the Display an Object Member List icon on the Text Editor toolbar. 

                                       

 
Figure 5.1.   The documentation provided in the List Members box is the summary defined in the XML documentation for the class.

Using XML comments to document your classes makes it easier for you and other developers to work with your classes.

Building Along

For the Purchase Tracker sample application:

• Open the Product class in the Code Editor.
  
• Add documentation for the Product class using XML comments.

In the Code Editor, view the comments by typing pro and then pressing Ctrl+Spacebar to display the List Members box, as shown in Figure 5.1.