A problem with using the COM model for Web application components is that those components must be registered (typically using the regsvr32 tool) before they can be used from a traditional ASP application. Remote administration of these types of applications is often not possible, because the registration tool must be run locally on the server. To make matters more difficult, these components remain locked on disk once they are loaded by an application, and the entire Web server must be stopped before these components can be replaced or removed.

ASP.NET attempts to solve these problems by allowing components to be placed in a well-known directory, to be automatically found at run time. This well-known directory is always named /bin, and is located immediately under the root directory for the application (a virtual directory defined by Internet Information Services (IIS)). The benefit is that no registration is required to make components available to the ASP.NET Framework application -- components can be deployed by simply copying to the /bin directory or performing an FTP file transfer.

In addition to providing a zero-registration way to deploy compiled components, ASP.NET does not require these components to remain locked on disk at run time. Behind the scenes, ASP.NET duplicates the assemblies found in /bin and loads these "shadow" copies instead. The original components can be replaced even while the Web server is still running, and changes to the /bin directory are automatically picked up by the runtime. When a change is detected, ASP.NET allows currently executing requests to complete, and directs all new incoming requests to the application that uses the new component or components.

At its most basic level, a business component is just a class for which you can create an instance from a Web Forms page that imports it. The following example defines a simple HelloWorld class. The class has one public constructor (which is executed when an instance of the class is first created), a single String property called FirstName, and a SayHello method that prints a greeting using the value of the FirstName property.

Imports System
Imports System.Text

Namespace HelloWorld
  Public Class HelloObj
    Private _name As String

    Public Sub New
      MyBase.New()
      _name = Nothing
    End Sub

    Public Property FirstName As String
      Get
        Return(_name)
      End get
      Set
        _name = value
       End Set
    End Property

    Public Function SayHello() As String
      Dim sb As New StringBuilder("Hello ")
      If (_name <> Nothing) Then
         sb.Append(_name)
      Else
         sb.Append("World")
      End If
      sb.Append("!")
      Return(sb.ToString())
    End Function
  End Class
End Namespace

To compile this class, the C# compiler (Csc.exe) is run from the command line. The /t option tells the compiler to build a library (DLL), and the /out option tells the compiler where to place the resulting assembly. In this case, the /bin directory for the application is directly under the "aspplus" vroot of this tutorial, and it is assumed this command is being run from the sample directory, that is, ...\QuickStart\AspPlus\Samples\WebForms\Busobjs.

csc /t:library /out:..\..\..\..\bin\HelloObj.dll HelloObj.cs

For Visual Basic, the equivalent compilation command is:

vbc /t:library /out:..\..\..\..\bin\HelloObjVB.dll HelloObj.vb

For JScript, the equivalent compilation command is:

jsc /out:..\..\..\..\bin\HelloObjJS.dll HelloObj.js

The component is now available to any Web Forms page in the application that needs to use it. The following HelloObj.aspx example illustrates this functionality.

VB HelloObj.aspx [Run Sample] | [View Source]

Note the Import directive at the top of the page that specifies the namespace to include. Once the namespace is included using this directive, the class can be used from within the Web Forms page. Because the assembly is pre-loaded by the ASP.NET runtime, only a simple namespace import is required to make the component available. The following code example the Import directive.

<%@ Import Namespace="HelloWorld" %>

The classic use for an external component is to perform data access. This simplifies the code in your page, improving readability and separating your user interface (UI) logic from the system functionality. The following example demonstrates a simple two-tiered Web Forms page that uses a data access component to retrieve product information.

VB TwoTier.aspx [Run Sample] | [View Source]

The data access component takes a single parameter to its constructor specifying the connection string to the product database. The Web Forms page calls the component's GetCategories method to populate a drop-down list, and calls the component's GetProductsForCategory method to display the products for the category selected by the user.

A three-tiered application model extends the two-tiered scenario to include business rules between the UI and data access logic. This model allows UI developers to work with a higher level of abstraction rather than directly manipulating data through low-level data access component APIs. The middle business component typically enforces business rules and ensures that the relationships and primary key constraints of the database are honored. The following example uses the middle component to calculate a discount based on a two-digit Vendor ID entered by the client.

VB ThreeTier.aspx [Run Sample] | [View Source]