Building Business Objects for an Application

Obsolescing Methods

Code changes over time. Methods that you created today may no longer be needed tomorrow. But if you delete them, every piece of code that calls the method needs to be changed. Depending on the features you are implementing, this may be necessary. But in many cases, you can define a smoother obsolescence plan.

Obsolescence is the concept in which methods become obsolete over time. Instead of changing a method for a new feature, you add a method overload to support the new feature, essentially making the original method obsolete. That way, you need to change only the code required for the new feature, not every piece of code that calls the original method. You can then obsolete the original method so that you don’t forget to remove it at a later point in time.

In looking at the Create method example from earlier in this chapter, you defined the method with a product name parameter. Suppose you later find that you need to sometimes manage comment information. So you add an overloaded method with a flag defining whether to handle comment information. You want every call to the method to ultimately call the new method signature. But in the interim, by having the original method remain in place, any unchanged code still works.

To identify a method as obsolete, use the Obsolete attribute. An attribute is metadata that you can associate with programming elements such as classes, properties, and methods. Attributes are defined in Visual Basic using less-than (<) and greater-than (>) signs. Attributes must be defined on the same line as the declaration of the class, property, or method to which the attribute is assigned. Use the line-continuation character (_) to separate the attribute from the declaration so that they are easier to read.

For example, to define one overload of the Create method as obsolete, add the Obsolete attribute to the method:

<ObsoleteAttribute( _
  "Use the Create(prodName, withComments) instead", False)> _
Public Shared Function Create(ByVal prodName) As Product
    Return Create(prodID, False)
End Function

The attribute’s name can be defined with or without the “Attribute” suffix; either Obsolete or ObsoleteAttribute can be used. Your coding standards may define that the suffix is included for clarity or not included for brevity. Either way, be consistent with all attributes.

Some attributes, such as the Obsolete attribute, have parameters. The first parameter in this case is a message to any developer using your obsolete method, and the second parameter is an error flag. This message appears in the Error List window (see Figure 5.3) as a warning if the second parameter is False, or as an error if the second parameter is True. This gives the developer using the method a warning or error, depending on your standard method obsolescence path.

Figure 5.3.  When you define a property or method as obsolete, any developer using the method knows that the property or method is on the obsolescence path.

Define a standard obsolescence plan for your application. This plan defines when properties and methods are made obsolete, how long they should be obsolete in a warning mode, and at what point they should be marked with a compile-time error. This provides a phased approach to modifying your application.

Building a Base Business Object Class

Business objects have standard housekeeping tasks that they must perform. For example, they must keep track of their state (unchanged, added, modified, deleted). The purpose of a base business object class is to define a standard set of operations that are applicable to all business objects. This keeps the housekeeping code out of the business objects themselves.

Creating base classes was covered in detail in Chapter 4, which demonstrated how to build a base form class. This section provides information on building a base business object class. For all the definitions, benefits, and techniques of building a base class, see Chapter 4.

Creating the Base Business Object Class

The primary code in a business object base class is housekeeping code—code that manages the object state, whether it is “dirty” (meaning changed), and whether it is valid. The base business object class performs any task that is common for all the business objects.

To create a base business object class:

1. Add a project item to your business object Class Library project using the Class template.
   
   If you created your own class template, you can use it here. Use a clear name for the base business object class. This helps you (and your project team) keep track of the base class. 
    
2. Add code as desired.
   
   Add any code that is common to the business objects to the base business object class.

As an example, the base business object class can keep track of the object state. The code required for this has three parts. First, the set of valid business object states must be defined. Then one or more properties must be created to expose the state. Finally, a method is needed to manage the state.

The set of valid business object states can be implemented using an enumeration, defined with the Enum keyword. An enumeration defines a set of named constants whose underlying type is an integer. You can define the integer assigned to each constant; otherwise, the enumeration sets each constant to a sequential integer value starting with 0.

For example, the business object state values are defined in an enumerated type as follows:

Public Enum EntityStateEnum
    Unchanged
    Added
    Deleted
    Modified
End Enum

In this example, the value of Unchanged is 0, Added is 1, and so on. Any variable declared to be of this enumeration type can be assigned to one of these defined constants.

A business object’s state is exposed by defining a property that gets and sets the object’s state. For example, an EntityState property could be defined as follows:

Private _EntityState As EntityStateEnum
''' <summary>
''' Gets the business object state
''' </summary>
''' <value>Unchanged, Added, Deleted, or Modified</value>
''' <returns>Value identifying the entity's state</returns>
''' <remarks></remarks>
Protected Property EntityState() As EntityStateEnum
    Get
        Return _EntityState
    End Get
    Private Set(ByVal value As EntityStateEnum)
        _EntityState = value
    End Set
End Property

Notice that the property uses the Protected keyword to ensure that it can be accessed only by classes that inherit from this base class. The setter uses the Private keyword to ensure that code outside of the class cannot modify the entity’s state.

You may want to define other properties that expose the object state in different ways. For example, it is common for a business object to have a Boolean IsDirty property that identifies whether an entity has been changed. Although the EntityStateEnum could be used to determine this, adding an IsDirty property provides a shortcut:

''' <summary>
''' Gets whether the business object has changes
''' </summary>
''' <value>True or False</value>
''' <returns>True if there are unsaved changes;
''' False if not</returns>
''' <remarks></remarks>
Protected ReadOnly Property IsDirty() As Boolean
    Get
        Return Me.EntityState <> EntityStateEnum.Unchanged
    End Get
End Property

This property does not have its own private backing variable. Instead, it uses the value of the EntityState property.

You also need code that manages the state. This is normally implemented as a method:

''' <summary>
''' Changes the state of the entity
''' </summary>
''' <param name="dataState">New entity state</param>
''' <remarks></remarks>
Protected Sub DataStateChanged(ByVal dataState As EntityStateEnum)
    ' If the state is deleted, mark it as deleted
    If dataState = EntityStateEnum.Deleted Then
        Me.EntityState = dataState
    End If

    ' Only set data states if the existing state is unchanged
    If Me.EntityState = EntityStateEnum.Unchanged _
       OrElse dataState = EntityStateEnum.Unchanged Then 
        Me.EntityState = dataState
    End If
End Sub

This code sets the state appropriately. This is not as simple as just assigning the state to the value passed in to the method, because some states cannot be changed. For example, if the state is already defined to be Added, further changes to the object leave the state as Added. And if the state is Deleted, it does not matter which other state it was; it needs to be deleted.

In your code, call DataStateChanged with a state of Added when the user creates a new item. Call DataStateChanged with a state of Deleted when the user deletes an item. Call DataStateChanged with a state of Modified whenever the user changes any of the data associated with an object. Because you defined all your object data with properties, you can add the call to DataStateChanged to the setter for each property, as described in the next section.

Building a base business object class keeps the majority of the housekeeping code out of the business object class itself and lets you focus on the unique business rules and business processing code required for the specific business object.

Building Along

For the Purchase Tracker sample application:

• Add a class project item to the business object Class Library project (PTBO) using the Class template.
  
  If you created your own class template using steps from Chapter 3, you can use your class template here.
  
  Name the class PTBOBase.
  
  If not already added by the selected template, add the standard set of regions to the class as described earlier in this chapter.
  
• Add documentation to the class using XML comments.
  
• Add the code defined in this section.

You now have an operational base business object class that ensures the business objects from all derived classes consistently handle their state. But at this point, the base class does not actually do anything. To make use of the base class, you need to inherit from it, as described in the next section.

Inheriting from the Base Business Object Class

After you create a base business object class, you use it by inheriting from it. Each business object class that needs to manage its state can inherit from the base business object class. The business object then has access to the properties and methods from the base business object class.

The Inherits keyword specifies that a class inherits from another class. Add the Inherits keyword to any business object class as follows:

Public Class Product
    Inherits PTBOBase

The class, in this case Product, then has all the properties and methods from the base business object class. You can easily see this by typing Me. somewhere within a property or method of the Product class. The Intellisense List Members box displays properties and methods of both the base class (PTBOBase) and the derived class (Product in this case).

To take advantage of the code in the base business object class, the derived classes can use the properties and methods of the base class. For example, when a property in the business object is changed, the code calls the DataStateChanged method in the base business object class to correctly set the business object state.

The code in the ProductName property provides an example:

Public Property ProductName() As String
    Get
        Return _ProductName
    End Get
    Set(ByVal value As String)
        If _ProductName <> value Then
            Dim propertyName As String = "ProductName"
            Me.DataStateChanged(EntityStateEnum.Modified)
            _ProductName = value
        End If
    End Set
End Property

NOTE: This code does not currently use the propertyName variable. It is used later when validation code is added in Chapter 7.

The Dim statement declaring the propertyName variable could be a Const statement instead since the property name does not change within the property.

The setter code first determines whether the value is the same as it was. If so, it does not reset it. If the value is indeed changed, the setter sets a variable for the property’s name. The DataStateChanged method in the base business object class is then called and passed a state of Modified. Finally, the property value is changed to the passed-in value.

In every derived class, modify each updatable property to include similar code. When any property value changes, the object is marked as modified. This ensures that each object is aware of its state so that it can react accordingly.

Building Along

For the Purchase Tracker sample application:

• Open the Product class in the Code Editor.
  
• Modify the Product class to inherit from the base business object class (PTBOBase), as demonstrated in this section.
  
• Modify the setter for each updatable property defined in the Product class, to include a call to DataStateChanged as shown in this section.

NOTE: ProductID is not updatable because its setter is private. So it should not call the DataStateChanged method.

NOTE: Recall that the InventoryDate is a Nullable type. Nullable types do not support the not-equal (<>) operator. So to check the value of the InventoryDate property against the value passed in, you need to use some additional code:

If (_InventoryDate.HasValue<>value.HasValue) OrElse _
     (_InventoryDate.HasValue AndAlso _
     value.HasValue AndAlso _
     InventoryDate.Value <> value.Value) Then
    Dim propertyName As String = "InventoryDate"
    Me.DataStateChanged(EntityStateEnum.Modified)
    _InventoryDate = value
End If

This code first determines if the property has a value. The code changes the value only if the HasValue changes or if it has a current value and that value has changed.

• Modify the Create method to reset the object’s entity state to Unchanged after it sets the property values. This ensures that the entity state tracks the user’s changes, not changes made to the properties when they are first populated.
  
  Add the following code as the last line of the Create method:
  
  prod.DataStateChanged(EntityStateEnum.Unchanged)

Overriding Base Class Members

Sometimes the derived class needs to modify the functionality of one of the base class members. When this is required, you can override the base class member by implementing the property or method in the derived class. When the property or method is called, the implementation in the derived class overrides the implementation from the base class.

For example, say that one business object requires some additional processing in the base class DataStateChanged method. To override this method, implement the method in the business object using the exact same method signature:

''' <summary>
''' Changes the state of the entity
''' </summary>
''' <param name="dataState">New entity state</param>
''' <remarks></remarks>
Protected Sub DataStateChanged(ByVal dataState As EntityStateEnum)
    MyBase.DataStateChange(dataState) ' Performs base processing

    ' Do unique code
    ...
End Sub

Notice that this code calls the base business object class to perform its processing and then performs its unique processing. It could instead perform its processing first and then call the base business object class. Or it can do all of its own processing.

Use overriding whenever the derived class needs its own implementation of a property or method in the base class.

Conclusion

What Did This Chapter Cover?

This chapter described how to build code in the business logic layer for your application. It provided information on defining properties, coding methods, using generics, and building a base business object class.

This chapter covered several real productivity enhancers:

1. Writing class documentation using the XML documentation feature makes it easy to create the class’s documentation. That documentation is then available in many places within Visual Studio, making it easier for you or your team to work with the class’s properties and methods.
   
2. Defining regions helps you focus on the code you are working on.
    
3. Using partial classes for generated code makes it easier to regenerate the generated code without impacting the custom code. 
    
4. Handling nulls using the generic Nullable structure simplifies working with value types and null values. 
    
5. Defining a Factory pattern method or class library method with the Shared keyword makes it easy to call the method, because you don’t need to create an instance of the class. 
    
6. Building a base business object class provides standardized processing for all your application’s business objects and significantly reduces the amount of housekeeping code required in each business object class.

The next chapter provides additional tools and techniques for working with classes.

Building Along

If you are “building along” with the Purchase Tracker sample application, this chapter added the basic code you need for your business object component.

Since the user interface from the preceding chapter does not yet reference any information in the business object component, running the application provides the same results as at the end of the preceding chapter.

The next chapter adds functionality and unit testing to the business object component of the Purchase Tracker sample application using some of the new Visual Studio 2005 tools and techniques.

Additional Reading

Cwalina, Krzysztof, and Brad Abrams. Framework Design Guidelines. Upper Saddle River, NJ: Addison Wesley, 2006.

This is an excellent book for any .NET developer. It provides general guidelines and many specific recommendations for handling everything from naming conventions to base classes to exceptions.

Lhotka, Rockford. Expert VB 2005 Business Objects, Second Edition. APress, 2006.

This book demonstrates how to build a framework for business objects that handles all the complex issues of .NET. It then shows you how to build Windows Forms, Web Forms, and Web Services interfaces on top of the objects, using all the data binding and other productivity features built into .NET 2.0 and Visual Studio 2005.

Richter, Jeffrey. “Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework.” MSDN magazine, November 2000.

This article provides details on the .NET garbage collector.

Try It!

Here are a few suggestions for trying some of the techniques presented in this chapter:

1. Add a SalesRep business object class to the business object Class Library project.
   
   Ensure that the class inherits from the base business object class. Add properties for name, employee number, and so on. Add a Create method using the same Factory pattern defined in this chapter. Add other methods as appropriate.
   
2. Add an exception handler class, such as SalesRepNotFound-Exception, to the SalesRep class code file using an exception class.
   
   Throw the exception in the Create method if the ID passed into the method is not the ID you hard-coded data for. 
    
3. Add several overloads for the Create method in the SalesRep class. 
    
4. Make one of the overloads obsolete using the techniques presented in this chapter.