Your first task in developing your component for ASP will be 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. The following functional areas are some examples of ways in which you can classify component functions.
Business objects rely on business rules. You should create them to fit a wide variety of business situations, but with enough specific functionality to be useful. For example, a Quantity on Hand component would be useful in a wide variety of business application scenarios. 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 need to aggregate components to a higher level. For example, rather than a Quantity on Hand component, you may choose to aggregate several components into an Inventory Control component. The problem with this level of aggregation, of course, is that there may be subcomponents in Inventory Control, such as Quantity on Hand, that would be useful in addressing business functions that are not limited to inventory control, such as a Sales Order function.
If you decide that there is some general function that many people writing ASP scripts will want to do, you should consider writing a utility component. Your utility components should offer a very high degree of flexibility, and should not rely on specific business rules. A utility can be applied to a wider variety of situations than, for example, a business component. Content Rotator and Counters are both good examples of utility components.
If you are developing an application that shares data you should consider merging that data into a single component. In the context of COM the term data object is used to mean any object that supports an implementation of the IDataObject interface. Implementations vary, depending on what the data object is required to do.
You should create presentation components in order to obtain information from users. 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 compose the presentation tier in a multitiered application. It is important that your application design include a presentation tier to provide adequate separation of your business components from particular physical implementations. The following scenario illustrates why presentation components are needed.
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 scenario you should create a presentation component that reads ASP requests and passes them on to the business component. Inserting the presentation layer allows your business component to remain unchanged when new clients are added. For more information on multitiered applications, see Advanced Web Application Development.