Speed of Development

[Simon Harvey]

Hi All,

I have a colleague that I wprk with that develops using ASP. I develop using
ASP.net.

He seems to make sites much faster than me and I am wondering if its because
of the two different technologies. I use codebehinds as standard

Does anyone else find that developing with ASP.net takes more work than asp.

I'm trying to avoid the conclusion that I'm just shit. Please help!

Simon

 

[Curt_C [MVP]]

"It depends"
ASP has the ease of being able to be tossed together fairly quickly, but
often it's very wrongly done (connections open, objects not destroyed, etc).
It also has the abiltity to not have to be compiled, this is good and bad.
ASP.NET, once you are familiar with the tools, is really just as quick. Down
the line as you start to reuse classes (etc) you will find you gain speed
too and pass him by.

 

[George Ter-Saakov]

In ASP.
Connection does not need to be closed,
Object does not need to be destroyed.

The ASP.NET gives you so many abilities that you want to utilize them all.
So it takes project to take more time. Since it has more features.

Also i bet that his ASP forms do not have any validations.

George.

 

[Curt_C [MVP]]

In ASP.

Connection does not need to be closed,
Object does not need to be destroyed.

not true really.... they will eventually go away, but in the meantime they
can, and will, eat major resources. It's always better to explicitly
close/kill them.

Also i bet that his ASP forms do not have any validations.

some of the ASP.NET ones are clientside though, and could be replicated in
ASP.

 

[Peter O'Reilly]

A programmer's level of experience is of much greater magnitude than which
development tool is used in terms of speed of development. (I'm talking
about same generation tools, e.g. not programming in assembler v. visual
basic)
Experience, along with how motivated your staff is, is even more so the case
within all that comprises a development project.

That said, I consider myself (equally) experienced with classic ASP and
ASP.NET. Comparing the two tools, in my experience using ASP.NET results in
much more rapid development due to intellisense, compiling, and true
debugging.
It's also a much more pleasurable experience.

 

[Alvin Bruney [MVP]]

dito

 

[George Ter-Saakov]

I was talking about ASP (not ASP.NET)
In ASP objects are released when they go out of scope.

And there is not need to close connections or destroy objects.

There was a bug though in earlier versions of ADO when due to the cyclic
reference between recordset and connection the connection will not be closed
even if it goes out of scope.

George.

 

[Peter O'Reilly]

There was a bug though in earlier versions of ADO when due to the cyclic

reference between recordset and connection the connection will not be closed
even if it goes out of scope.

It was never a bug. In theory what you write should be the case (and is ok
for a very light load), but practice tells me otherwise. Some RDBMS like
Oracle 8,9i or MS Access (Jet) are much less forgiving than SQL Server with
respect to not closing connections and recordsets. I have found this to be
the case with IIS 4, 5, 5.1. Load testing a classic ASP application will
make this immediately apparent.

Microsoft/MSDN docs have consistently parroted all along that ADO recordsets
and connection objects should be explicitly closed. The same is true, even
more so for the .Net framework's datareader and connection objects. For
instance, it is not possible to (re)use another datareader on the connection
without closing the first. The result is an exception raised/run time
error.

 

[Kevin Spencer]

And there is not need to close connections or destroy objects.

Hang on a second, George. Connections DO need to be closed, or disposed.
Setting objects to Nothing does Nothing. Closing Connections frees them up
for re-use.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[George Ter-Saakov]

I am talking about ASP. Not ASP.NET.
In ASP.NET connection must be closed.
In ASP it's not necessary.

George.

 

[George Ter-Saakov]

Yes. Do the test. I tested with MS SQL.
Create an ASP page (not asp.net)

<%
Dim con
Set con = CreateObject("ADODB.Connection")
con.Open "Provider=SQLOLEDB.1;Password=test;Persist Security Info=True;User
ID=test;Initial Catalog=test;Data Source=test"
%>

Hit it couple times then go to Enterprise Managment Managment/Current
Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for
you as soon as object goes out of scope.
MSDN is wirtten by people and usually not by developers who actually created
ADO.

BTW: It's practically impossible to write a clean ASP page which will close
connections in any case (exception, script timeout, ...)


George.

 

[Peter O'Reilly]

Hit it couple times then go to Enterprise Managment Managment/Current

Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for
you as soon as object goes out of scope.

Perhaps it's because you had to 2 Management consoles open - one for each
connection connection. A couple of times, I see that's definitive and
conclusive.

Reread my message. What did I write about SQL Server? What did I write
about load?

MSDN is wirtten by people and usually not by developers who actually created
ADO.

I sure hope their writing is done by people(and not trolls, like here).
Some may jibe that their marketing department writes them, but they are
written by their technical staff many of them (software engineers) who have
coded their various products including ADO.

 

[Kevin Spencer]

Ah, yes. That's exactly right, George.

--
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Andrea Williams]

ASP Best practices for our company say to "close the connections". We have
seen problems when connection are not explicitly closed, and that IS with
SQL Server. If connections aren't closed, OLEDB starts to return an
unspecified error after a while (depending on load) and the only way to get
rid of it is to reboot or change the conncetion string to ODBC. We found
the problem when converting to OLEDB from ODBC a while ago. ODBC doesn't
seem to care, but OLEDB does.

Andrea

Yes. Do the test. I tested with MS SQL.
Create an ASP page (not asp.net)

<%
Dim con
Set con = CreateObject("ADODB.Connection")
con.Open "Provider=SQLOLEDB.1;Password=test;Persist Security Info=True;User
ID=test;Initial Catalog=test;Data Source=test"
%>

Hit it couple times then go to Enterprise Managment Managment/Current
Activity/Process Info and you will see only one connection.
So it's not necessary to close connection in an APS page. ADO closes it for
you as soon as object goes out of scope.
MSDN is wirtten by people and usually not by developers who actually created
ADO.

BTW: It's practically impossible to write a clean ASP page which will close
connections in any case (exception, script timeout, ...)


George.