Announcement

**Andreas Kosch** · 06.01.2003, 08:15

Hallo,

>Vor allem w�re ich an technischen Unterschieden interessiert.

eine webbasierende Anwendung ist zwangsl�ufig Zustandslos, d.h. die Software muss dem Anwender vorgaukeln, als ob das Programm "am St�ck durchl�uft". Das f�hrt dazu, dass der Zustand zwischen den einzelnen Abrufen der Seiten entweder auf der Client-Seite (Bsp. Cookies) oder auf der Server-Seite (Bsp: Datenbank) zwischengespeichert werden muss. Aus diesem Grund ist eine Webanwendung zwangsl�ufig komplexer und schwerf�lliger zu entwickeln.

Es gibt in der letzten Zeit verschiedene Ans�tze, wie diese Komplexit�t vor dem Entwickler verborgen werden kann (siehe IntraWeb von Delphi 7 beziehungsweise Web Forms von .NET).

**Gesine Kuhlmann** · 08.01.2003, 01:14

Hi,

Theoretisch gibt es keine Unterschiede ;-)

Um komplexerere, webbasierte Anwendungenen wirklich zu realisieren lautet jedoch z.Zt. das einzige g�ltige Stichwort JAVA.

Voteil:
- umfassende Plattformunabh�ngigkeit.

Nachteil:
- bedingter Funktions- und Leistungsumfang im Vergleich zu nativen CS-L�sungen.

Gruss
Gesin

**Andreas Kosch** · 08.01.2003, 08:01

Hallo,

>..Theoretisch gibt es keine Unterschiede ;-)

diesen Satz kann man - bei allem Respekt - so nicht stehen lassen. Nehmen wir einmal eine triviale Anwendung: Der Anwender hat ein Eingabefeld, eine Listbox und einen Button. Immer dann, wenn er auf den Button klickt, soll der momentan im Eingabefeld stehende Wert in die Listbox aufgenommen werden.

Bei einer Windows-Anwendung mit einem TForm ist die Sache ganz einfach - die neue Zeichenkette wird einfach angef�gt.

Bei einer Web-Anwendung (Benutzer klickt einen Button in seinem Browser an) l�st diese Aktion jedes Mal einen neuen Seitenabruf aus, so dass es grunds�tzliche technische Unterschiede gibt: 
a) irgend eine Stelle muss sich merken, was vorher in der Listbox stand, 
b) irgend eine Stelle muss die neue Zeichenkette anh�ngen, und 
c) irgend eine Stelle muss den neuen Zustand an den Browser zur�ckliefern.

Damit "irgend eine Stelle" nicht mit "der Entwickler" ausgetauscht werden muss, sind moderne Systeme cleverer. Am VB.NET-Beispiel der Web Forms von .NET sieht das zum Beispiel so aus, um das oben beschriebene Verhalten umzusetzen:

a) Windows-Anwendung: Der Entwickler tippt nur die rot hervorgehobene Zeile ein:
<pre>Private Sub ButtonAdd_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles ButtonAdd.Click
  ListBox1.Items.Add(TextBox1.Text)
End Sub</pre>

b) Web-Anwendung: Der Entwickler tippt nur die rot hervorgehobene Zeile ein:
<pre>Private Sub ButtonAdd_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles ButtonAdd.Click
  ListBox1.Items.Add(TextBox1.Text)
End Sub</pre>

Das ist kein Tippfehler - die beiden Wege sind wirklich identisch, da sich ein Web Form �ber die intergrierten ViewStates hinter den Kulissen um die Zustandsverwaltung k�mmert und so eine "Anwendung am St�ck" simuliert.

Zwar l�uft ASP.NET nicht auf jedem Betriebssystem, aber es gibt ja Einsatzf�lle, bei denen Effektivit�t gegen�ber der Wahlfreiheit des Betriebssystems Vorrang hat. Und da Web Form alias ASP.NET auch bei Delphi.NET zur Verf�gung steht, m�ssten wir als Delphianer noch nicht einmal die geliebte Sprache wechseln:

<html> 
<h1>ASP.NET und Delphi .NET (Preview)</h1>
<script
language="Delphi" runat="server">
  procedure
ButtonClick(Sender:
System.Object; E: EventArgs); 
  begin 
    ShowInputText.Text := EditInput.Text; 
  end;
</script>
<body> 
<form runat="server"> 
<asp:textbox id="EditInput" runat="server"/> 
<asp:button text="Los gehts!" OnClick="ButtonClick"
runat="server"/> 
</form> 
<asp:label id="ShowInputText" runat="server"/> 
</body> 
</html>

P.S: Auch der Delphi.NET-Programmcode wird von .NET nach jeder �nderung am Sourcecode automatisch beim ersten Abruf der Seite in eine DLL (.NET-Assembly) compiliert. Sobald der HTTP-Request-Aufruf f�r diese ASPX-Seite beim IIS eintrifft, parst die ASP.NET-Laufzeitumgebung den Inhalt dieser Datei und beauftragt den in der XML-Konfigurationsdatei Web.config festgelegten Provider (hier Delphi), daraus eine Page Class zusammenzubauen. Jedes Verzeichnis kann �ber eine eigene Web.config eine andere Sprache anmelden, in meinem Beispiel sieht der Inhalt der Web.config (jede .NET-Sprache kann hier aktiviert werden) so aus:
<pre><configuration>
 <system.web>
  <compilation debug="true">
   <assemblies>
    <add assembly="DelphiProvider" />
   </assemblies>
   <compilers>
    <compiler language="Delphi" extension=".pas"
     type="Borland.Delphi.DelphiCodeProvider,DelphiProvider" />
    </compilers>
  </compilation>
 </system.web>
</configuration></pre>

In diesem Fall liegt die Page Class als .pas-Datei vor, da der DelphiProvider f�r diese ASP.NET-Anwendung angemeldet wurde und somit auch f�r das Generieren des Sourcecodes der Page Class zust�ndig ist. Nachdem ASP.NET �ber den impliziten Aufruf des Delphi.NET Preview-Compilers die Page Class als Assembly-DLL gespeichert hat, wirft die CLR den Just-In-Time-Compiler (JIT) an, um daraus den CPU-Code zu generieren, damit alle nachfolgenden Request-Aufrufe sofort bedient werden k�nnen. 
Jedes vorgefundene Server Control erh�lt den Auftrag, sich selbst darzustellen, indem eine HTML-Repr�sentation generiert wird. Das Ergebnis dieser ASP.NET-internen Bem�hungen wird als HTTP-Response an den Browser zur�ckgeliefert. Der aufrufende Browser erh�lt nur reines HTML. Es spielt somit keine Rolle, welches Betriebssystem und welchen Browser der Anwender einsetzt, solange der Browser mindestens HTML 3.2 unterst�tzt. In meinem Beispiel sieht der beim Browser eintreffende HTML-Output so aus:
<html> 
<h1>ASP.NET und Delphi .NET (Preview)</h1> 
<body> 
<form name="_ctl0" method="post" action="OSFirstASPNET.aspx" id="_ctl0"> 
<input type="hidden" name="__VIEWSTATE"
value="dDwtNzY0NDQ0NDYzOzs+VLaKqasNaHTpqz 4VSFLk/0afkSI="
/> 
<input name="EditInput" type="text" id="EditInput" /> 
<input type="submit" name="_ctl1" value="Los gehts!" /> 
</form> 
 
</body> 
</html>

&#10

**Gesine Kuhlmann** · 10.01.2003, 15:38

Hi Andreas,

Doppeldoch ;-)

Webanwendungen sind doch wohl CS-Systeme reinsten Wassers. Ich habe ausdr�cklich theoretisch geschrieben. Das die tats�chliche Implementierung ein ganz anderes Paar Schuhe ist, steht auf einem anderen Blatt.

Bei all Deiner Liebe zu NET, hast Du aber vergessen zu erw�hnen, dass JAVA sich genau der gleichen, von Dir geschilderten Mechanismen bedient. Es gibt sogar Frevler, die behaupten das NET-Konzept sei bei JAVA abgepinnt...

Desweiteren fehlt mir in Deiner Schilderung ein kleiner Hinweis darauf, dass JAVA heute real existierend und plattformunabh�ngig verf�gbar ist, w�hrend NET doch wohl maximal in den Kinderschuhen steckt und im Zweifel nie plattformunabh�ngig wird.

Im �brigen w�re es bzgl. der eingangs gestellten Frage und dem heutigen Zeitpunkt vielleicht auch ganz vern�nftig gewesen, darauf hinzuweisen, das die Basis der Clients, auf welchen .NET-Technologien �berhaupt lauff�hig sind mikroskopisch klein ist.

Gruss
Gesin

Announcement

webbasierte Anwendung vs. Client/Server Anwendung

webbasierte Anwendung vs. Client/Server Anwendung

Comment

Comment

Comment

Comment