Using a Visual Basic Component and an ASP Page

We will use the Products component from our DNA application and the VB6 UML book to generate product information for an HTML page. The first question we must ask is, "Is this component appropriate for doing this?" We talked about reusing components so the question is, "Does it make sense to reuse the Products component for this application?"

The Products component was originally built for a Visual Basic EXE order entry application. The service this component was to perform was to review, update and add product records by either using a recordset bound to a control or by using properties of the object.

In our ASP application, we want a user to be able to submit a request to view all of the products of a particular group. The information will be returned in a standard HTML table. This information is dynamic, so the table must be made for each request.

We could build an ASP page that calls a Visual Basic component, which calls the Products component. The Visual Basic component will then use this component to retrieve all of the products for all a particular category.

In this scenario, we would not need the part of our Products component that binds to interface components. We could though use the properties of our products component to get the information. Thus, the products component can be used for our purposes.

Another possibility would be to create a stored procedure. For an application like this, a stored procedure would be the usual choice, though it may not be the best choice. SQL Server 7.0 comes with a web wizard that converts a recordset into an HTML page. With a few modifications, you could use this wizard to build any HTML page you needed from the data. The problem with stored procedures is scalability. What if our web site becomes very popular and we start having hundreds of requests a second? Eventually, our server will reach a point where it will no longer be able to keep up with the requests to build web pages. Scaling databases can be done, but it is difficult.

Let us go back to our original solution, where we had a Visual Basic web component being called from the ASP page that called the products component. Let us place the Visual Basic web component and the products component on the web server. As the demand for the site increases, you can create a web farm; that is, you can use multiple identical web servers to share the load. Each web server will have the Visual Basic web component and the products component on it. This solution will easily scale to be as large as needed. Thus, using a Visual Basic component to build the HTML page makes sense. However, this still does not justify using the Products component.

The Products component calls a server component that then requests the data from the database. Our Visual Basic component could call the database directly and request the data from the database, or it could also directly call the server component for the data. With regards to efficiency, it is possible that calling the Products component, then calling the server component, which retrieves the data, is slightly slower than calling the database directly. The actual difference will depend on the system and the load on the system. There is one advantage, though, to using the Products component.

If, instead of having to create just one set of data, we had to write code to return hundreds of different data sets, writing directly to the database would fill our Visual Basic web component with code to connect and retrieve data from the database. We would need programmers who are experts in ADO and in using stored procedures. We would also be mixing our business services logic with our data services logic. The code could quickly become confusing and hard to maintain and upgrade. If there were a change in the database, it would mean we would have to change our Visual Basic web component. Thus, using the Products component means that the Visual Basic developer creating the component will not have to know anything about ADO and, furthermore, the web component will not be affected by changes to the database. You would have to perform tests comparing performance with and without the Products component to see if the difference in performance is significant. It is very likely that under heavy loads the difference will be very small between using the server component and directly connecting to the database.

Before I would make any decision, I would create small applications (prototypes) for all three methods (using the Products component, calling the server component directly from the web component and connecting directly to the database from the web component). I would then test each of the three solutions under various loads. Based on the performance of each solution, I would make my final choice for the project. Below we will show the code for the solution using the products component. The other two solutions could be written by making minor changes to this application, i.e. by just changing how the data is retrieved.

It is likely that if we were going to use the Products component, we would probably not use our original component. We only need to use the properties; all of the code for binding a recordset is excess code. In a production environment, we would probably reuse all of the code from the products component that is needed for the properties, and remove all of the code related to binding the recordset. Thus, we would reuse the code and not the component. Because I want to show how to use a Visual Basic component from an ASP page and not how to rewrite the Products component, I will only make a few modifications to the Products component so that it will work with this project. We will begin our project with the page that the user will use to make a request for product information.

The following sections will look quickly at the coding techniques involved in reusing a component in a different environment. If you are not familiar with coding in Visual Basic, you may find it advisable to skip to the section on 'The Future' towards the end of the chapter.

The Client HTML Page

We need a web page with a listbox listing all of the categories. The user selects a category and submits the form. The server will then return a list of all of the products in that category. The HTML page will appear as follows:

The code for this HTML page will look as follows:



<META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">




<FORM action=GetProductsByCategory.asp>


A Category</STRONG>





id=select1 name=select1 style="HEIGHT: 22px; WIDTH: 150px">



selected>Beverages Category</OPTION>



>Condiments Category</OPTION>



> Confections Category</OPTION>



>Dairy Products Category</OPTION>



> Grains/Cereals Category</OPTION>



> Meat/Poultry Category</OPTION>



>Produce Category</OPTION>



>Seafood Category</OPTION>


<P><INPUT id=submit1 name=submit1 type=submit value=Submit></P>





When the user selects a category and clicks on the button, a request will be submitted to an ASP page named GetProductsByCategory .asp in the same directory as the HTML page we just built. So, our next task is to build this GetProductsByCategory .asp page.

Was this article helpful?

0 0
365 Days Of Motivation

365 Days Of Motivation

Stop Wasting Time And Learn How To Stay Motivated. Finally! Discover How To Stop Your Mind From Wandering, And Upgrade Your Motivation. You Can Hack Your Motivation Levels, Allowing You To Take Your Life To The Next Level.

Get My Free Ebook

Post a comment