Getting Started
  Introduction
  What is ASP.NET?
  Language Support

ASP.NET Web Forms
  Introducing Web Forms
  Working with Server Controls
  Applying Styles to Controls
  Server Control Form Validation
  Web Forms User Controls
  Data Binding Server Controls
  Server-Side Data Access
  Data Access and Customization
  Working with Business Objects
  Authoring Custom Controls
  Web Forms Controls Reference
  Web Forms Syntax Reference

ASP.NET Web Services
  Introducing Web Services
  Writing a Simple Web Service
  Web Service Type Marshalling
  Using Data in Web Services
  Using Objects and Intrinsics
  The WebService Behavior
  HTML Pattern Matching

ASP.NET Web Applications
  Application Overview
  Using the Global.asax File
  Managing Application State
  HttpHandlers and Factories

Cache Services
  Caching Overview
  Page Output Caching
  Page Fragment Caching
  Page Data Caching

Configuration
  Configuration Overview
  Configuration File Format
  Retrieving Configuration

Deployment
  Deploying Applications
  Using the Process Model
  Handling Errors

Security
  Security Overview
  Authentication & Authorization
  Windows-based Authentication
  Forms-based Authentication
  Authorizing Users and Roles
  User Account Impersonation
  Security and WebServices

Localization
  Internationalization Overview
  Setting Culture and Encoding
  Localizing ASP.NET Applications
  Working with Resource Files

Tracing
  Tracing Overview
  Trace Logging to Page Output
  Application-level Trace Logging

Debugging
  The SDK Debugger

Performance
  Performance Overview
  Performance Tuning Tips
  Measuring Performance

ASP to ASP.NET Migration
  Migration Overview
  Syntax and Semantics
  Language Compatibility
  COM Interoperability
  Transactions

Sample Applications
  A Personalized Portal
  An E-Commerce Storefront
  A Class Browser Application
  IBuySpy.com

  Get URL for this page

Working With Business Objects


Encapsulating logic in business components is an essential part of any real-world application, Web-based or otherwise. In ASP.NET, business objects are the building blocks for multi-tiered Web applications, such as those with a layer for data access or common application rules. This section demonstrates how to write some simple components and include them in your application's Web Forms pages.

The Application /Bin Directory

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.

Importing Business Objects

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.

VB

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" %>

By default, ASP.NET loads all assemblies from the /bin directory when the application is started. The assemblies to load are specifed through the configuration system. For details, see the Configuration Overview section. Additional assemblies can be imported into an application using configuration as well. For example:

<configuration>
    <compilation>
        <assemblies>
            <!--The following assemblies are loaded explicitly from the global cache-->
            <add assembly="System.Data"/>
            <add assembly="System.Web.Services"/>
            <add assembly="System.Drawing"/>
            <!--This tells ASP.NET to load all assemblies from /bin-->
            <add assembly="*"/>
        </assemblies>
    </compilation>
</configuration>
Note: Each assembly loaded from /bin is limited in scope to the application in which it is running. This means that peer applications could potentially use different assemblies with the same class or namespace names, without conflicting.

A Simple Two-Tier Web Forms Page

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 Simple Three-Tier Web Forms Page

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]

Section Summary

  1. The ASP.NET runtime finds business objects (local assemblies) in a well-known /bin directory, directly under the application root. The /bin directory offers the following advantages:

    • No registration required. No registration is required to make an assembly available to pages in the application. It is available by virtue of its location in the /bin directory. Compiled code can be deployed by simply copying or FTPing to this location.
    • No server restart required. When any part of an ASP.NET Framework application is changed (for example, when a DLL in /bin is replaced), new requests immediately begin execution against the changed file or files. Currently executing requests are allowed to complete before the old application is gracefully torn down. The Web server does not require a restart when you change your application, even when replacing compiled code.
    • No namespace conflicts. Each assembly loaded from /bin is limited in scope to the application in which it is running. This means that peer applications could potentially use different assemblies with the same class or namespace names, without conflicting.

  2. Classes in an assembly are made available to a page in the application using an Import directive within the .aspx file.
  3. Two-tiered applications simplify the code in a page, improving readability and separating user interface (UI) logic from system functionality.
  4. Three-tiered applications extend the two-tiered model to enable UI developers to work with a higher level of abstraction. The middle business component typically enforces business rules and ensures that the relationships and primary key constraints of the database are honored.


Copyright 2001 Microsoft Corporation. All rights reserved.

GoToMyPC | ASP.NET Knowledge Base