[thelist] FW: [aspadvanced] RE: The Future: ADO+ is part of ASP+ here is a n overview

[Scott Dexter]

If any of you are keeping an eye on ASP+ and the .NET stuff, here is some
spilling from Charles Carroll (webmaster of http://learnasp.com/ and all
those infernal overly specific email lists ;)) that encapsulates a number of
the bonuses in one spot. Worth the read.

oh, and he openly invites any of you CF-heads (dan? seth?) over to the CF vs
ASP debate list, apparently they're heavy on pro-ASP, light on pro-CF:
http://www.asplists.com/asplists/debatecfasp2.asp (but if you ask me,
choosing to engage in a "this vs that" mailing list may be an ulcer waiting
to happen)

sgd

-----Original Message-----
From: Charles Carroll [mailto:darthcarroll at asplists.com]

someone else said:
----
        The obvious question: is ADO+ simply a more powerful, functional,
and intelligent - and therefore more expensive - way to work with
Recordsets? I see where you mention scalibiliy a number of times below, but
its not clear if, you are talking scalibiliy as regards (ADO recordsets vs.
ADO+ Datasets) or (ADO+ Datasets and all other structures).
----

ADO recordsets are 
=> HEAVY objects (high memory footprint)
=> NOT Agile and NOT free-threaded unless disconnected and using certain
obscure drivers and conditions
     see: http://msdn.microsoft.com/workshop/server/asp/asptips.asp
=> every cell/row/column datapoint is a heavy variants
=> built on Iunknown and bloated COM glue
=> Had tons of expensive and flexible (read bloated) methods and properties
designed to interface with 10-15 year old ODBC drivers and modern drivers. 
=> Almost every method and property was tightly coupled to the DRIVER, so
method speed was always as slow as weakest driver code

Arrays were lighter 

and strings were even lighter

ADO+ datasets are:
=> LIGHT objects built from IL with small memory footprint
=> Freethreaded and Agile
=> every cell/row/column datapoint is a light strongly typed variable
=> built from very light IL and CLR glue
=> only talks to old drivers for initial connects and data transfers back
ONLY so has lightweight sort, filter and other methods that allow speedy
manipulation of datasets a
=> Since those methods talk to memory structures, not disk, server cursors,
etc. speed is LIGHTNING. These operations are UNCOUPLED (not even loosely
coupled) to the drivers.

Of course Arrays are lighter 

and strings are still lighter.


But recordset weighed 100 - 150 x as much as same data in array. And since
it was not agile putting it in any session o application scope was
scalability suicide, see: Connections would effectively limit all database
activity through one overworked connection with thread affinity. see: 
http://www.learnasp.com/advice/dbsessionapp.asp
and
http://www.learnasp.com/advice/threads.asp

Datasets weight slightly more than arrays OR strings and it is does not
cause scalability nightmares.

Arrays are lighter and strings are lighter BUT Datasets are pretty light.
Only the "connect" and "transfer" back statements are heavy. Other methods
are extremely lightweight and uncoupled to old techmology. 

--

The connection object, command object are not coupled to a recordset object.
The ADO+ Framework objects don't support anything resembling a recordset so
the connection and command object are not attached to a boat anchor.

Since VBscript is gone and all ASPX pages (even ones created with Notepad)
are compiled as 
==> free-threaded agile objects <==- whether the page language is VB,
C-Sharp or one of the other IL/CLR languages like:

Here is a list of some of the available non-MS languages that can build ASPx
pages:
Perl (http://www.activestate.com/.net) 
Python (http://www.activestate.com/.net) 
Cobol (http://www.adtools.com/info/whitepaper/net.html) 
Component Pascal (http://www.plasrc.qut.edu.au/ComponentPascal/) 
Eiffel (http://www.eiffel.com/doc/comtech/) 
Haskell (http://haskell.cs.yale.edu/ghc/) 
Mercury (http://www.cs.mu.oz.au/research/mercury/) 
APL (http://www.dyadic.com) 
Scheme (http://rover.cs.nwu.edu/~scheme/) 
SmallTalk (http://www.qks.com/) 
Oberon (http://www.oberon.ethz.ch/lightning/) 
Standard ML (http://research.microsoft.com/Projects/SML.NET/index.htm)

These compiled page objects can even be inherited, subclassed., and have
their methods over-ridden by pages in different languages: Fujitsu cobol
pages can inherit C# or VB compiled objects and change their implementation
or vice-versa.

Then these light scalable agile objects can be placed in application or
session state. Some notes:
a) session variables are accesible from every machine in a webfarm 
b) cookieless sessions are easy and cheap (believe it or NOT one config.web
ASCII file modification and all your pages transparently emit GUIDs without
harms to your POSTs and GETs and no changes in your pages.
http://www.aspng.com/quickstart/aspplus/doc/stateoverview.aspx

The only caveats are:

=> Of course anything in session variables lives longer than the users stay.
You could have 50 users on your site and 150 sessions which is WASTE but it
is much cheaper than the old days. But it is not free.

http://www.aspng.com/quickstart/aspplus/doc/applications.aspx

Global.asa is replaced by global.asax with 14 events instead of 4 including
the ability to participate in the whole request life-cycle such as mucking
with EVERY page IF WANTED before and after it is served and before it
arrives at user browser.
http://www.aspng.com/quickstart/aspplus/doc/globalasax.aspx

HOWEVER IF your purpose is CACHING, ASP+ has several better ways to cache:

Caching any kind of browser output (XML, a commonly accessed database query,
any part of the browser stream including images, etc.) is not a
code-intensive task anymore. 
Tasks like "the worlds fastest listbox" @ 
http://www.learnasp.com/learn/speedappdata.asp are now easy and 90% of the
code is unnecessary replaced by simple caching 
directives. http://www.aspng.com/quickstart/aspplus/doc/cachingoverview.aspx

gives an overview but here is a high-level summary.
a. 
A page that hits a database that was accessed by 5,000 users for example in
1 minute could only be cached by some code that carefully built strings,
placed in app vars and managed all that. 

Now a simple cache directive i.e. "Cache for 1 minute" could be placed on
the page and 5,000 users would get serious speed. The first user renders the
page, the other 4999 users that minute get that cached page. 

<%@ OutputCache duration="240"%>
This directive means the HTML for the page is remembered after first request
for 240 seconds. Even if a page reads XML data, scrapes websites, does 12
database reads only the first user invokes the code and for 239 more seconds
subsequent users get HTML without all the code activity.

EVEN IF PAGE WAS INVOKED VIA POST AND/OR GET ASP+ keeps many relevant
independent caches if necessary transparent to the person coding the page.

b. 
Fragment caching is possible too. If the above page had several database
reads, several website scrapes and had some customized content for a user
directives could be placed that cache one of the database segments for 1
hour, another for 10 minutes, the scraper data for 3 minutes of granularity
and leave the user-driven customized component alone. 
c. 
Any cache can be tied to a file resource, if the file date/time changes, the
cache is dirtied and rebuilt. 
d. 
Any cache item (like a business object) that is created by a developer can
be marked with a cost so that if ASPNG has to remove items from the cache to
conserve memory it doesn't throw items out that are expensive to rebuild
time-wise. You know your resources and bottlenecks so these hints you supply
keep the system from removing your cached data that is hard to rebuild. 

Look at:
http://www.aspng.com/learn/dbtable.aspx
for an example of simple output caching.

Sessions can persist a machine reboot ONLY IF IF IF you adjust config.web
settings so sessions are stored to a backend database (SQLserver, Oracle,
whatever) transparently to the code. Otherwise sessions leave upon timeout.

Of course sessions and apps are only one of the tools a programmer has to
attain raw speed and high scalability in a VERY scalable way. HTTP Handlers
will blow your mind. ISAPI speed/power and low-level access. High-level
declaritive elegance when writing.
http://www.aspng.com/quickstart/aspplus/doc/httphandlers.aspx

Writing NT services is trivial and free-threaded with Notepad and VB:
http://www.aspng.com/quickstart/howto/doc/SimpleService.aspx

ITS A WHOLE NEW WORLD!!!!!