OO overhead in ASP

[Tom]

I have been developing in VB since 3.0 but am new to ASP development. I am
taking the over the debugging and cleanup of an ASP project.

The ASP page creates VB COM objects for accessing data in a SQL Server
database. The details of SQL Server are hidden from ASP so that the back
end could easily be changed to another database platform. However, to
accomplish this, the original developer builds field definitions for ALL
fields in the table (with field names,, data type, etc) each time the COM
object is created. The ASP page simply passes in a list of fields and a
conditional for data retrieval.

I am concerned with the overhead of this approach. For every page hit, ASP
creates, uses, and destroys these COM objects. I am considering migrating
to a simpler approach; One option I'm considering is where the COM objects
determine field definitions as needed. The other option is to move these
table definition/SQL statement builder objects to application scope so that
they are only created once. However, I'm sure there are threading issues to
consider here.

Anyone found any general guidelines in this area through practice or know of
some articles on this subject?

[Trey]

Tom:

Why don't you build the database with all the tables and fields that are
needed once.

Then write your COM object as a wrapper around that database, to shield the
ASP pages from its complexities. The COM object will contain the business
rules. Use register your COM object with MTS.

Yes the ASP page will still "creates, uses, and destroys" the COM objects,
but that is normal and expected. HTTP, by nature, is stateless MTS will
"cache" the objects and help keep the memory clean. This will help promote
scalability. (MTS on one Server, IIS on a second server, Database on
a Third, etc...)

If the database needs to be changed from SQL Server to DB2, you just need
to change the COM object to recognise the new database (with the same tables,
fields, and data). The ASP pages will not need to be changed.

HTH


"Tom" <nospam@hotmail.com> wrote:
>I have been developing in VB since 3.0 but am new to ASP development. I
am
>taking the over the debugging and cleanup of an ASP project.
>
>The ASP page creates VB COM objects for accessing data in a SQL Server
>database. The details of SQL Server are hidden from ASP so that the back
>end could easily be changed to another database platform. However, to
>accomplish this, the original developer builds field definitions for ALL
>fields in the table (with field names,, data type, etc) each time the COM
>object is created. The ASP page simply passes in a list of fields and a
>conditional for data retrieval.
>
>I am concerned with the overhead of this approach. For every page hit,
ASP
>creates, uses, and destroys these COM objects. I am considering migrating
>to a simpler approach; One option I'm considering is where the COM objects
>determine field definitions as needed. The other option is to move these
>table definition/SQL statement builder objects to application scope so that
>they are only created once. However, I'm sure there are threading issues
to
>consider here.
>
>Anyone found any general guidelines in this area through practice or know
of
>some articles on this subject?
>
>

[Tom]

Trey,

The arrangement you describe is basically what already exists. The ASP
pages have little to no knowledge of the database, just knows some of the
field names when asking for some data. All the SQL server specifics are
isolated in the COM objects.

However, the site does not use MTS at this point. Therefore, we're not
getting any benefit from object caching and are creating all objects from
scratch when they are needed. The database table "objects" have field
definition objects for every field in the table that are created in the
table object's Class_Initialize method.

MTS may be the way to go; I haven't researched it much. How difficult is it
to switch to for a running site? You mention running MTS on a separate
server. At what point does this help performance since you have to marshal
data across machines?





"Trey" <nospamtcollier@vimata.comnospam> wrote in message
news:3b2e63a0$1@news.devx.com...
>
> Tom:
>
> Why don't you build the database with all the tables and fields that are
> needed once.
>
> Then write your COM object as a wrapper around that database, to shield
the
> ASP pages from its complexities. The COM object will contain the
business
> rules. Use register your COM object with MTS.
>
> Yes the ASP page will still "creates, uses, and destroys" the COM objects,
> but that is normal and expected. HTTP, by nature, is stateless MTS will
> "cache" the objects and help keep the memory clean. This will help
promote
> scalability. (MTS on one Server, IIS on a second server, Database on
> a Third, etc...)
>
> If the database needs to be changed from SQL Server to DB2, you just need
> to change the COM object to recognise the new database (with the same
tables,
> fields, and data). The ASP pages will not need to be changed.
>
> HTH
>
>
> "Tom" <nospam@hotmail.com> wrote:
> >I have been developing in VB since 3.0 but am new to ASP development. I
> am
> >taking the over the debugging and cleanup of an ASP project.
> >
> >The ASP page creates VB COM objects for accessing data in a SQL Server
> >database. The details of SQL Server are hidden from ASP so that the back
> >end could easily be changed to another database platform. However, to
> >accomplish this, the original developer builds field definitions for ALL
> >fields in the table (with field names,, data type, etc) each time the COM
> >object is created. The ASP page simply passes in a list of fields and a
> >conditional for data retrieval.
> >
> >I am concerned with the overhead of this approach. For every page hit,
> ASP
> >creates, uses, and destroys these COM objects. I am considering
migrating
> >to a simpler approach; One option I'm considering is where the COM
objects
> >determine field definitions as needed. The other option is to move these
> >table definition/SQL statement builder objects to application scope so
that
> >they are only created once. However, I'm sure there are threading issues
> to
> >consider here.
> >
> >Anyone found any general guidelines in this area through practice or know
> of
> >some articles on this subject?
> >
> >
>

[Ralph Carrasquillo]

Trey,
It's not entirely necessary to separate MTS on another server it all depends
on your sys usage. Another way is to have MTS running on your IIS server.
I believe Tom is right in pointing you in the com/mts direction migrating
from com to mts is not significant. There are alternative ways of sending
data across objects reduce overhead my favorite is in using XML. I think
the real overhead is in the creation of mult com objs that are not being
shared across by multiple request.

Ralph

"Tom" <nospam@hotmail.com> wrote:
>Trey,
>
>The arrangement you describe is basically what already exists. The ASP
>pages have little to no knowledge of the database, just knows some of the
>field names when asking for some data. All the SQL server specifics are
>isolated in the COM objects.
>
>However, the site does not use MTS at this point. Therefore, we're not
>getting any benefit from object caching and are creating all objects from
>scratch when they are needed. The database table "objects" have field
>definition objects for every field in the table that are created in the
>table object's Class_Initialize method.
>
>MTS may be the way to go; I haven't researched it much. How difficult is
it
>to switch to for a running site? You mention running MTS on a separate
>server. At what point does this help performance since you have to marshal
>data across machines?
>
>
>
>
>
>"Trey" <nospamtcollier@vimata.comnospam> wrote in message
>news:3b2e63a0$1@news.devx.com...
>>
>> Tom:
>>
>> Why don't you build the database with all the tables and fields that are
>> needed once.
>>
>> Then write your COM object as a wrapper around that database, to shield
>the
>> ASP pages from its complexities. The COM object will contain the
>business
>> rules. Use register your COM object with MTS.
>>
>> Yes the ASP page will still "creates, uses, and destroys" the COM objects,
>> but that is normal and expected. HTTP, by nature, is stateless MTS
will
>> "cache" the objects and help keep the memory clean. This will help
>promote
>> scalability. (MTS on one Server, IIS on a second server, Database
on
>> a Third, etc...)
>>
>> If the database needs to be changed from SQL Server to DB2, you just need
>> to change the COM object to recognise the new database (with the same
>tables,
>> fields, and data). The ASP pages will not need to be changed.
>>
>> HTH
>>
>>
>> "Tom" <nospam@hotmail.com> wrote:
>> >I have been developing in VB since 3.0 but am new to ASP development.
I
>> am
>> >taking the over the debugging and cleanup of an ASP project.
>> >
>> >The ASP page creates VB COM objects for accessing data in a SQL Server
>> >database. The details of SQL Server are hidden from ASP so that the
back
>> >end could easily be changed to another database platform. However, to
>> >accomplish this, the original developer builds field definitions for
ALL
>> >fields in the table (with field names,, data type, etc) each time the
COM
>> >object is created. The ASP page simply passes in a list of fields and
a
>> >conditional for data retrieval.
>> >
>> >I am concerned with the overhead of this approach. For every page hit,
>> ASP
>> >creates, uses, and destroys these COM objects. I am considering
>migrating
>> >to a simpler approach; One option I'm considering is where the COM
>objects
>> >determine field definitions as needed. The other option is to move these
>> >table definition/SQL statement builder objects to application scope so
>that
>> >they are only created once. However, I'm sure there are threading issues
>> to
>> >consider here.
>> >
>> >Anyone found any general guidelines in this area through practice or
know
>> of
>> >some articles on this subject?
>> >
>> >
>>
>
>

[Rodney Kendall]

For your application, there is no code changes whatsoever when you migrate
to MTS, unless you are using transactions around your objects - something
you are most likely not going to need unless you are performing a set of
financial transactions or other transactions that must all either succeed or
fail across several objects. To your ASP pages, the Server.CreateObject
call is still used, you merely need to drag and drop your objects from
Windows Explorer to a package you create within MTS. See Microsoft for
information about configuring MTS and creating packages.

Since you are not currently using MTS, let me STRONGLY suggest that you do
move your objects to MTS. MTS does cache your objects and allows for much
faster object instantiation (after the first load of the object into memory)
in addition to isolating your objects within packages in MTS instead of the
IIS address space.

Although it is possible to run MTS on a separate server, it does degrade
performance due to marshalling the objects across the network.

Tom <nospam@hotmail.com> wrote in message news:3b2fa680@news.devx.com...
> Trey,
>
> The arrangement you describe is basically what already exists. The ASP
> pages have little to no knowledge of the database, just knows some of the
> field names when asking for some data. All the SQL server specifics are
> isolated in the COM objects.
>
> However, the site does not use MTS at this point. Therefore, we're not
> getting any benefit from object caching and are creating all objects from
> scratch when they are needed. The database table "objects" have field
> definition objects for every field in the table that are created in the
> table object's Class_Initialize method.
>
> MTS may be the way to go; I haven't researched it much. How difficult is
it
> to switch to for a running site? You mention running MTS on a separate
> server. At what point does this help performance since you have to
marshal
> data across machines?
>
>
>
>
>
> "Trey" <nospamtcollier@vimata.comnospam> wrote in message
> news:3b2e63a0$1@news.devx.com...
> >
> > Tom:
> >
> > Why don't you build the database with all the tables and fields that are
> > needed once.
> >
> > Then write your COM object as a wrapper around that database, to shield
> the
> > ASP pages from its complexities. The COM object will contain the
> business
> > rules. Use register your COM object with MTS.
> >
> > Yes the ASP page will still "creates, uses, and destroys" the COM
objects,
> > but that is normal and expected. HTTP, by nature, is stateless MTS
will
> > "cache" the objects and help keep the memory clean. This will help
> promote
> > scalability. (MTS on one Server, IIS on a second server, Database on
> > a Third, etc...)
> >
> > If the database needs to be changed from SQL Server to DB2, you just
need
> > to change the COM object to recognise the new database (with the same
> tables,
> > fields, and data). The ASP pages will not need to be changed.
> >
> > HTH
> >
> >
> > "Tom" <nospam@hotmail.com> wrote:
> > >I have been developing in VB since 3.0 but am new to ASP development.
I
> > am
> > >taking the over the debugging and cleanup of an ASP project.
> > >
> > >The ASP page creates VB COM objects for accessing data in a SQL Server
> > >database. The details of SQL Server are hidden from ASP so that the
back
> > >end could easily be changed to another database platform. However, to
> > >accomplish this, the original developer builds field definitions for
ALL
> > >fields in the table (with field names,, data type, etc) each time the
COM
> > >object is created. The ASP page simply passes in a list of fields and
a
> > >conditional for data retrieval.
> > >
> > >I am concerned with the overhead of this approach. For every page hit,
> > ASP
> > >creates, uses, and destroys these COM objects. I am considering
> migrating
> > >to a simpler approach; One option I'm considering is where the COM
> objects
> > >determine field definitions as needed. The other option is to move
these
> > >table definition/SQL statement builder objects to application scope so
> that
> > >they are only created once. However, I'm sure there are threading
issues
> > to
> > >consider here.
> > >
> > >Anyone found any general guidelines in this area through practice or
know
> > of
> > >some articles on this subject?
> > >
> > >
> >
>
>