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 Design. Components for each of these tiers are briefly described below.
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.
Presentation components comprise the presentation layer in a multitiered 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 both 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 can not 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. The following diagram illustrates this scenario.
For more information on multitiered applications, see Web Applications: An Overview.
Business components follow 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:
You should create business components that are sufficiently granular to provide meaningful functionality and sufficiently general to work as building blocks. Your organization, for example, may have performed a needs analysis to determine how business rules will be combined 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 aggregate several components into a Sales Order processing component.
If you are developing an application that shares data you should consider merging that data into a single component. By storing your data in a data component you will provide 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.
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 Building Components for ASP section.