Compartir a través de

Component Types

  • Artículo

Your first task in developing a component for ASP is to determine the component's purpose. You can create components that perform a simple function, such as maintaining a page count, or a complex function, such as finding the probability of your company attaining a future value. You can think of your component as falling into one of the three logical tiers (presentation, business-logic, or data services) as outlined in The New System Architecture.

Presentation Components

Presentation components obtain information from users or return data that has been formatted. The ASP Request and Response objects are built-in objects that you can use to create your presentation components. For example, you might want to create an object that combines data access capabilities with security information so that you can provide your users with a consistent way of validating client access and input.

Presentation components comprise the presentation layer in a multi-tiered application. It is important that your application design include a presentation layer to provide adequate separation of your business components from a particular user interface. Inserting the presentation layer allows your business component to remain unchanged when new clients are added. The following scenario illustrates the necessity of presentation components.

You have developed an inventory control component that is called by a Microsoft ? Visual Basic ? client running on the Inventory Manager's desktop and by remote inventory warehouse managers using ASP. The Visual Basic client relies on a data structure that the Inventory Control object passes back. The .asp file cannot use this data structure, because its scripting language is designed only to interpret variant data. In this situation, you should create a presentation component that calls the business component and then formats the returned data structure for presentation to the browser.

For more information on multi-tiered applications, see Web Application Architecture.

Business Components

Business components are built on and act as instances of business rules. You should create them to fit a wide variety of business situations, but with enough specific functionality to be useful. For example, an inventory component would be useful in a wide variety of business applications. The following are examples of business rules you could build into your component:

  • Inputs: primary keys for product identification, quantity required, and so on.

  • Queries: pre-defined query strings for locating inventory.

  • Persistence/Transaction: update rules, such as when to decrement the inventory.

  • Security: who has rights to view and update the inventory.

You should create business components that are sufficiently broken up to provide meaningful functionality and sufficiently general to work as building blocks. Your organization, for example, might have performed a needs analysis to determine how to combine business rules into functional units. This aggregation should determine the methods and properties you define for your component. For example, rather than an Inventory component, you might choose to join several components into a Sales Order processing component.

Data Components

Storing your data in a data component provides a standard way for other components to access the data. For example, a Sales Order component could be used by both an Order Processing component and an Inventory Management component. If you are developing an application that shares data, you should consider merging that data into a single component.

Once you have determined the component's functionality, you will be prepared to refine the component design and implement. Implementation details are discussed in the Creating COM Components for ASP section.