COM versus Oracle Stored Procedures



We are currently in the requirements phase of our project and will be in 

design soon.  I am fairly new to ASP and COM.  I have been reading many of 

the Wrox publications in anticipation and even after reading the material 

I am unsure if we should put our business logic and SQL in COM or Stored 

Procedures in Oracle.



From the Windows DNA book, the theory is that business logic should be 

stored on the application server, not in the database.  This separates the 

business logic from the database, allows for better optimization of the 

tiers, allows the database to undergo changes with minimal impact to the 

application logic, and changes to application logic are all made in one 

place -- the application server.



From the ASP Data Access book, the theory is that, whenever possible, 

stored procedures should be used to extract the fastest possible 

performance.  In addition, it will take less time to create stored 

procedures than to go through the thought process required for COM 

development -- resulting in less development time.



So:

- The manager wants it coded quickly (stored procedures)

- The client wants it coded quickly (stored procedures)

- The client wants it to run quickly (could be either)

- The client wants a good first-version foundation (COM)

- The developer wants to build the app to ease maintenance & future 

expansion/changes) (COM)



Since managers and clients are frequently under pressure to meet 

unrealistic deadlines :) and the benefits of COM are realized in the later 

stages of an application's life, it seems difficult to justify the COM 

solution at this time.  Yet my gut tells me that the COM solution is the 

right way to go.  Are there better (or additional) arguments for the COM 

solution, or are stored procedures the way to go in this case?



Thanks,

Sam

Why don't you use both?

I mean, I'm developing a intranet solution which uses ASP+COM+SQL

Server.

We use client objects (IE object + DTHML Controls) for the client part

and ActiveX objects for the server part. However, when we need to add or

eliminate data from the db, I use stored procedures that are called from

my ActiveX objects.

Hope this makes sense.



Luis Abreu



> -----Original Message-----

> From: Sam Samuelson [mailto:sam_samuelson@u...]

> Sent: sexta-feira, 23 de Mar=E7o de 2001 20:42

> To: ASP components

> Subject: [asp_components] COM versus Stored Procedures

>

> COM versus Oracle Stored Procedures

>

> We are currently in the requirements phase of our project and will be

in

> design soon.  I am fairly new to ASP and COM.  I have been reading

many of

> the Wrox publications in anticipation and even after reading the

material

> I am unsure if we should put our business logic and SQL in COM or

Stored

> Procedures in Oracle.

>

> From the Windows DNA book, the theory is that business logic should be

> stored on the application server, not in the database.  This separates

the

> business logic from the database, allows for better optimization of

the

> tiers, allows the database to undergo changes with minimal impact to

the

> application logic, and changes to application logic are all made in

one

> place -- the application server.

>

> From the ASP Data Access book, the theory is that, whenever possible,

> stored procedures should be used to extract the fastest possible

> performance.  In addition, it will take less time to create stored

> procedures than to go through the thought process required for COM

> development -- resulting in less development time.

>

> So:

> - The manager wants it coded quickly (stored procedures)

> - The client wants it coded quickly (stored procedures)

> - The client wants it to run quickly (could be either)

> - The client wants a good first-version foundation (COM)

> - The developer wants to build the app to ease maintenance & future

> expansion/changes) (COM)

>

> Since managers and clients are frequently under pressure to meet

> unrealistic deadlines :) and the benefits of COM are realized in the

later

> stages of an application's life, it seems difficult to justify the COM

> solution at this time.  Yet my gut tells me that the COM solution is

the

> right way to go.  Are there better (or additional) arguments for the

COM

> solution, or are stored procedures the way to go in this case?

>

> Thanks,

> Sam

Luis,

   Thanks for the response.  One of the books I am reading is about 

Windows DNA.  If I am developing a solution based on the principles of 

Windows DNA (which the COM solution would be), I have two reasons for not 

doing both.  Number one is that I want my tiers to be separate.  All of my 

business logic should be on the application server.  Any changes to my 

business logic will then be applied to the server code and will not affect 

the client or the database.  Reason number two is that I am tuning my 

database server to optimize disk and memory performance -- parameters the 

database needs to operate efficiently.  My application server is being 

tuned to maximize CPU and Network I/O usage.  If I am running code on the 

database tier, the resources the code needs will be fighting with the 

resources the database needs.



   Perhaps for a small database with low traffic performance tuning is not 

as critical, however I like the advantage of having all of the business 

logic in one place.  I feel like we will be in a much better position to 

handle changes, upgrades, increased volume, etc. if I am set up this way.  

However, my original question still stands:



It seems that COM has a bunch of long-term benefits, but takes longer to 

develop.  With management that sees short-term more clearly, are there any 

short-term arguments I can add to my case for COM?



Thanks,

Sam