De verschillen tussen ASP en ASP.NET samengevat

Door Charles Carroll
3 februari 2003

ASP en ASP.NET stoelen wel op dezelfde principes, maar zijn qua aanpak radicaal anders. Hieronder vind je de belangrijkste verschillen op een rijtje.

Object ondersteuning

ASP

• ASP bevat zes objecten. De componenten zijn interface gebaseerd (niet object gebaseerd), en worden derhalve vaak componenten genoemd.
• De ingebouwde objecten in ASP kunnen uitgebreid worden met COM objecten of COM+ (inclusief transacties). De COM/COM+ objecten kunnen communiceren met ASP objecten, maar je kunt ook generieke objecten maken die ook bruikbaar zijn in andere soorten applicaties. ASP ondersteunt alleen de standaard COM/COM+ interface, en niet eventuele additionele interfaces.

ASP.NET

• Kan COM/ COM+ objecten gebruiken (maar er zijn betere alternatieven).
• Kan gebruikt worden om .NET objecten te maken met interfaces en overerving. Objecten kunnen gemaakt worden in verschillende talen, waarbij overerving van de ene taal naar de andere mogelijk is. Componenten kunnen gemaakt worden zonder ontwikkelomgeving, een teksteditor zoals notepad is al genoeg. Een ontwikkelomgeving is wel gemakkelijk, maar dus geen noodzaak.
• Kan van componenten SOAP listeners en proxies maken door slechts een aantal attributen in te stellen. Hiervoor is dus heel weinig werk nodig.
• Het hart van het .NET Framework en de basiscomponenten zijn niet gebonden aan Intel of Windows. Het hele Framework werkt op dit moment alleen op Windows, maar het hart van het Framework, de Common Language Runtime (CLR), en een grote hoeveelheid objecten werkt al op FreeBSD en MacOS 10.2.
• Het .NET Framework bevat alle faciliteiten die nodig zijn om een robuust commercieel product te maken in de orde van grote van Office 2000. .NET is een enorme bibliotheek met duizenden zelfdocumenterende objecten, die je programmatisch kunt vragen hoe ze gebruikt moeten worden. De objecten varieëren van browser interactie tot encryptie, GDI/GDI+, sockets en abstracties op een hoger niveau.
  De .NET Framework Class Browser 
  demonstreert het rijke object model dat beschikbaar is en hoe je zelf programmatisch toegang krijgt via reflectie.

Taal Ondersteuning

ASP

• 2 ingebouwde script talen (VBscript, Jscript) die niet gecompileerd zijn. Enkele 3rd party talen: Perlscript, Python, deze zijn echter niet zo robuust en hebben de neiging de server te crashen.

• 3 ingebouwde gecompileerde talen (heeft geen script talen): VB.NET (VB7), C# en JScript / JS.NET
• Als je echt iets cools wil zien, moet je eens kijken naar:
  Visual Inheritance dat toont hoe grafische ontwerpers kunnen werken aan een bestand en programmeurs aan een ander apart bestand.

Database Ondersteuning

ASP

• Database ondersteuning via ADO dat communiceert met ODBC en OLEDB databases. De meeste database weergave wordt gedaan m.b.v. recordsets en loops. De meeste database manipulatie vereist code die gekoppeld is aan een back-end database. Het is mogelijk dat de code niet werkt als drivers worden verwisseld en derhalve moet voorzichtig geschreven worden.

• Database ondersteuning via ADO.net dat communiceert met:
  ODBC en OLEDB databases, XML Streams, Binary Streams
  maar niet gekoppeld aan de onderliggende data bron, zodat verschillen tussen databases of andere data bronnen nooit het programmeermodel aantasten.
• Database weergave kan altijd zonder het gebruik van loops. Door het gebruik van sjablonen, gegroepeerde controls, Grids en vele andere declaratieve structuren, zijn loops niet meer nodig. Flexibiliteit is verzorgd, zodat de programmeur alle interactie tussen de sjablonen declaratief kan bepalen.
• Vergelijk:
  Display Table on Web Page met 
  Easy Grid Display from Access/OLEDB Databases of
  DataGrid and Column Binding
  om te zien hoe anders deze geweldige technologie is.
• of vergelijk:
  HTML List Box from Column met
  Dropdown Lists from Database of
  User Control: Simplifies Database Lists
  om te zien hoe veel voorkomende taken zijn vereenvoudigd en verbeterd met databases.
• Houd je hartmedicatie bij de hand als je DataGrid Events (Sort, Edit, Delete) leest. Probeer dat maar eens in ASP!

Schaalbaarheid

• Schaalbaarheid is gelimiteerd omdat 2 van de hoofd objecten (sessie, applicatie) niet schalen op webfarms. Deze objecten moeten vervangen worden door zelfgemaakte of commerciële objecten als die functionaliteit gewenst is op webfarm. Schaalbaarheid, multi-tier applicaties, en transactie systemen kunnen wel gemaakt worden, maar de programmeur heeft weinig gereedschap om hier een simpel klusje van te maken. Het is gewoon een lastige klus en de programmeur moet ervaring hebben met het maken van zulke systemen in het verleden om nu een effectieve te kunnen maken.

• Sessies en alle mogelijkheden werden gebouwd met webfarms in het achterhoofd en ondersteunen "web gardens" (1 computer met meerdere CPUs)
• Voor verschillende vormen van caching zie:
  Overzicht van caching in ASP.NET
  vermindert database toegang en executie van code dramatisch zonder dat er pagina niveau veranderingen nodig zijn.

Third party support

• Sommige essentiële COM componenten die nodig zijn om websites te maken (browser detectie, etc.) -- Simpel maar bruikbaar. Voor de meeste sites met complexe benodigdheden moet je veel COM componenten bouwen of kopen om taken te volbrengen.

• Veel minder third-party support nodig, omdat veel al in ASP.NET ingebouwd is. Veel fabrikanten van COM componenten maken inmiddels ook server controls voor ASP.NET.

Browser ondersteuning

• Browserneutraal, de programmeur moet alle verschillen tussen browsers zelf opvangen.

• Validatoren en ingebouwde componenten gebruiken browser-detectie om HTML weer te geven die zich consisten gedraagt in verschillende browseser. ASP.NET heeft vele mogelijkheden zodat controls de browser kunnen detecteren en de HTML heel anders genereren afhankelijk van wat de browser aan de pagina vraagt.

Uitvoer omgeving

• Nauw gekoppeld aan Internet Information Server (IIS).
• De ASP-engine is niet gedocumenteerd waardoor deze niet makkelijk uitgebreid kan worden. Je kunt alleen low-level ISAPI filters maken om taken te volbrengen die ASP niet makkelijk zal ondersteunen.
•  In ASP wordt een script gecompileerd wanneer de eerste persoon dat script opvraagt. Dit moet echter telkens opnieuw als script cache vol is en het script verwijderd is, of als de server opnieuw opgestart wordt.

• Opereert buiten IIS om er zeker van te zijn dat de infrastructuur van IIS niet nodig is, en ASP.NET dus met elke webserver zou kunnen werken.
• Zeer uitbreidbare en high-level objecten die HTTP Handlers genoemd worden, kunnen de meest complexe taken volbrengen zonder dat daarvoor de gehele ASP.NET infrastructuur overgeërfd hoeft te worden.
• De gecompileerde code van objecten en pagina's wordt bewaard op de harde-schijf, zodat de compilatie nooit opnieuw uitgevoerd hoeft te worden, totdat de broncode verandert.

Installeren

• Als een applicatie is gemaakt zitten de instellingen in de Windows Registry, de Metabase, MTS catalogs, en IIS. Overschrijven en kopiëren van een applicatie naar een andere server is een complex en vervelend klusje met slechts een aantal automatische tools. Component registratie wordt verricht m.b.v. verschillende software pakketten die door een systeembeheerder gedraaid moeten worden. Zie:
  Overzicht van het installeren en configureren van ASP.NET applicaties
  voor meer details.

• Enorm complexe applicaties slaan hun instellingen en componenten op in tekstbestanden. Het kopieren van deze tekstbestanden van server naar server is genoeg om de instellingen correct over te zetten op de andere server. Er zijn geen tools nodig voor component registratie, aangezien componenten geen registry entries nodig hebben en niet gecompileerd hoeven te worden voordat ze gekopieerd worden naar de server. Alle configuratie/beveiligings opties zijn opgeslagen in XML/tekst bestanden.

Versiebeheer

• Bij een nieuwe versie van componenten moet de server gestopt en herstart worden.
• Als nieuwe component versies geïnstalleerd worden, worden de oude versies vervangen.

• Als een component herschreven is om een nieuwe versie te krijgen, dan zal bij de eerstvolgende gebruiker die een pagina opvraagt de nieuwe versie gebruikt worden, in een nieuwe thread. De oude en nieuwe versies bestaan naast elkaar in het geheugen aangezien er een volledig draaiend component op een thread aanwezig is. Uiteraard zal het ASP.NET werk proces uiteindelijk alle gebruiker verzoeken eindigen die communiceren met het oude component zodat ze niet onnodig geheugen innemen.
• ASP.NET of andere programma´s kunnen elke versie van een assembly gebruiken aangezien .NET side-by-side executie van verschillende versies ondersteunt.

Stabiliteit

• De omgeving gaat er vanuit dat de code en bibliotheken nauwkeurig geschreven zijn, alle bugs gevonden zijn, en dat er tests onder zware load uitgevoerd zijn. Fouten in code of componenten of geheugen lekken veroorzaken daardoor dat het systeem steeds langzamer wordt, waardoor zachte of harde reboots nodig kunnen zijn.

• Het proces dat ASP.NET uitvoert (ASP.NET werkproces) gaat er vanuit dat alle componenten en code kunnen crashen, dat geheugen kan lekken, en slechte code kan bevatten (zoals bijvoorbeeld oneindige loops). Het ASP.NET werkproces merkt slechte code op, isoleert de thread die de code uitvoert, staat niet toe dat nieuwe code op dezelfde uitgevoerd wordt, en vernietigt vervolgens de thread en alle slechte code. Als code geheugen lekt, kan het ASP.NET werkproces een nieuwe instantie maken om nieuwe verzoeken uit te voeren. Ook hier wordt de lekkende thread vernietigt, zodat er geen reboot nodig is. Zie:
  Overzicht van crashbeveiliging in ASP.NET
  voor meer informatie. 

Debugging

• Debuggen alleen mogelijk met Visual Interdev. Tools zijn niet gedetailleerd en hebben daardoor beperkte mogelijkheid tot diep in het systeem kijken.
• Foutafhandeling heeft in alle talen flinke beperkingen. VBscript heeft On Error Resume Next en geen On Error Goto. JavaScript heeft try...catch, maar geen andere taal heeft dat.

• Krachtige debugging, milliseconde timing en profiling zijn ingebouwd. Dit kan gedaan worden zonder HTML. Zie:
  Debugging #2: Page Tracing/Timing
  voor een voorbeeld.
• Alle huidige paginaverzoeken kunnen achteraf opgeslagen en gecontroleerd worden. Zie:
  Application trace 
  voor een voorbeeld op je server (normaal gesproken moeten zulke dingen met een paswoord beschermd worden op je server zodat alleen programmeurs toegang kunnen krijgen).
• Debuggen kan ook met tools die niet aan een specifieke editor gekoppeld zijn.
• Foutafhandeling in de code is makkelijk omdat er veel mogelijkheden zijn voor foutafhandeling (ongeveer 8 x zoveel als voor ASP). De meeste talen ondersteunen try...catch en verschillende andere robuuste manieren van foutafhandeling.