(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Richtlinien für den Anwendungsentwurf - von N-Tier zu .NET

Veröffentlicht: 13. Jun 2002 | Aktualisiert: 09. Nov 2004
Von David Chappell und Steve Kirk

Dieser Artikel erörtert den Entwurf von Anwendungen für Microsoft .NET und die erforderlichen Änderungen. Wie lässt sich dabei Wissen über das Erstellen von N-Tier-Anwendungen mit Microsoft Windows DNA auf das Erstellen von Anwendungen mit Microsoft .NET Framework übertragen? Außerdem enthält der Artikel Ratschläge zur Entwicklung von Anwendungen, die XML-Webdienste verwenden.

Auf dieser Seite

Einführung Einführung
Die Windows-DNA-Umgebung Die Windows-DNA-Umgebung
Die .NET-Umgebung Die .NET-Umgebung
Schlussfolgerung Schlussfolgerung

Einführung

N-Tier-Anwendungen gelten heutzutage als Maßstab für das Erstellen von Unternehmenssoftware. Die meisten verstehen unter einer N-Tier-Anwendung alles, was sich in separate logische Komponenten unterteilen lässt. Am häufigsten wird eine dreifache Unterteilung gewählt: Darstellung, Geschäftslogik und Daten. Es gibt jedoch auch andere Möglichkeiten. Ursprünglich wurden N-Tier-Anwendungen entwickelt, um Probleme mit traditionellen Client/Server-Anwendungen zu lösen. Mit der Verbreitung des Web begann diese Architektur jedoch, neue Entwicklungen zu dominieren.

Die Microsoft Windows® DNA-Technologie (Distributed Internet Architecture) stellt eine sehr erfolgreiche Grundlage für N-Tier-Anwendungen dar. Auch Microsoft .NET Framework bietet eine solide Plattform für das Programmieren von N-Tier-Anwendungen. Aufgrund der Änderungen, die .NET mit sich bringt, sollten die Entwickler jedoch einige der Lektionen überdenken, die sie bei Windows DNA über den Entwurf von N-Tier-Anwendungen gelernt haben.

Noch wichtiger ist die Tatsache, dass die in .NET Framework integrierte fundamentale Unterstützung für XML-Webdienste das Programmierern von neuartigen Anwendungen ermöglicht, die über das herkömmliche N-Tier-Prinzip hinausgehen. Wenn Sie verstehen möchten, wie Sie Anwendungen für .NET am besten entwickeln können, müssen Sie zunächst wissen, welche Änderungen mit diesen neuen Methoden einhergehen und wie Sie diese Änderungen nutzen können.

Dieser Artikel gibt einen Einblick in diese Aspekte, wobei er zunächst die wichtigsten Punkte wiederholt, die beim Programmieren von N-Tier-Anwendungen mit Windows DNA erlernt wurden. Anschließend wird unter Einhaltung der gleichen Reihenfolge untersucht, wie sich die jeweiligen Ergebnisse auf das Erstellen von Anwendungen mit .NET Framework anwenden lassen. Der letzte Abschnitt enthält Ratschläge zur Entwicklung von Anwendungen, die XML-Webdienste verwenden.

Die Windows-DNA-Umgebung

Die Unterteilung einer Anwendung in logische Komponenten ist nützlich. Das Aufschlüsseln einer großen Softwarekomponente in kleinere Bestandteile erleichtert das Programmieren, Wiederverwenden und Ändern der Anwendung. Es kann auch bei der Integration verschiedener Technologien oder unterschiedlicher Geschäftsorganisationen hilfreich sein.

Es gibt dabei jedoch auch einige Nachteile, die ebenfalls berücksichtigt werden sollten. Modularität und Wiederverwendbarkeit sind nützliche Dinge, können jedoch zu Anwendungen führen, die nicht so sicher, verwaltbar und schnell sind wie eigentlich möglich. In diesem Abschnitt werden einige der grundlegenden Entwicklungslektionen wiederholt, die sich aus den umfassenden Erfahrungen mit dem Erstellen von N-Tier-Anwendungen mit Windows DNA-Technologien besonders hervorheben.

Schreiben der Geschäftslogik
Windows DNA-Anwendungen implementieren ihre Geschäftslogik im Allgemeinen mit Hilfe der folgenden Implementierungsoptionen:

  • ASP-Seiten

  • COM-Komponenten (u.U. unter Verwendung der von COM+ bereitgestellten Zusatzdienste)

  • Im DBMS ausgeführte, gespeicherte Prozeduren

Es ist ein schlechte Idee, viel Geschäftslogik in ASP-Seiten zu packen. Es müssen dabei einfache Sprachen wie Microsoft Visual Basic® Script (VBScript) verwendet werden, der Code wird bei jeder Ausführung interpretiert, was Leistungsverluste zur Folge hat. Code in ASP-Seiten ist außerdem schwer zu verwalten. Dies ist größtenteils darauf zurückzuführen, dass sich die Geschäftslogik häufig mit dem Darstellungscode vermischt, der die Benutzeroberfläche erzeugt.

Aus diesem Grund wird beim Schreiben von Geschäftslogik der mittleren Ebene u.a. empfohlen, diese Logik in Form von COM-Objekten zu implementieren. Dieses Verfahren ist ein wenig komplexer als das Schreiben einer reinen ASP-Anwendung. Da jedoch mit sämtlichen Features versehene Sprachen verwendet werden können, die kompilierte ausführbare Dateien erzeugen, ist das resultierende Programm normalerweise schneller. Durch das Wrappen von Geschäftslogik in COM-Objekte wird dieser Code außerdem sauber von dem in ASP-Seiten enthaltenen Darstellungscode getrennt, sodass die Anwendung einfacher zu verwalten ist.

Von COM zu COM+ ist es nur ein kleiner Entwicklungsschritt. Wie viele Windows DNA-Entwickler gelernt haben, sollten die von COM+ bereitgestellten Kerndienste, wie Transaktionen, Just-In-Time-Aktivierung (JIT), rollenbasierte Sicherheit und Threadingdienste, nur verwendet werden, wenn sie wirklich erforderlich sind.

Die Verwendung von COM+ oder ähnlichen Diensten, die von anderen Entwicklungsplattformen bereitgestellt werden, können in Anwendungen resultieren, die langsamer und komplexer sind als normalerweise nötig. Die Verwendung von COM+ ist in den folgenden Fällen sinnvoll:

  • Wenn verteilte Transaktionen erforderlich sind, die sich auf heterogene Ressourcen-Manager erstrecken, wie Microsoft SQL ServerT und Oracle.

  • Wenn die Anwendung effektiv rollenbasierte Sicherheit einsetzen kann.

  • Wenn das Threadingverhalten von Microsoft Visual Basic® 6.0 verbessert werden kann.

  • Wenn die Leistung durch JIT-Aktivierung verbessert wird. Dies ist bei Browserclients nur selten der Fall, da ASP-Seiten sowieso effektiv JIT-aktiviert sind.

  • Wenn die Konfigurationsvorteile von COM+ die Weitergabe einer Anwendung erheblich erleichtern.

Die dritte Option zum Schreiben von Geschäftslogik besteht darin, einen Teil des Codes als gespeicherte Prozedur zu erstellen, die im Datenbank-Managementsystem (DBMS) ausgeführt wird. Auch wenn die Verwendung von gespeicherten Prozeduren in erster Linie dazu dienen soll, die Einzelheiten des Datenbankschemas von der Geschäftslogik zu isolieren, um die Codeverwaltung und Sicherheit zu vereinfachen, kann eine derartige Datennähe des Codes zu einer Optimierung der Leistung beitragen.

Anwendungen, die DBMS-unabhängig sein müssen, wie diejenigen, die von unabhängigen Softwareanbietern programmiert werden, vermeiden diese Option gewöhnlich, da sie die Anwendung auf ein bestimmtes Datenbanksystem beschränkt. Gespeicherte Prozeduren können auch schwerer zu schreiben und zu debuggen sein als COM-Objekte, und dieses Verfahren kann die Möglichkeiten zur Wiederverwendung des Codes einschränken.

Trotzdem bleiben die meisten benutzerdefinierten Anwendungen an das DBMS-System gebunden, in dem sie ursprünglich erstellt wurden, und die Verwendung von gespeicherten Prozeduren kann enorme Leistungsvorteile haben. Aus diesem Grund verwenden Windows DNA-Anwendungen, die so gute Leistungen wie möglich erzielen müssen, im Allgemeinen gespeicherte Prozeduren für einige oder alle Teile ihrer Geschäftslogik.

Erstellen der Clients
Windows DNA unterstützt sowohl systemeigene Windows-Clients, die in einer Sprache wie Visual Basic geschrieben wurden, als auch Browserclients. Browserclients unterliegen größeren Einschränkungen - insbesondere, wenn es sich bei dem verwendeten Browser um Microsoft Internet Explorer oder Netscape handelt. Aus diesem Grund verfügen Anwendungen häufig sowohl über einen Browser- als auch über einen systemeigenen Windows-Client. Der Browserclient stellt eine eingeschränktere Schnittstelle bereit, ermöglicht jedoch einen einfachen Zugriff auf das Internet, während der Windows-Client eine mit sämtlichen Features versehene Schnittstelle bietet. Komplexere Browserschnittstellen können mit Hilfe von downloadbaren Microsoft ActiveX®-Steuerelementen erstellt werden, allerdings nur, wenn es sich bei dem Browser definitiv um Internet Explorer handelt und der Benutzer dem Ersteller der Anwendung vertraut.

Statusverwaltung in Browseranwendungen
ASP-Anwendungen können verschiedene Mechanismen verwenden, um Informationen auf dem Server zwischen Clientanforderungen zu verwalten. Bei Windows DNA gilt es jedoch als feststehende Regel, das ASP-Session-Objekt niemals zum Speichern von clientspezifischem Status zu verwenden, wenn die Anwendung load balancing über zwei oder mehr Computern macht. Das ASP-Session-Objekt ist an einen einzelnen Computer gebunden und kann daher mit load balancing nicht korrekt arbeiten.

Sowohl das ASP-Session-Objekt als auch das ASP-Application-Objekt unterliegen ebenfalls einer Einschränkung. Wenn eines dieser beiden zum Speichern eines ADO-Recordsets verwendet wird, reduziert sich dadurch die Skalierbarkeit erheblich, da es die Möglichkeiten der Anwendung zur Nutzung von Multithreading einschränkt. Aus diesem Grund ist es in kaum einem Fall ratsam, Recordsets in einem dieser Objekte zu speichern.

Verteilte Kommunikation
Festzulegen, wie auf unterschiedlichen Computern ausgeführte Komponenten miteinander kommunizieren sollen, ist in Windows DNA ein Kinderspiel. Aus rein entwicklungstechnischer Sicht stellt DCOM eine einfache Erweiterung von COM dar. In der Praxis sind mit DCOM jedoch verschiedene Auswirkungen verbunden. Diese sehen u.a. folgendermaßen aus:

  • Da es sich in einem sehr realen Sinne um ihr systemeigenes Protokoll handelt, ist die Kommunikation mit Remote-COM+-Objekten unter Verwendung von DCOM recht unkompliziert.

  • Wenn es richtig konfiguriert wird, ist DCOM ein sehr sicheres Protokoll. Das Konfigurieren ist jedoch nicht so einfach, was die Verwendung des Protokolls erschweren kann. Trotzdem kann DCOM selbst insbesondere in einer Windows-2000-Domäne eine gute verteilte Authentifizierung, Datenintegrität und Datenschutz gewährleisten.

  • Da es das Öffnen beliebiger Ports erfordert, funktioniert DCOM mit Firewalls nicht so gut. Dementsprechend können Anwendungen, die über das Internet kommunizieren müssen, zu diesem Zweck gewöhnlich DCOM nicht einsetzen.

Zugreifen auf gespeicherte Daten
Die Datenzugriffsarchitekturen, die mit ADO angelegt werden können, lassen sich in zwei Kategorien unterteilen: Light-Touch und Heavy-Touch. Light-Touch-ADO-Clients halten Datenbankverbindungen so kurz wie möglich und schreiben mit Hilfe von gespeicherten Prozeduren in die Datenbank. Light-Touch-Clients haben zum Abrufen von Daten die folgenden drei Möglichkeiten:

  • Durch Füllen von Recordsets mit schreibgeschützten Vorwärtscursorn

  • Über die Ausgabeparameter von gespeicherten Prozeduren

  • Mit Hilfe von Datenströmen (in älteren Versionen von ADO)

Alternativ dazu halten Heavy-Touch-Clients die Datenbankverbindung über einen längeren Zeitraum. Diese Anwendungsart basiert auf offenen Verbindungen, und die statusbehafteten serverseitigen Cursor bieten folgende Möglichkeiten:

  • Direkter Zugriff eines Recordsets auf Änderungen, die von anderen Benutzern oder Anwendungen vorgenommen wurden

  • Aktivierung einer eingeschränkten Sperre

  • Reduzierung des Netzwerkverkehrs durch Minimierung der in den ADO-Client kopierten Datenmenge. Im Gegensatz zu Light-Touch-Clients können Clients, die serverseitige Cursor verwenden, Abfrageergebnisse so lange in der Datenbank lassen, bis diese Daten benötigt werden. Bei diesem Verfahren werden außerdem weniger Metadaten in das Recordset kopiert, sodass ein Großteil von ihnen in der Datenbank selbst verbleibt.

Light-Touch-Anwendungen bieten die größte Skalierbarkeit, da sie Datenbankverbindungen - eine knappe Ressource - auf effektivste Weise nutzen. Heavy-Touch-Anwendungen müssen hingegen längere Datenbankverbindungen aufrecht erhalten, da diese von statusbehafteten serverseitigen Cursorn benötigt werden.

Dies schränkt die Skalierbarkeit der Anwendung erheblich ein und ist insbesondere für Internetserveranwendungen nicht ratsam. Heavy-Touch-Anwendungen lassen sich mit ADO zwar einfacher entwickeln, stellen aber nur selten die bessere Wahl dar.

ADO ist ebenfalls nicht besonders gut für die Arbeit mit hierarchischen Daten (z.B. XML-Dokumenten) geeignet. Die entsprechenden ADO-Features sind in ihrer Verwendung komplex und schwer zu durchschauen. Außerdem bietet ADO nur beschränkte Unterstützung für den Zugriff auf die XML-Features von SQL Server 2000. Folglich wird die Verwendung von ADO für die Arbeit mit hierarchischen Daten von Windows DNA-Anwendungen häufig vermieden.

Übergeben von Daten an Clients
Das effektive Verschieben von Daten von der mittleren Ebene in einen Client stellt für jede N-Tier-Anwendung einen entscheidenden Aspekt dar. Bei der Kommunikation mit Windows-Clients über DCOM können Windows-DNA-Anwendungen getrennte ADO-Recordsets verwenden. Diese Option kann auch für Browserclients eingesetzt werden, sofern es sich bei dem Browser definitiv um Internet Explorer handelt.

Das Senden von Daten an beliebige Browser ist schwerer. Eine Möglichkeit besteht darin, die Daten explizit in XML zu konvertieren und sie zusammen mit sämtlichem erforderlichem Skriptcode an den Browser zu senden.

Die .NET-Umgebung

.NET unterstützt konventionelle N-Tier-Anwendungen, Webdienstanwendungen und Anwendungen, die Elemente von beiden in sich vereinigen. In diesem Abschnitt befassen wir uns zunächst mit den Auswirkungen von .NET auf N-Tier-Anwendungen. Anschließend werden einige der wesentlichen Entwicklungsaspekte beim Erstellen von Webdienstanwendungen beschrieben.

Binden von N-Tier-Anwendungen mit .NET
Einige der im vorigen Abschnitt beschriebenen Aspekte gelten gleichermaßen für Windows-DNA-Anwendungen wie auch für Anwendungen, die mit .NET Framework erstellt werden. Auch hier ist es z.B. sinnvoll, COM+ (das in .NET Framework als "Enterprise Services" bezeichnet wird) nur dann einzusetzen, wenn eine oder mehrere der oben aufgeführten Bedingungen erfüllt werden. Genauso führt auch das Programmieren der Geschäftslogik in Form von gespeicherten Prozeduren in vielen N-Tier-Anwendungen zu besseren Leistungen.

.NET Framework bietet jedoch immer noch eine Fülle von neuen Technologien bzw. neuen Versionen vorhandener Technologien. Diese Verbesserungen bringen eine Reihe von Änderungen bezüglich der optimalen Architektur von N-Tier-Anwendungen mit sich.

In diesem Abschnitt werden die zuvor beschriebenen Kategorien einzeln durchgegangen, um zu erläutern, inwiefern .NET Framework Einfluss auf die Entscheidungen eines Entwicklers beim Erstellen von N-Tier-Anwendungen nimmt.

Schreiben der Geschäftslogik
Anders als Windows DNA, wo mit ASP-Seiten, COM-Komponenten und gespeicherten Prozeduren drei Möglichkeiten zum Programmieren von N-Tier-Geschäftslogik zur Verfügung stehen, bietet .NET Framework nur zwei Optionen an: Assemblys und gespeicherte Prozeduren.

Für Browseranwendungen können mit Hilfe von Microsoft ASP.NET-ASPX-Seiten Assemblys erzeugt werden. Im Gegensatz zu ASP ist es häufig ratsam, Geschäftslogik unter ausschließlicher Verwendung von ASP.NET zu schreiben.

Ein Grund dafür ist die ASP.NET-Option mit den zugrunde liegenden Codeanweisungen. Anders als bei herkömmlichen ASP-Seiten, die es nicht gerade leicht machen, Geschäftslogik und Darstellungscode in einer verwaltbaren Weise zu mischen, ermöglicht die Verwendung von zugrunde liegenden Codeanweisungen mit ASPX-Seiten eine saubere Trennung dieser beiden Codetypen.
Wo eine Windows DNA-Anwendung möglicherweise sowohl ASP-Seiten als auch COM-Objekte verwendet, um eine verwaltbare Lösung zu erhalten, reicht bei einer Anwendung, die mit .NET Framework erstellt wurde, die Verwendung von ASP.NET aus.

Außerdem kann die in ASPX-Seiten enthaltene Geschäftslogik in einer beliebigen .NET-basierten Sprache geschrieben werden, nicht nur in den einfachen Skriptsprachen, die von herkömmlichen ASP-Seiten unterstützt werden. Und da ASP.NET Seiten kompiliert, statt sie zu interpretieren, können ASP.NET-Anwendungen sehr schnell sein.

Während für eine mit Windows DNA entwickelte Anwendung u.U. sowohl ASP-Seiten als auch COM-Objekte verwendet wurden, um eine ausreichende Leistung zu erzielen, kann die mit .NET erzielte Leistungssteigerung es ermöglichen, dieselbe Anwendung lediglich mit ASP.NET zu erstellen. Schließlich kann Geschäftslogik, die mit Hilfe des ASP.NET-Caches den Datenbankzugriff für regelmäßig verwendete Daten reduziert, bedeutende Leistungsverbesserungen realisieren.

Es soll jedoch nicht unerwähnt bleiben, dass die Wiederverwendung von Code, der in eine ASPX-Seite eingebaut ist, schwerer ist als bei Verwendung einer Standardassembly. Das gilt selbst dann, wenn Code Behind verwendet wird, So ist z.B. der Zugriff auf Code in einer ASPX-Seite über einen Windows-Forms-Client problematisch.

Schreiben der Clients
Bei .NET Framework ist kaum noch ein Windows-Client erforderlich - ein Browserclient reicht u.U. aus. Ein Grund dafür ist, dass ASP.NET-Websteuerelemente das Erstellen und/oder Kaufen von wiederverwendbaren grafischen Browser-Benutzeroberflächenelementen ermöglichen und dadurch das Erstellen von besser verwendbaren Clients vereinfachen.

Die Möglichkeit, .NET-Framework-basierte Komponenten in Internet-Explorer-Clients downzuloaden und anschließend mit eingeschränkter Vertrauenswürdigkeit auszuführen, statt mit der "Alles-oder-nichts"-Vertrauenswürdigkeit, die für ActiveX-Steuerelemente erforderlich ist, erleichtert außerdem das Erstellen von besseren Benutzeroberflächen.

Statusverwaltung in Browseranwendungen
Da das ASP-Session-Objekt an einen Computer gebunden ist, ist es nicht so nützlich wie es eigentlich sein könnte. Mit .NET Framework wird diese Einschränkung jedoch beseitigt. Anders als bei ASP kann das ASP.NET-Session-Objekt von zwei oder mehr Computern gemeinsam genutzt werden. Dadurch wird es ermöglicht, das Session-Objekt zum Verwalten des Status in einer Webserverfarm mit Lastenausgleich zu verwenden und seinen Nutzen somit wesentlich zu erhöhen.

Da der Inhalt des Session-Objekts wahlweise in einer SQL Server-Datenbank gespeichert werden kann, kann dieser Mechanismus außerdem in Anwendungen eingesetzt werden, die im Fall von Ausfällen persistent clientspezifischen Status aufrechterhalten müssen.

Eine weitere wichtige Änderung mit Auswirkungen auf die Architektur von ASP.NET-Anwendungen besteht darin, dass hier im Gegensatz zu ASP DataSets im Session- und Application-Objekt gespeichert werden können, ohne das Threading zu beeinträchtigen.

Mit anderen Worten: Die feste Windows-DNA-Regel, dass Recordsets nicht in diesen Objekten gespeichert werden sollten, gilt nicht für DataSets im .NET Framework. Dadurch können Abfrageergebnisse nicht nur einfacher, sondern auch auf natürlichere Weise gespeichert werden.

Verteilte Kommunikation
.NET Framework bietet mehr Optionen für die Kommunikation zwischen den verteilten Komponenten einer Anwendung als Windows DNA. Dazu gehören u.a. auch die folgenden:

  • .NET Remoting, das sowohl einen TCP-Channel als auch einen HTTP-Channel bereitstellt

  • ASP.NET-Unterstützung für SOAP-aufrufbare XML-Webdienste, die in ASMX-Seiten implementiert sind

  • DCOM für die Kommunikation mit Remote-COM-Objekten

Je mehr Optionen, desto mehr Möglichkeiten bei der Entwicklung, d.h. Sie müssen auch mehr Faktoren berücksichtigen, bevor Sie sich für eine Möglichkeit entscheiden. Beim Erstellen von verteilten Anwendungen mit .NET Framework sollten u.a. die folgenden entwicklungstechnischen Aspekte berücksichtigt werden:

  • Für die direkte Kommunikation mit Remote-COM+-Objekten ist DCOM erforderlich - .NET Remoting kann nicht verwendet werden. Da die Einrichtung und Verwendung von DCOM recht kompliziert ist, sollte diese Kommunikationsart möglichst vermieden werden. In einigen Fällen kann es lohnenswert sein, vorhandene COM+-Objekte über verwalteten Code offen zu legen, auch wenn die dazu erforderliche COM-Interoperabilität zu Leistungsverlusten führt.

  • Der .NET-Remoting-TCP-Channel stellt keine integrierte Sicherheit bereit. Im Gegensatz zu DCOM bietet er keine starken Authentifizierungs-, Datenintegritäts- oder Datenschutzdienste. Der TCP-Channel hat jedoch nicht nur Nachteile. Er ist z.B. wesentlich einfacher zu konfigurieren als DCOM.

  • Anders als DCOM, das nicht besonders gut mit Firewalls funktioniert, wurde der .NET-Remoting-HTTP-Channel explizit für eine effektive Kommunikation über das Internet entworfen. Außerdem bietet er einen sicheren Datenpfad, da er SSL verwenden kann. Im Allgemeinen stellt der TCP-Channel für die Kommunikation über ein Intranet die bessere Wahl dar, während der HTTP-Channel oder die ASP.NET-SOAP-Unterstützung für die Kommunikation über das Internet vorzuziehen ist.

  • Sowohl der .NET-Remoting-HTTP-Channel als auch die ASP.NET-Unterstützung für XML-Webdienste implementieren SOAP. Die beiden Implementierungen unterscheiden sich jedoch voneinander, und jede von ihnen dient einem bestimmten Zweck. .NET Remoting konzentriert sich auf die Erhaltung der genauen Semantik der Common Language Runtime und stellt somit die beste Wahl dar, wenn das Remotesystem auch .NET Framework ausführt.

ASP.NET hingegen zielt darauf ab, absolute Standard-XML-Webdienste bereitzustellen und ist daher am besten geeignet, wenn das Remotesystem auf .NET oder einer anderen Plattform basiert. ASP.NET ist außerdem schneller als der .NET Remoting-HTTP-Channel. Der HTTP-Channel hat jedoch ebenfalls Vorteile. Er ermöglicht sowohl das Übergeben von Parametern nach Verweis als auch echte asynchrone Rückrufe - Features, die nicht von Natur aus Bestandteil der SOAP-Unterstützung in ASP.NET sind.

Zugreifen auf gespeicherte Daten
Im Gegensatz zu ADO, das die Erstellung von nicht so gut skalierbaren Heavy-Touch-Clients erleichtert, ist ADO.NET eher zum Erstellen von Light-Touch-Clients geeignet. Ein ADO.NET-Client verwendet zum Lesen von Daten schreibgeschützte Vorwärtscursor. Da statusbehaftete serverseitige Cursor nicht unterstützt werden, ist das Programmiermodell auf kurze Verbindungszeiten ausgelegt.

Clients, die Daten direkt lesen und verarbeiten, können das ADO.NET-DataReader-Objekt verwenden, das zurückgegebene Daten nicht zwischenspeichert. Alternativ dazu können Daten in ein DataSet-Objekt gelesen werden, das als Cache für Daten dient, die von SQL-Abfragen und anderen Quellen zurückgegeben werden. Im Gegensatz zu einem ADO-Recordset kann ein DataSet jedoch nicht explizit eine offene Verbindung zu einer Datenbank beibehalten.

Trotzdem hat das von ADO geförderte Heavy-Touch-Verfahren einige Vorteile, die bereits erwähnt wurden. Diese Probleme lassen sich in ADO.NET folgendermaßen lösen:

  • Ein ADO.NET-Client, der Daten in DataSets speichert und Zugriff auf Änderungen von anderen Benutzern oder Anwendungen erfordert, muss expliziten Code zum Ausführen dieser Änderungen enthalten. Dieser Code muss normalerweise auch bei jeder von ihm durchgeführten Überprüfung eine Verbindung zu der Datenbank öffnen.

  • Auch wenn in ADO.NET keine direkte Unterstützung für das eingeschränkte Sperren vorhanden ist, kann ein Client durch ADO.NET-Transaktionen oder die Implementierung der erforderlichen Funktionalität in einer gespeicherten Prozedur dieselbe Wirkung erzielen.

  • Im Gegensatz zu ADO können in ADO.NET keine Abfrageergebnisse in der Datenbank gelassen werden, um mit einem serverseitigen Cursor auf sie zuzugreifen. ADO.NET ruft zwar weniger Metadaten ab als ADO, Anwendungen sollten jedoch immer noch dazu entwickelt werden, die kompletten Ergebnissen einer Abfrage von der Datenbank an den ADO.NET-Client zu übertragen.

Eine weitere Änderung in ADO.NET, die sich auf entwicklungstechnische Entscheidungen auswirken kann, ist die verbesserte Unterstützung für die Arbeit mit hierarchischen Daten, und zwar insbesondere mit XML-Dokumenten.

Das Transformieren eines ADO.NET-DataSets in XML ist genauso unkompliziert wie der Zugriff auf die XML-Features von SQL Server 2000. Dementsprechend kann auf hierarchische Daten, die in einer Windows DNA-Umgebung möglicherweise in ein relationales Modell gezwängt worden wären, nun in ihrer ursprünglichen Form zugegriffen werden. Weitere Informationen finden Sie im Abschnitt Verwandte Literatur.

Übergeben von Daten an Clients
Das effektive Übergeben von Daten an Clients ist in N-Tier-Anwendungen, die mit .NET Framework erstellt wurden, in jeder Hinsicht genauso wichtig wie in denjenigen, die mit Windows DNA erstellt wurden. Eine bedeutende Änderung besteht darin, dass die ADO.NET-DataSets automatisch in XML serialisiert werden können und das Übergeben von Daten zwischen den Ebenen erleichtern. Diese Möglichkeit bestand in Windows DNA zwar bereits, .NET vereinfacht die Verwendung von XML zum Austauschen von Informationen jedoch erheblich.

XML-Web-Service-Architektur
Die Technologien von XML-Webdiensten, wie SOAP, Web Services Description Language (WSDL) usw., können beim Erstellen von verteilten Anwendungen auf verschiedene Weise genutzt werden. Dazu sind u.a. folgende Beispiele zu nennen:

  • Herstellen einer Verbindung zum Webclient einer N-Tier-Anwendung über SOAP, nicht nur über HTTP. Bei diesem Client kann es sich um jedes beliebige Gerät handeln, das SOAP-Aufrufe ausführen kann. Der Client kann dann mehr Funktionen für den Benutzer bereitstellen, da er nun über eine einfache Möglichkeit verfügt, Methoden in Remoteservern aufzurufen.

  • Verbinden von zwei N-Tier-Anwendungen, von denen die eine auf einer .NET Framework-basierten Plattform erstellt worden sein kann und die andere auf einer anderen Plattform, z.B. einem Java-Anwendungsserver.

  • Verbinden von zwei Mainframeanwendungen, zwei Enterprise Resource Planning-Systemen (ERP-Systemen) oder einem ERP-System mit einer anderen Anwendungsart. Wie diese Beispiele zeigen, lassen sich XML-Webdienste in wesentlich breiter gefassten Szenarios einsetzen als nur in N-Tier-Anwendungen.

Auf welche Weise sie auch immer verwendet werden, XML-Dienste bringen viele neue entwicklungstechnische Aspekte mit sich. Der vielleicht grundlegendste Unterschied zwischen XML-Webdiensten und den traditionelleren Middlewaretechnologien, die von N-Tier-Anwendungen häufig verwendet werden, besteht darin, dass XML-Webdienste flexible Kopplung verwenden.

Leider wird dieser Begriff von verschiedenen Leuten unterschiedlich interpretiert. Hier bezieht er sich auf kommunizierende Anwendungen mit den folgenden Eigenschaften:

  • Die Anwendungen sind größtenteils voneinander unabhängig und werden häufig von verschiedenen Organisationen gesteuert.

  • Zuverlässigkeit ist kein absoluter Wert. Die jederzeitige Verfügbarkeit der einzelnen kommunizierenden Anwendungen wird nicht gewährleistet.

  • Die Interaktion erfolgt synchron oder asynchron. Ein Webdienstclient kann das Warten auf eine Antwort auf eine Anforderung blockieren oder nach dem Absetzen der Anforderung seinen Geschäften nachgehen und vielleicht später überprüfen, ob eine Antwort eingegangen ist.

Diese grundlegenden Eigenschaften beinhalten eine Reihe von entwicklungstechnischen Richtlinien für Anwendungen, die XML-Webdienste verwenden. Während einige dieser Aspekte wahrscheinlich in künftigen Arbeiten, wie den globalen XML-Webdienstarchitektur-Spezifikationen (GXA-Spezifikationen) (in Englisch) von Microsoft, abgedeckt werden, müssen sie von den Erstellern effektiver XML-Webdienstanwendungen heute schon berücksichtigt werden. Dazu gehören u.a. die folgenden:

  • Die Sicherheit ist wahrscheinlich komplex. Es ist erforderlich, von vornherein End-to-End-Authentifizierung und eine effektive Autorisierung einzuplanen. End-to-End-Datenintegrität und -Datenschutz können für einige Anwendungen ebenfalls wichtig sein. Es kann erforderlich sein, verschiedene Sicherheitsmechanismen untereinander zuzuordnen, auch wenn dies möglichst vermieden werden sollte. Weitere Informationen finden Sie im Abschnitt .

  • Die Interoperabilität kann problematisch sein. Aufgrund der relativen Unausgereiftheit der Spezifikation sind die SOAP-Implementierungen verschiedener Anbieter nicht immer kompatibel. Weitere Informationen finden Sie im Abschnitt .

  • Die Modifikation vorhandener Anwendungen für den Zugriff über XML-Webdienste kann Probleme verursachen. Geschwindigkeit, Skalierung und Sicherheit spielen grundsätzlich eine Rolle, wenn Komponenten, die ursprünglich nicht für die Zusammenarbeit geschaffen wurden, miteinander verbunden werden.

Da vorhandene Anwendungen häufig nicht dazu erstellt wurden, die Aufgaben von Servern zu übernehmen, können sie durch die Verarbeitung vieler kleiner Anforderungen leicht überfordert werden. Weniger Anforderungen, die jeweils mehr Daten anfordern, führen wahrscheinlich zu einer besseren Anwendungsleistung.

Auch eignen sich vorhandene Anwendungen gewöhnlich nicht zum Verarbeiten unvorhersehbarer Lasten, wie es z.B. beim Bereitstellen von Software für das Internet der Fall ist. Wenn möglich, kann die Verwendung eines Warteschlangenmechanismus hilfreich sein, der Anforderungen so lange speichert, bis sie bedient werden können.

  • Es ist notwendig, Fehler einzuplanen. Insbesondere Anforderungen, die eine einmalige Semantik erfordern, müssen dabei gewöhnlich gesondert berücksichtigt werden. So wird z.B. für eine Anforderung ein Timeout ausgelöst, während die ursprüngliche Anforderung jedoch lediglich aus irgendeinem Grund verzögert wurde. Wenn das zweimalige Ausführen eines Remotewebdienstes aufgrund eines einmaligen Aufrufs ein Problem darstellt, müssen Mechanismen erstellt werden, um dieses Problem zu lösen.

  • End-to-End-Transaktionen, die auf verteilten, über mehrere Organisationsgrenzen gehaltenen Sperren basieren, sind wahrscheinlich nicht verfügbar. Die meisten Organisationen lassen es nicht zu, dass "fremde" Anwendungen Daten sperren, und daher sind keine Transaktionen im Zweiphasencommit-Stil möglich. Stattdessen sollten Sie die Verwendung von Kompensationstransaktionen für eventuell erforderliche Rollbacks einplanen.

  • Da die abgerufenen Daten auf Anwendungs- und Organisationsgrenzen stoßen können, müssen diese Daten ggf. an beiden Enden der jeweiligen Webdienstkommunikation sorgfältig überprüft werden. Während der Ersteller einer Anwendung möglicherweise auf die Genauigkeit der Daten vertraut, die von anderen Teilen seiner Anwendung erzeugt wurden, sollte er dieses Vertrauen anderen Anwendungen nicht so ohne weiteres entgegenbringen. Die empfangenen Informationen können u.U. sogar böswilligen Code enthalten, und daher ist eine sorgfältige Überprüfung mehr als gerechtfertigt.

  • SOAP und die von ihm transportierten XML-definierten Daten sind ausführlich. Das Übergeben von zu vielen Daten aufgrund eines einfachen Aufrufs kann Netzwerke mit niedriger Bandbreite überfordern. Im Gegensatz dazu kann das Übergeben von zu wenigen Daten nach den einzelnen Aufrufen die Anwendung überfordern, die dieses Anforderungen verarbeitet. Auch wenn dies möglicherweise keine leichte Aufgabe ist, ist es wichtig, den richtigen Mittelweg zu finden. Weitere Informationen finden Sie im Abschnitt .

Schlussfolgerung

Die Architektur spielt eine Rolle. Die Auswahl der richtigen Struktur für eine Anwendung - insbesondere wenn diese über mehrere Systeme verteilt ist - ist von entscheidender Bedeutung. Eine falsche Architektur kann bei der Implementierung gewöhnlich nicht mehr korrigiert werden, auch wenn der Entwickler noch so gut ist. Falsche Entscheidungen führen zu Leistungsverlusten, geringerer Sicherheit und weniger Aktualisierungsmöglichkeiten für die Anwendung.

Windows DNA bietet eine solide Grundlage für N-Tier-Anwendungen, und Windows-Entwickler können auf ihren DNA-Kenntnissen aufbauen und einen Großteil dieser Kenntnisse auf die neue .NET-Umgebung anwenden. Wenn Sie die in diesem Artikel erwähnten Änderungen berücksichtigen, können Sie schnellere, sichere und funktionellere Anwendungen erstellen. .NET hat sowohl für N-Tier-Anwendungen als auch Anwendungen, die sich die neuen Webdiensttechnologien zu Nutze machen, viel zu bieten.

Verwandte Literatur

Die Windows DNA-Umgebung

Architecture Decisions for Dynamic Web Applications: Performance, Scalability, and Reliability (in Englisch)
Duwamish Online Application Architecture (in Englisch)

Die .NET-Umgebung

Performance Comparison: Transaction Control (in Englisch)
P erformance Comparison: Data Access Techniques (in Englisch)
.NET Architectural Sample Applications (in Englisch)

Aspekte der XML-Webdienstarchitektur

Real SOAP Security (in Englisch)
Designing Your Web Service for Maximum Interoperability (in Englisch)
DIME: Sending Binary Data with Your SOAP Messages (in Englisch)


Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft