ASP Classes vs COM

[CJM]

For the majority of my work, I just use plain ASP. On the rare occasion that
I am doing something intensive that does require user interaction I might
create a COM component (ie where performance gain outweighs the overhead of
COM).

A simple Rule-of-Thumb. I imagine this is fairly common practice... (I hope
it is, at least).

However, I'm curious about VBScript Classes. I would have imagined that if a
page was complex enough to merit defining and creating your own
classes/objects, that COM would be appropriate...

In which case, when and how do people use VBScript Classes?

Thanks

Chris

 

[Cowboy \(Gregory A. Beamer\)]

I have played with them, but find that the main reason for going to classes
warrants creating a reusable component. I have yet to see an app where I
felt a VBScript class would be the right option. I am not saying that the
app does not exist, just that I have yet to see one.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

**********************************************************************
Think Outside the Box!
**********************************************************************

 

[Chris Barber]

They are useful to encapsulate functionality and provide intellisense for
the functions etc. but they can't be easily persisted in the session state
so their usefulness in that sense is limited.
It's also true that Interdev doesn't give you intellisense for include files
that contain VBScript classes so the usefulness of encapsulating groups of
functions is also reduced by this.
In contrast, Windows Script Components provide all the benefits of COM
components but as a scripted solution. Hence, you can change the component
without recompilation.
I have used them in the past where custom DLL components were not allowed on
the web server and they are very good but severely hampered by their
implementation and lack of development tools that can work with them
properly. Usually, I get a VBScript class working and then move it into a
WSC if I feel they are important enough. A classic example in my case is a
script wrapper for ADO that I have used for some time now. Since a lot of my
ASP is DB based then I use this particular component a lot.

These are just *my* opinions though so don't read too much into them.

Chris.

For the majority of my work, I just use plain ASP. On the rare occasion that
I am doing something intensive that does require user interaction I might
create a COM component (ie where performance gain outweighs the overhead of
COM).

A simple Rule-of-Thumb. I imagine this is fairly common practice... (I hope
it is, at least).

However, I'm curious about VBScript Classes. I would have imagined that if a
page was complex enough to merit defining and creating your own
classes/objects, that COM would be appropriate...

In which case, when and how do people use VBScript Classes?

Thanks

Chris

 

[Chris Barber]

Also, MS did some testing with ASP vs. COM speed of execution and certainly
with IIS 5.0 and above, the script solutions are almost as fast as the VB
compiled solutions although not nearly as fast as C++ components which don't
require the VB runtimes to be loaded up.

Chris.

For the majority of my work, I just use plain ASP. On the rare occasion that
I am doing something intensive that does require user interaction I might
create a COM component (ie where performance gain outweighs the overhead of
COM).

A simple Rule-of-Thumb. I imagine this is fairly common practice... (I hope
it is, at least).

However, I'm curious about VBScript Classes. I would have imagined that if a
page was complex enough to merit defining and creating your own
classes/objects, that COM would be appropriate...

In which case, when and how do people use VBScript Classes?

Thanks

Chris

 

[CJM]

I remember seeing that paper I think...

Cheers

Chris

 

[Michael D. Kersey]

Also, MS did some testing with ASP vs. COM speed of execution and certainly
with IIS 5.0 and above, the script solutions are almost as fast as the VB
compiled solutions

<snipped>
The script solution was _faster_, especially when there were many users.
See Figure 9 of Microsoft's Nile Benchmarks at
http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp?frame=true

The full article title is "Architecture Decisions for Dynamic Web
Applications: Performance, Scalability, and Reliability" by Gregory
Leake, Microsoft Corporation, November 2000

 

[Chris Barber]

That was the one!

Thanks for the link.

Chris.

Also, MS did some testing with ASP vs. COM speed of execution and certainly
with IIS 5.0 and above, the script solutions are almost as fast as the VB
compiled solutions

<snipped>
The script solution was _faster_, especially when there were many users.
See Figure 9 of Microsoft's Nile Benchmarks at
http://msdn.microsoft.com/library/en-us/dnnile/html/docu2kbench.asp?frame=true

The full article title is "Architecture Decisions for Dynamic Web
Applications: Performance, Scalability, and Reliability" by Gregory
Leake, Microsoft Corporation, November 2000

 

[arachno]

Well, using Classes is good stuff when you represent your webware project as
somethign object oriented, say manipulating with web site as with collection
of objects. Nothing hard and saves you thousands hours of work...

ev.

 

[Adrian Forbes [ASP MVP]]

The main thing against ASP classes is that you can't store them in the
Session or Application.

So with that in mind classes are good where you want to encapsulate
functionality in an object-orientated fashion. You can use functions etc to
abstract functionality, but it is procedural rather than object-orientated.

Let's say instead of working with a recordset you want to create an ASP
class that represents a customer, or whatever, which lets you use the
object's properties and methods in a COM-way. It is a half-way house in
that it gives you the object based COM features but without COM
hassle/overhead....but limited to scripts where all logic is on the one page
of course.

How much you use them depends on how much you like to work with objects
rather than recordsets, strings of XML, Request variables etc.