By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
428,786 Members | 2,241 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,786 IT Pros & Developers. It's quick & easy.

ASP Classic Best Practices

P: n/a
Hi all,

i am an ASP developer with 1,5+ years experience. After sneaking around the
ASP Classic world for a bit i became a bit dissatisfied of my ASP code
practices so i'd like to have some advice from the advanced/pro users...
some advice that would help me to grow up!

I know that many (if not all) the stuff that was a hassle in ASP 3 has been
corrected in ASP.NET/VS.NET (which i'm studying) but ASP 3 will still be
around for a long time (at least for all the lifetime of Win2k3) so i think
it would still be worth knowing how to program the right way in ASP 3.

So here are my questions
- How do you design multi-tier web applications? What needs to go in the
Data/Business/Presentation layer? Otherwise (if 3 tier is overkill for you,
as it would be for the stuff i write) how do you architect your application?
Where do you put code, ect...?
- How do you access the db? Do you have customized classes for accessing the
data, retrieving recordsets?
- Do you have any datagrid class for displaying/editing/sorting data?
- Do you store db connections as an application variable?
- Some links to useful components (preferably free!)
- Any else?

Thank You very much for paying attention to this post.

Lorenzo
Jul 19 '05 #1
Share this Question
Share on Google+
18 Replies


P: n/a
In my previous post i forgot and important subject: error handling,
especially form processing error handling, user input validation, etc...

Lorenzo
Jul 19 '05 #2

P: n/a
> - Do you store db connections as an application variable?

NEVER!
Jul 19 '05 #3

P: n/a
> In my previous post i forgot and important subject: error handling,
especially form processing error handling, user input validation, etc...


I do as much validation as I can on the client side. This way, the user
gets feedback right away, instead of waiting for a round-trip to the server.
Also, this means less toll on your web server, particularly if your user
base consists of a large ratio of numbskulls (or if your forms aren't
designed very well :-).

However, I think it is important to also validate on the server side (for
format issues, in ASP; for data violations, in SQL Server). There should
never be a way for bad data to get into the system, and a cunning user can
usually find a way to bypass client-side validation.
Jul 19 '05 #4

P: n/a
Where do you put code, ect...?
- Option Explicit is the first thing after the language declaration
- Pre-processing code - getting the data from the database; updates;
inserts; deletes all go above the <HTML> tag, so redirecting is not an issue
when the db work is done.
- Presentation - that is, everything the user sees after getting the data -
goes between the <HTML>of course</HTML>.
- All javascript validations and instructions are collected into an array
and output as the last thing before the </HTML> tag. I have another post on
this subject, earlier in this group.
- Subs and functions local to the page go after the </HTML> tag.
- Subs and functions used throughout the app go into other files, such as
stringFunctions.asp, sqlFunctions.asp, etc etc etc, and are included as
needed immediately after the Option Explicit line.
- Because we specify IE5.5 as a minimum standard for our application,
behaviors are used whenever possible to limit the amount of code written in
every page.
- How do you access the db? Do you have customized classes for accessing the data, retrieving recordsets?
Customized classes? No. Wrapper functions? Yes. For instance,

GetRs conn, rs, sSQL, "[Somepage.asp].[Function1] Getting employee data<p>"
& sSQL

- creates the connection if conn.state <> 1
- creates the recordset if rs is not an object
- redirects to an "Oops" page if rs.state <> 1, displaying the error
message shown in the last parameter

CreateConnection objConnection:=conn, UseShape:=false

- accepts a connection object
- gets connection string for shape queries if true, vanilla OLEDB if false
- redirects to an "Oops" page if conn.state <> 1, displaying the error
message built from the connection's errors collection
- Do you have any datagrid class for displaying/editing/sorting data?
No.
- Do you store db connections as an application variable?
NO. NEVER. NOT EVER. ON PAIN OF DEATH. OR JUST PAIN. Let me be
completely unambiguous: NO.
- Some links to useful components (preferably free!)


JMail. http://www.dimac.net. Beats the hell out of CDONTS.
- Wm "agressively lazy" Morris
--
William Morris
Product Development, Seritas LLC
Jul 19 '05 #5

P: n/a
> JMail. http://www.dimac.net. Beats the hell out of CDONTS.

I don't think anybody ever suggested that CDONTS was any good. It was
deprecated for a reason (well, dozens of reasons, probably).

If you have access to SQL Server, I prefer xp_smtp_sendmail for sending
alerts, etc. This way, all mailing is controlled from one location, and it
is capable of sending alerts for database errors, ASP errors (500, 404, 403,
etc), and you can also schedule it to send daily, weekly emails to lists of
users, etc. You have a single stored procedure wrapped around this xp, and
you can call it from anywhere (stored procedure, directly from ASP, from a
job, etc).

Of course, you might have to rely on a COM, or CDO.Message object if you are
worried that xp_smtp_sendmail will ever fail... but that's easy enough to
set up. In the procedure that wraps the xp, just have an error trap that
uses sp_OACreate to send mail via jmail, CDO.Message, or some other object
to send the mail. You might also wish to send a NET SEND in this case, in
case it's the SMTP server and not the sending itself, or else have a backup
SMTP server available as well.

In any case, for more info about xp_smtp_sendmail, see www.aspfaq.com/2403
Jul 19 '05 #6

P: n/a
WIlliam Morris wrote:
...
- Do you store db connections as an application variable?


NO. NEVER. NOT EVER. ON PAIN OF DEATH. OR JUST PAIN. Let me be
completely unambiguous: NO.


care to elaborate on the issue(s) ?

--
William Tasso - http://WilliamTasso.com
Jul 19 '05 #7

P: n/a
William Tasso wrote:
WIlliam Morris wrote:
...
- Do you store db connections as an application variable?


NO. NEVER. NOT EVER. ON PAIN OF DEATH. OR JUST PAIN. Let me be
completely unambiguous: NO.


care to elaborate on the issue(s) ?


Again?

OK:

http://www.learnasp.com/learn/sessionoverview.asp
http://www.learnasp.com/advice/dbsessionapp.asp
http://www.learnasp.com/learn/globalproblems.asp
http://www.learnasp.com/learn/stateproscons.asp

HTH,
Bob barrows
Jul 19 '05 #8

P: n/a
Thanks Bob. I added three of those links to http://www.aspfaq.com/2053
(which should also help drive the point home for William).

care to elaborate on the issue(s) ?


Again?

OK:

http://www.learnasp.com/learn/sessionoverview.asp
http://www.learnasp.com/advice/dbsessionapp.asp
http://www.learnasp.com/learn/globalproblems.asp
http://www.learnasp.com/learn/stateproscons.asp

Jul 19 '05 #9

P: n/a
Good, I'll link to that from now on.

Bob

Aaron Bertrand [MVP] wrote:
Thanks Bob. I added three of those links to
http://www.aspfaq.com/2053 (which should also help drive the point
home for William).

care to elaborate on the issue(s) ?


Again?

OK:

http://www.learnasp.com/learn/sessionoverview.asp
http://www.learnasp.com/advice/dbsessionapp.asp
http://www.learnasp.com/learn/globalproblems.asp
http://www.learnasp.com/learn/stateproscons.asp


Jul 19 '05 #10

P: n/a
Aaron Bertrand [MVP] wrote:
care to elaborate on the issue(s) ?
Again?

OK:

http://www.learnasp.com/learn/sessionoverview.asp
http://www.learnasp.com/advice/dbsessionapp.asp
http://www.learnasp.com/learn/globalproblems.asp
http://www.learnasp.com/learn/stateproscons.asp

Thanks Bob. I added three of those links to
http://www.aspfaq.com/2053 >
Ahh, my mistake. IRTA 'connection strings' as opposed to 'connection
objects'.
(which should also help drive the point
home for William).


Thank you for you concern - much appreciated

--
William Tasso - http://WilliamTasso.com
Jul 19 '05 #11

P: n/a
Tnx to everybody who has partecipated in this thread!

Lorenzo
Jul 19 '05 #12

P: n/a
After retrieving data into a RecordSet, I used to iterate thru the RS and I
have even issued a GetRows into an array, but I now save it into an XML
structure and iterate thru its Nodes.

Putting data into an array makes maintenance a PITA because you have to
identify the columns using numbers, so visiting the page some days later
causes headaches.

here's what I do now:

set oXML = Server.CreateObject("MSXML2.DomDocument")
oRS.save oXML,1
' now close all ADO objects
set rows = oXML.selectNodes("//z:row")
rowCount = rows.length
for each row in rows
' use row.getAttribute("columnName")
next

Brian

"Lorenzo Bolognini" <lo*****@mysurname.net> wrote in message
news:Wm**********************@news2.tin.it...
Hi all,

i am an ASP developer with 1,5+ years experience. After sneaking around the ASP Classic world for a bit i became a bit dissatisfied of my ASP code
practices so i'd like to have some advice from the advanced/pro users...
some advice that would help me to grow up!

I know that many (if not all) the stuff that was a hassle in ASP 3 has been corrected in ASP.NET/VS.NET (which i'm studying) but ASP 3 will still be
around for a long time (at least for all the lifetime of Win2k3) so i think it would still be worth knowing how to program the right way in ASP 3.

So here are my questions
- How do you design multi-tier web applications? What needs to go in the
Data/Business/Presentation layer? Otherwise (if 3 tier is overkill for you, as it would be for the stuff i write) how do you architect your application? Where do you put code, ect...?
- How do you access the db? Do you have customized classes for accessing the data, retrieving recordsets?
- Do you have any datagrid class for displaying/editing/sorting data?
- Do you store db connections as an application variable?
- Some links to useful components (preferably free!)
- Any else?

Thank You very much for paying attention to this post.

Lorenzo

Jul 19 '05 #13

P: n/a
Why not make a client side cursor recordset and use it as a disconnected
recordset?

Just disconnect right after rs.open.

<%
Set rs = Server.CreateObject("ADODB.Recordset")
rs.CursorLocation = 3
rs.CursorType = adOpenStatic
rs.Open strSQL, ObjConn
Set ObjConn = Nothing
Do While Not rs.EOF
'What Ever
rs.MoveNext
Loop
rs.Close
Set rs = Nothing
%>

iterating an XML is expensive processing time.

-dlbjr

Discerning resolutions for the alms
Jul 19 '05 #14

P: n/a
Brian Staff wrote:
After retrieving data into a RecordSet, I used to iterate thru the RS
and I have even issued a GetRows into an array, but I now save it
into an XML structure and iterate thru its Nodes.

Putting data into an array makes maintenance a PITA because you have
to identify the columns using numbers, so visiting the page some days
later causes headaches.

You can use constants to save yourself those headaches:

rs.open (select username, userpassword from ..." ...
arResults = rs.GetRows
const cUserName = 0
const cUserPassword = 1

sUserName = arResults(cUserName, 0)
etc.

An array will outperform the XML Parser, so if you need performance, stick
with the array.

HTH,
Bob Barrows

Jul 19 '05 #15

P: n/a
dlbjr wrote:
Why not make a client side cursor recordset and use it as a
disconnected recordset?

Just disconnect right after rs.open.

iterating an XML is expensive processing time.

It will probably outperform a recordset loop (I've never tested this - it's
just my gut feeling), but an array will beat both handily.

Bob Barrows
Jul 19 '05 #16

P: n/a
I Agree! Just don't use the XML idea

--
-dlbjr

Discerning resolutions for the alms
Jul 19 '05 #17

P: n/a
Don't write it off so quickly. Performance is not an issue for me - it's
plenty fast enough.

Having my data in an XML structure now allows me to separate the tiers quite
easily.

The data tier reads the data and creates an XML structure. It then passes it
off to the business tier who iterates thru it creating a XHTML structure who
then passes it to the GUI tier where it may, depending on the client,
transform it using XSL before sending it to the end user.

It works for me<g>.

Brian

"dlbjr" <do******@do.u> wrote in message
news:ee**************@TK2MSFTNGP11.phx.gbl...
I Agree! Just don't use the XML idea

--
-dlbjr

Discerning resolutions for the alms

Jul 19 '05 #18

P: n/a
Brian Staff wrote:
Don't write it off so quickly. Performance is not an issue for me -
it's plenty fast enough.


I didn't mean to recommend that it be "written off". I was merely commenting
on the relative performance.
I use xml documents extensively, mainly for passing structured data between
processes, such as from server-side to client-side code.

Bob Barrows

Jul 19 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.