 |
| Classic ASP Basics For beginner programmers starting with "classic" ASP 3, pre-".NET." NOT for ASP.NET 1.0, 1.1, or 2.0 |
Welcome to the p2p.wrox.com Forums.
You are currently viewing the Classic ASP Basics section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
|
|
|
|

June 26th, 2004, 05:09 AM
|
|
Friend of Wrox
|
|
Join Date: Oct 2003
Posts: 463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Object oriented ASP.
Hi friends,
I am learning the object oriented aspects of ASP. In this way, I am trying to develop 3 tier applications with ASP.
The things I am going to do are :
1) a db class which will handle all db related operations - insert, update, delete, select, get count of records, check the existence of a record based on a condition and method to return the value of a field of a record etc. etc.
2) a class which handles all validation activities - simple format validations like - isemail, is null etc and simple range validations like is number between 1 and 10, is future date etc. etc.
3) A form class. This class will display a form
I am concerned about the speed if pages are done with the help of these classes. Some of my friends say that object oriented ASP is a bad approach and plain ASP is faster than it. They say that object creation and destruction is a costly operation and consume a lot of resources. They take the example of PHP which does everything through functions.
It is my experience that PHP codes execute faster than ASP.
I am very much confused now. When I move to OO ASP and spend a lot of time in designing classes, will I find it not useful and slow in the end ?
Have anybody did any work in the same direction ? Could you please share your experiences and opinions in this issue ?
Thanks
Madhu
|
|

June 26th, 2004, 06:58 AM
|
|
Friend of Wrox
|
|
Join Date: Jun 2004
Posts: 331
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Dear Madhu your friend are saying very right it wil slow the browsing speed bcuz one page need top two page include each time when it load to browser
Love 4 all
|
|

June 26th, 2004, 07:59 PM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
Hi there,
I don't agree with qazi_nomi on this one. First of all, I don't think that including files means that much of a performance hit. Sure, they need to be read, but after that they are cached for future requests.
But even then, it doesn't really matter. Including pages is not strictly reserved for class based programming. In "traditional" ASP pages it is also very common to include other pages: headers, footers, menus, functions pages with common functions used throughout the site are examples that come to mind. So, in both cases, include files are often necessary (I don't even want to think of the nightmare scenario of an ASP database driven Web site with *no* include files.)
So, back to other performance issues: I guess the usual answer is: it depends. Personally, I am inclined to believe that class based programming in ASP is not bad for performance. Objects are created all over the place in classic ASP as well, so why not add a few of your own. And by using nicely structured class files and definitions, you can avoid including long function pages that contain common functionality for the entire site; not just the topic you're dealing with. Instead, you define some common logic in one place, maybe include common a short list of common functions and that's about it. But again, I don't think it matters much whether you include 1 or 3 pages.
What does matter is context switching (switching between plain HTML and ASP code). If your class based application is, for example, outputting HTML to the Response object directly, you avoid the mix of many plain HTML blocks mixed with short ASP code blocks that outputs a variable's value. That will definitely benefit performance.
That said, I don't think you should worry about performance issues too much, especially not at this level. Often, bad performance is caused by bad programming. Unnecessary looping or recursion, getting 27,000 records from a database just to get a count, generally getting more data than required, using 7 connections and recordsets to get some related data, or getting data inside a loop for another recordset while you could accomplish the same with one recordset and a complicate query, etc etc are all problems that are far worse for performance than an include file.
So, if I were you, I'd stick to the class based approach if that is what you like. You'll probably write cleaner code than the spaghetti mess that classic ASP can be, and it's also easier to "upgrade" your knowledge to COM+ or ASP.NET.
In fact, if you are already doing some class design, you might as well take things one step further, and develop COM+ components in Visual Basic. They usually run faster than plain ASP (as they contain compiled code, and not interpreted script), and are not that difficult to create and use.
Does this help?
Cheers,
Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Little Acorns by The White Stripes (Track 10 from the album: Elephant) What's This?
|
|

June 28th, 2004, 01:12 AM
|
|
Friend of Wrox
|
|
Join Date: Oct 2003
Posts: 463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Thanks Imar for very useful suggestions.
I have decided to go ahead with the object oriented ASP.
Regarding the form class, I will store the entire HTML which creates form in a variable and then outputting them altogether. Eventhough it is slightly slow (it cannot display partial forms), I have no alternative.
By COM, do you mean to use Windows scripting components ? I fear then the page will not visible in browsers of other Operating systems like MAC, Linux etc. Am I correct ?
The same fear prevents me from using VB components. Or is there anything wrong with my knowledge of COM objects ?
|
|

June 28th, 2004, 02:11 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
With COM+ I was referring to COM+ Components created in Visual Basic or Visual C++ or any other COM+ compatible technology.
Since these components live on the server, the browser has nothing to do with it, so it doesn't matter what OS or browser your end user has.
Think about the ADO objects. You can create a Connection object like this:
Code:
Dim myConnection
Set myConnection = Server.CreateObject("ADODB.Connection")
This connection object lives on the server; the browser doesn't even know it exists. You can do the same with your own COM+ components, so you can do something like this:
Code:
Dim objEmployees
Dim rsEmployees
Set objEmployees = Server.CreateObject("MyProject.Employee")
Set rsEmployees = objEmployees.GetEmployeeList()
The GetEmployeeListing method inside the Employee class would then be responsible for creating a connection, opening it, getting the data from the database and returning the recordset to the client. Inside that method, you can add your Business Logic to determine who is allowed to do what, where to retrieve the information from etc etc. You could take this one step further, and see GetEmployeeListing as a true business logic method which delegates the database actions to another Database Layer class which does the actual retrieving of the records. For that, you'll need to create a database layer that can perform actions like ExecuteSqlGetRecordset, ExecuteStoredProcedure and so on. There are DALs available in some of the sample projects from Microsoft.
Since COM+ components are compiled code, they're supposed to run faster. And separate COM+ components can also be reused in other applications. Your Windows app could use the same GetEmployeeListing method to display a list of employees on a VB 6 Windows form or other application.
So, all in all, you can use COM+ objects without problems in the browser. You should, however, be aware that not every ISP will allow you to install custom components (in fact, most won't). But if you control your servers, that is not a real problem.
You may have mistaken COM+ at the server with COM+ at the browser. It's possible to use COM+ components and ActiveX in client side code in the browser as well. That type of code will indeed not be cross-browser. However, usually you don't need that functionality; the server can create the pages for you, and return them in a format that the browser understands.
Check out the following links for more info:
http://www.4guysfromrolla.com/webtech/040300-1.shtml
http://msdn.microsoft.com/library/de...l/vbmtsiis.asp
Cheers,
Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Crime In The City (Sixty to Zero Part I) by Neil Young (Track 2 from the album: Freedom) What's This?
|
|

June 28th, 2004, 02:34 AM
|
|
Friend of Wrox
|
|
Join Date: Oct 2003
Posts: 463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Quote:
|
You may have mistaken COM+ at the server with COM+ at the browser.
|
Yes. This is indeed the case. Earlier I had done a client side component to display time at browser. This was not cross-browser compatible and I had to later re-do this. I was still in that fear.
Eventhough I know VB, I have not designed a COM object. But I am fascinated by this . I have started exploring it further. Thanks Imar for this.
In ur opinion, which is best - com object with VB or Windows scripting component (wsh)?
Thanks very much.
|
|

June 28th, 2004, 02:48 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
COM+ objects with VB. They are compiled, so they run faster.
Windows Scripting Components suffer from the same problem as ASP pages and VBScript; although they offer you an object oriented approach, they are still interpreted and not compiled, so they do not run as fast as COM+ objects. For true speed, though, you could consider writing the objects in C++, but IMO, that's a whole different ball game.
If you decide to take the VB DLL route, I am sure this FAQ will come in handy:
http://authors.aspalliance.com/nothi...ngmn_96&aid=96
When you compile a DLL in VB and then use it in an ASP page, the DLL gets locked by IIS. This means you cannot recompile unless you restart IIS which is pretty time-consuming. By putting your DLL inside a COM+ package (as described in the FAQ) you can simply restart the COM+ application, and then recompile your DLL.
Cheers,
Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: No More by Neil Young (Track 10 from the album: Freedom) What's This?
|
|

July 2nd, 2004, 07:04 AM
|
|
Friend of Wrox
|
|
Join Date: Oct 2003
Posts: 463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Hello Imar,
Thanks for your helps in achieving my COM object.
One more doubt.
I have a method by name ExecuteManipulationQuery which requires a query to be passed to it. However, I am doing it like this.
There is a property by name Query. The method will access it and execute the query. So in the ASP page, it will just need to have following statements.
object.Query=<query>
object.ExecuteManipulationQuery
i.e. the method is called without any argument.
Another method is to define method such that it takes an argument. It will need only one line in asp
object.ExecuteManipulationQuery(<query>)
May I know which of this method is more efficient ?
Thanks
Madhu
|
|

July 2nd, 2004, 07:21 AM
|
 |
Wrox Author
|
|
Join Date: Jun 2003
Posts: 17,089
Thanks: 80
Thanked 1,576 Times in 1,552 Posts
|
|
I think theoretically, the second approach is faster. In the first scenario, you have two calls to the object: one to set the query property, and the other to execute the method.
However, personally, I would prefer the second solution. That allows you to re-read the SQL statement later. This is a bit how the ADO command object works. You can set a query string, and then call Execute to execute that query. Even after the call to Execute, you can still examine the CommandText property.
Speaking of the ADO Command object: aren't you recreating that object? Does ExecuteManipulationQuery do more than just execute that query?
Cheers,
Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Wish you dead by Curve (Track 3 from the album: Doppelganger) What's This?
|
|

July 2nd, 2004, 08:09 AM
|
|
Friend of Wrox
|
|
Join Date: Oct 2003
Posts: 463
Thanks: 0
Thanked 0 Times in 0 Posts
|
|
Dear Imar,
Thanks for your suggestion.
Currently, this method is just doing the thing which can be done by ADO command object. But I am going to expand it to include
1) The code to generate a random string key (which is needed when some cascaded insertions are needed. The insert query will return this key (which is not possible in ADO command object, I think)
2) The code check the uniqueness of some fields (and their combinations) and appropriately return an error code.
3) To prevent deletion of records incase one of the field is referenced in a record of another table as foreign key
Meanwhile, I need to pass a list of parameters to this object. They are to be used as parameters of stored procedure. I am using a collection (parameter list) for it. Then set that collection from ASP page. Is there any faster method ?
Thanks
Madhu
|
|
 |