(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Entwerfen einer .NET-Anwendung

Veröffentlicht: 24. Jun 2002 | Aktualisiert: 21. Jun 2004
Von Paul D. Sheriff

Dieses Dokument bietet einen Überblick über die unterschiedlichen Standardarchitekturen, die sich in .NET-Anwendungen als sinnvoll erwiesen haben. Jede Architekturbeschreibung enthält grundlegende Richtlinien zu relevanten Szenarien für die Nutzung, Implementierungsoptionen sowie Vor- und Nachteile. Beschrieben werden Anwendungen mit zwei, drei oder n Ebenen (Schichten).

Anmerkung: Die in diesem Artikel vorgestellten Probleme in Anwendungsentwürfen sind im Abschnitt Building Distributed Applications with .NET von MSDN® eingehender erläutert.

Auf dieser Seite

Anwendungsarchitektur mit zwei Ebenen
Anwendung mit drei Ebenen und einem XML-Webdienst
Anwendung mit drei Ebenen und .NET Remoting
Logische Anwendungen mit n Ebenen
Anwendung mit n Ebenen und einem XML-Webdienst
Weitere Techniken für Anwendungen mit n Ebenen
Migrieren einer Visual-Basic-6.0-Anwendung mit n Ebenen
Zusammenfassung

Ziele

  • Kennenlernen von Standardarchitekturen für Microsoft® .NET-Anwendungen.

  • Abwägen der Vor- und Nachteile jeder Architektur für die Entwicklung.

Voraussetzungen

  • Sie sind mit der Entwicklung für .NET vertraut, einschließlich Web- und Desktopentwicklung.

  • Sie sind mit Programmierkonzepten vertraut, einschließlich Klassen und Attributen.

  • Sie sind mit einer Vielzahl von Architekturen vertraut, einschließlich Strukturen mit mehreren Ebenen oder Servern.

Anwendungsarchitektur mit zwei Ebenen

Eine Standardanwendung aus zwei Ebenen ist eine Clientanwendung, die ADO.NET verwendet, um direkt mit einem Datenbankserver wie Microsoft SQL ServerT zu kommunizieren (siehe Abbildung 1). Zwischen der Clientanwendung und der Datenbank ist außer ADO.NET keine Zwischenebene vorhanden. Weitere Informationen zu ADO.NET finden Sie in der Dokumentation zum .NET Framework, in weiteren Artikeln dieser Reihe oder mithilfe des MSDN-Suchmoduls.

Bild01
Abbildung 1. Eine Anwendung mit zwei Ebenen verfügt über eine Clientanwendung und einen Datenspeicher wie z. B. Microsoft SQL Server.


Wann ist eine Architektur mit zwei Ebenen zu empfehlen
Eine Architektur mit zwei Ebenen ist für eine kleine Anwendung geeignet, die wenig oder keine Formulare enthält. Sie ist möglicherweise auch für Prototypen geeignet, bei denen die endgültige Version der Anwendung eine der in diesem Artikel beschriebenen Techniken mit n Ebenen verwendet. Eine Architektur mit zwei Ebenen eignet sich jedoch nicht für eine Unternehmensumgebung, da die Kosten und die Dauer für Entwicklung und Wartung unüberschaubar werden können.

Standardoptionen für die Implementierung
Zum Entwickeln einer Anwendung mit zwei Ebenen können Sie unterschiedliche Techniken verwenden. Alle Techniken verwenden ADO.NET mit einer Clientschnittstelle, z. B. einer Desktop- oder webbasierten Anwendung, und eine Datenbank wie SQL Server. Mögliche Ansätze für eine Anwendung mit zwei Ebenen sind z. B.:

  • Verwenden von Datenbindungstechniken, um ein ADO.NET-DataSet direkt mit einem Steuerelement zu verbinden.

  • Schreiben von Code, der auf ADO.NET-Objekte zugreift, um Daten manuell auf Ihrer Benutzeroberfläche in Steuerelemente zu laden.

  • Verwenden einer Kombination der beiden beschriebenen Techniken.

  • Direktes Codieren von Geschäftsregeln in den Formularen mithilfe einer der beschriebenen Techniken.

Vorteile

Eine Anwendung mit zwei Ebenen hat folgende Vorteile:

  • Die Entwicklung kann schnell und problemlos durchgeführt werden, da Sie ein ADO.NET-DataSet mithilfe von Datenbindung direkt mit vielen der Steuerelementen verbinden können, die zum Erstellen der Benutzeroberfläche verwendet werden. Dadurch können die grundlegenden Funktionen einer Anwendung schnell gestartet und ausgeführt werden.

  • Sie können den gesamten Code einer Anwendung in Ihren Formularen anzeigen. Zum Anzeigen des Codes muss neben den Formularen keine weitere Komponente verwendet werden.

Nachteile

Eine Anwendung mit zwei Ebenen hat folgende Nachteile:

  • Alle Geschäftsregeln sind im Front-End-Code enthalten. Daher müssen alle Clients aktualisiert werden, wenn Sie eine Geschäftsregel ändern müssen. Wenn Sie keine automatische Aktualisierung verwenden, kann dies zu einem kaum zu bewältigenden Wartungsaufwand führen. Wenn Sie SQL Server verwenden, können Sie jedoch einige Geschäftsregeln in Form von gespeicherten Prozeduren erstellen und so Dauer und Kosten der Wartung reduzieren.

  • SQL kann zwar eine Abstraktionsschicht zwischen der Datenbankstruktur und dem Rest der Anwendung bereitstellen, aber Feldnamen sind im Quellcode oder den Steuerelementeigenschaften häufig hart codiert. Wenn Sie einen Feldnamen ändern, müssen Sie jedes Vorkommnis in Ihrer Anwendung suchen und ersetzen. Wenn Sie Datenbindung verwenden, müssen Sie zudem alle Formulare überprüfen und Eigenschaften ändern.

  • Ein großer Teil des Codes - z. B. SQL-Anweisungen und Geschäftsregeln - wird häufig in der gesamten Anwendung wiederholt, da unterschiedliche Formulare z. T. dieselben Tabellen verwenden. Dadurch wird die Wartung dieses Anwendungstyps erschwert, da Sie den Namen einer Tabelle oder eines Feldes im Fall einer Änderung an vielen Stellen ändern müssen. Zudem sind zusätzliche Regressionstests an mehreren Stellen erforderlich.

  • Das Ändern des Codes, der zum Laden von Daten in ein DataSet verwendet wird, wird schwieriger, wenn sich die Quelle dieser Daten ändert. Wenn Sie z. B. eine Textdatei zum Speichern von Daten verwenden und dann zu SQL Server wechseln, ändert sich auch die Zugriffsmethode. Darüber hinaus sind in vielen Bereichen Codeänderungen erforderlich, um Daten in das DataSet Ihrer Anwendung zu laden.

Anwendung mit drei Ebenen und einem XML-Webdienst


Eine andere Entwurfsoption besteht in der Verwendung eines XML-Webdienstes, um den Zugriff der Datenbank auf eine andere Komponente abzutrennen, die die Daten an die Front-End-Anwendung zurückgibt. Abbildung 2 veranschaulicht diese Entwurfsoption.
Weitere Informationen zum Entwickeln einer Anwendung mit drei Ebenen mithilfe von XML-Webdiensten können Sie über das MSDN-Suchmodul finden.

Bild02
Abbildung 2. Verwenden eines XML-Webdienstes zum Trennen der Datenbankebene vom Front-End-Code


Wann ist diese Technik zu empfehlen
Eine Anwendung mit drei Ebenen, in der ein XML-Webdienst verwendet wird, eignet sich für eine webbasierte oder Microsoft Windows®-Anwendung. Diese Technik ist praktisch, wenn Sie eine anspruchsvolle Desktopanwendung benötigen, die Benutzer jedoch von unterschiedlichen Standorten aus eine Verbindung zur Anwendung herstellen und über eine HTTP-Schnittstelle auf die Daten zugreifen.

Standardoptionen für die Implementierung
Zum Erstellen einer Anwendung mit drei Ebenen und einem XML-Webdienst werden zumeist die folgenden Entwicklungstechniken verwendet:

  • SQL befindet sich vollständig im XML-Webdienst. DataSets werden auf dem Server erstellt und als XML-Stream an den Client zurückgegeben, wo sie erneut in DataSets umgewandelt werden.

  • Vom XML-Webdienst zurückgegebene DataSets können direkt an die Steuerelemente in den Formularen gebunden werden.

  • Vom XML-Webdienst zurückgegebene DataSets können dazu verwendet werden, Daten manuell in unterschiedliche Steuerelemente in den Formularen zu laden.

  • Alle Geschäftsregeln werden direkt in den Formularen codiert.

Vorteile

Eine Anwendung mit drei Ebenen, die einen XML-Webdienst verwendet, hat die folgenden Vorteile:

  • Die Entwicklung kann schnell und problemlos durchgeführt werden, da Sie ein ADO.NET-DataSet mithilfe von Datenbindung direkt mit vielen der Steuerelementen verbinden können, die zum Erstellen der Benutzeroberfläche verwendet werden. Dadurch können die grundlegenden Funktionen einer Anwendung schnell gestartet und ausgeführt werden.

  • Benutzer können Ihre Anwendung von jedem Ort ausführen, an dem eine Internet- bzw. Intranetverbindung vorhanden ist.

  • Der Datenbankzugriff ist auf die Datenbankkomponente beschränkt, so dass kein SQL im Front-End-Code eingebettet ist.

  • Verbindungsinformationen werden nur im XML-Webdienst gepflegt, so dass der Wartungsaufwand des Clientcomputers weiter minimiert wird.

  • Die Datenbankzugriffsebene kann an zentraler Stelle aktualisiert werden. Komponenten müssen nicht erneut an den Client verteilt werden, wenn Sie auf dieser Ebene eine einfache Codeänderung durchführen.

Nachteile

Die Nachteile sind im Wesentlichen dieselben wie für eine Standardanwendung mit zwei Ebenen, da Sie die Geschäftsregeln noch nicht abgetrennt haben, sondern nur die Datenebene. Sie haben auch die Spaltennamen in den Tabellen noch nicht in einer Klasse zusammengefasst - dies lernen Sie im nächsten Abschnitt.

  • Alle Geschäftsregeln sind im Front-End-Code enthalten. Daher müssen alle Clients aktualisiert werden, wenn Sie eine Geschäftsregel ändern müssen. Wenn Sie keine automatische Aktualisierung verwenden, kann dies zu einem kaum zu bewältigenden Wartungsaufwand führen. Wenn Sie SQL Server verwenden, können Sie jedoch einige Geschäftsregeln in Form von gespeicherten Prozeduren erstellen und so Dauer und Kosten der Wartung reduzieren.

  • Alle Feldnamen sind entweder im Quellcode oder in den Steuerelementeigenschaften hart codiert. Wenn Sie einen Feldnamen ändern, müssen Sie jedes Vorkommnis in Ihrer Anwendung suchen und ersetzen. Wenn Sie Datenbindung verwenden, müssen Sie zudem alle Formulare überprüfen und die Eigenschaften ändern.

  • Die Leistung über eine HTTP-Schnittstelle ist langsamer als eine direkte Datenbankverbindung.

  • Wenn der Benutzer nicht über Internet- bzw. einen Intranetzugang verfügt, kann die Anwendung nicht verwendet werden.

Anwendung mit drei Ebenen und .NET Remoting


Dieser Anwendungsarchitekturtyp entspricht nahezu vollständig der Anwendung mit drei Ebenen, die einen XML-Webdienst verwendet. Der einzige Unterschied besteht darin, dass Sie statt eines XML-Webdienstes zum Wrappen der Datenzugriffsebene .NET Remoting verwenden. Abbildung 3 veranschaulicht diese Entwurfsoption.

Weitere Informationen zu .NET Remoting finden Sie in weiteren Artikeln dieser Reihe oder mithilfe des MSDN-Suchmoduls.

Bild03
Abbildung 3. Beim Arbeiten in einer LAN-Umgebung können Sie zum Wrappen der Datenzugriffsebene .NET Remoting verwenden.


Wann ist die Technik mit drei Ebenen und .NET Remoting zu empfehlen
Eine Anwendung mit drei Ebenen, in der .NET Remoting verwendet wird, eignet sich für eine Anwendung, die auf mehrere Computer in einem LAN verteilt werden muss. Dies kann aus betrieblichen Gründen erforderlich sein oder wenn der Bedarf der anfallenden Arbeit die Kosten des Netzwerkaufrufs rechtfertigt.

Standardoptionen für die Implementierung
Zum Erstellen einer Anwendung dieses Typs werden meist die folgenden Entwicklungstechniken verwendet:

  • SQL befindet sich vollständig in der Komponente, die über den Remotedienst aufgerufen wird. DataSets werden auf dem Server erstellt und als XML-Stream an den Client zurückgegeben, wo sie erneut in DataSets umgewandelt werden.

  • Von der Remotekomponente zurückgegebene DataSets werden direkt an die Steuerelemente in Ihren Formularen gebunden.

  • Von der Remotekomponente zurückgegebene DataSets werden dazu verwendet, Daten manuell in die unterschiedlichen Steuerelemente in Ihren Formularen zu laden.

  • Alle Geschäftsregeln werden direkt in den Formularen codiert.

Vorteile
Eine Anwendung mit drei Ebenen, die .NET Remoting verwendet, bietet dieselben grundsätzlichen Vorteile wie eine Anwendung mit drei Ebenen, die einen XML-Webdienst verwendet.

  • Anwendungen mit drei Ebenen können schnell und problemlos programmiert werden, da Sie Datenbindung verwenden können, um ein ADO.NET-DataSet direkt mit vielen der Steuerelemente zu verbinden, die zum Erstellen der Benutzeroberfläche verwendet werden. Dadurch können die grundlegenden Funktionen einer Anwendung schnell gestartet und ausgeführt werden.

  • Benutzer können diese Anwendung von jedem Ort ausführen, an dem eine LAN- oder WAN-Verbindung vorhanden ist.

  • Der Datenbankzugriff ist auf eine andere Komponente beschränkt, so dass kein SQL im Front-End-Code eingebettet ist.

  • Die Datenbankzugriffsebene kann an zentraler Stelle aktualisiert werden. Komponenten müssen nicht erneut an den Client verteilt werden, wenn Sie eine einfache Codeänderung in dieser Komponente durchführen.
    Anmerkung Dieser Vorteil gilt für jede Architektur mit n Ebenen.

Nachteile
Die Nachteile bei diesem Typ eines Entwurfs mit drei Ebenen sind dieselben, die bereits für die Verwendung eines XML-Webdienstes beschrieben wurden.

  • Alle Geschäftsregeln sind im Front-End-Code enthalten. Daher müssen alle Clients aktualisiert werden, wenn Sie eine Geschäftsregel ändern müssen. Wenn Sie keine automatische Aktualisierung verwenden, kann dies zu einem kaum zu bewältigenden Wartungsaufwand führen. Wenn Sie SQL Server verwenden, können Sie jedoch einige Geschäftsregeln in Form von gespeicherten Prozeduren erstellen und so Dauer und Kosten der Wartung reduzieren.

  • Alle Feldnamen sind entweder im Quellcode oder in den Steuerelementeigenschaften hartcodiert. Wenn Sie einen Feldnamen ändern, müssen Sie jedes Vorkommnis in Ihrer Anwendung suchen und ersetzen. Wenn Sie Datenbindung verwenden, müssen Sie zudem alle Formulare überprüfen und die Eigenschaften ändern.

  • Die Datenübertragung von einer Komponente zu einer anderen über ein Netzwerk ist langsamer als eine direkte Datenbankverbindung. In einem Intranetszenario ist .NET Remoting leistungsstärker als ein XML-Webdienst. In einem Internetszenario bietet sich die Verwendung von .NET Remoting weniger an.

  • Das Einrichten von Anwendungen dieses Typs ist etwas komplizierter als das Einrichten einer Anwendung mit zwei Ebenen oder einer Anwendung, die einen XML-Webdienst verwendet.

Logische Anwendungen mit n Ebenen

Der empfohlene Ansatz zum Erstellen einer Anwendung mit .NET besteht darin, alle logischen Prozesse in einzelne Klassen zu teilen. In einer standardmäßigen Unternehmensanwendung sind meist eine Geschäftsregelkomponente, eine Datenebenenkomponente und der Front-End-Code enthalten, der diese Komponenten verwendet. Abbildung 4 veranschaulicht diesen Ansatz.
Weitere Informationen zum Entwerfen einer Anwendung mit n Ebenen finden Sie in weiteren Artikeln dieser Reihe oder mithilfe des MSDN-Suchmoduls.

Bild04
Abbildung 4. Aufteilen eines Geschäftsprozesses in separate Klassen, um das Erstellen und Warten Ihrer Anwendung zu vereinfachen


Wann ist eine Architektur mit n Ebenen zu empfehlen
Das Verwenden einer logischen Entwicklungsstrategie mit n Ebenen eignet sich für alle Anwendungstypen. Die Strategie funktioniert in Anwendungen mit kleinem, mittlerem und großem Umfang und kann mit Desktop- und Webanwendungen verwendet werden.
Standardoptionen für die Implementierung
Zum Aufbau einer Anwendung dieses Typs werden meist die folgenden Entwicklungstechniken verwendet:

  • Programmieren der Front-End-Benutzeroberfläche mit Windows Forms oder Web Forms.

  • Programmieren der Geschäftsregelkomponente als separates Klassenbibliotheksprojekt.

  • Aufbau einer Datenebenenkomponente als separates Klassenbibliotheksprojekt. Diese Datenebene verwendet Klassen, um den Zugriff auf alle Tabellen zu wrappen. Sie sollten DataSets mit Typbindung verwenden; diese stellen die Flexibilität der DataSet-Klasse sowie eine starke Typbindung für jede Spalte in den Tabellen zur Verfügung.

Vorteile
Eine logische Anwendung mit n Ebenen hat folgende Vorteile:

  • Zentrale Geschäftsregeln in einer Komponente, die einfach erstellt, verwendet und wiederverwendet werden können. Dadurch werden Entwicklung und Wartung vereinfacht.

  • Stellt eine Sprache auf hohem Niveau für das Entwickeln von Geschäftsregeln zur Verfügung, die statt gespeicherter Prozeduren und einer begrenzten SQL-Sprache für die Überprüfung von Geschäftsregeln verwendet werden kann.

  • Stellt zentralen Datenzugriff in einer Komponente zur Verfügung. Dadurch reduziert sich der in Ihrer Anwendung wiederholte Code; alle Formulare, die Zugriff auf eine bestimmte Tabelle benötigen, verwenden immer dieselbe Komponente.

  • Wenn Sie DataSets mit Typbindung verwenden, können Sie Spaltennamen mithilfe von IntelliSense suchen, so dass Sie sich die Spaltennamen nicht unbedingt merken müssen.

  • Zentral konsolidierte Datenzugriffsroutinen unterstützen Sie bei der Wartung, da Änderungen an Datenzugriffsroutinen jeweils nur ein Mal durchgeführt werden müssen.

  • Ermöglicht es, Komponenten flexibel jederzeit auf mehrere physische Computer zu verteilen. Dies unterstützt Sie bei der Skalierung und verbessert die zentrale Konsolidierung von Code.

Nachteile
Eine logische Anwendung mit n Ebenen hat zwei bedeutende Nachteile:

  • Die Entwicklung dauert ein wenig länger, da Sie separate Komponenten programmieren müssen.

  • Die Anzahl der zu überwachenden Komponenten ist etwas größer. Daher ist diese Entwicklungsmethode für unerfahrene Programmierer etwas schwieriger zu verstehen.

Anwendung mit n Ebenen und einem XML-Webdienst

Abbildung 5 zeigt ein Beispiel eines logischen Anwendungsentwurfs mit n Ebenen, der auf mehrere Computer verteilt ist. In diesem Diagramm sehen Sie, dass ein XML-Webdienst für den Zugriff auf die Datenebene verwendet wird. Das DataSet mit Typbindung wird über die HTTP-Ebene an die Geschäftsregelebene zurückgegeben. Die Clientanwendung kann das DataSet dann für die Darstellung der Daten auf der Benutzeroberfläche verwenden.

Bild05
Abbildung 5. Verteilen Sie Ihre Geschäftsprozesse auf separate Computer, um Bereitstellung und Wartung zu vereinfachen.


Wann ist diese Technik zu empfehlen
Der Anwendungsentwurftyp mit n Ebenen und XML-Webdienst ist geeignet, wenn Sie eine anspruchsvolle Desktopanwendung benötigen, die Benutzer jedoch von unterschiedlichen Remote-Standorten aus eine Verbindung zur Anwendung herstellen und über eine HTTP-Schnittstelle auf die Daten zugreifen. Das Belassen der Geschäftsregeln auf der Clientseite verringert den Netzwerkverkehr, kann jedoch zu Aktualisierungsschwierigkeiten bei der Wartung führen, wenn sich die Regeln häufig ändern. Da .NET neue DLLs ohne Registrierung überschreiben kann, sind diese Probleme jedoch nicht so schwerwiegend wie in früheren Technologien.

Dieses Szenario kann auch für Web-basierte Anwendungen hilfreich sein, in denen die Daten von einem Webserver zur Verfügung gestellt, jedoch von einer anderen Webanwendung auf einem anderen Webserver angezeigt werden.

Standardoptionen für die Implementierung
Zum Erstellen einer Anwendung dieses Typs werden meist die folgenden Entwicklungstechniken verwendet: Die Techniken sind mit denen der logischen Anwendung mit n Ebenen identisch.

  • Erstellen der Front-End-Benutzeroberfläche mit Windows Forms oder Web Forms.

  • Erstellen der Geschäftsregelkomponente als separates Klassenbibliotheksprojekt.

  • Erstellen einer Datenebenenkomponente als separates Klassenbibliotheksprojekt. Diese Datenebene verwendet Klassen, um den Zugriff auf alle Tabellen zu wrappen. Sie sollten DataSets mit Typbindung verwenden; diese stellen die Flexibilität der DataSet-Klasse sowie eine starke Typbindung für jede Spalte in den Tabellen zur Verfügung.

Vorteile


Eine Anwendung mit n Ebenen, die einen XML-Webdienst verwendet, bietet mehrere Vorteile, die zum großen Teil mit den Vorteilen der logischen Anwendung mit n Ebenen identisch sind.

  • Zentrale Geschäftsregeln in einer Komponente, die einfach erstellt, verwendet und wiederverwendet werden können. Dadurch werden Entwicklung und Wartung vereinfacht.

  • Stellt eine Sprache auf hohem Niveau für das Entwickeln von Geschäftsregeln zur Verfügung, die statt gespeicherter Prozeduren und einer begrenzten SQL-Sprache für die Überprüfung von Geschäftsregeln verwendet werden kann.

  • Stellt zentralen Datenzugriff in einer Komponente zur Verfügung. Dadurch reduziert sich der in Ihrer Anwendung wiederholte Code; alle Formulare, die Zugriff auf eine bestimmte Tabelle benötigen, verwenden immer dieselbe Komponente.

  • Wenn Sie DataSets mit Typbindung verwenden, können Sie Spaltennamen mithilfe von IntelliSense suchen, so dass Sie sich die Spaltennamen nicht unbedingt merken müssen.

  • Zentral konsolidierte Datenzugriffsroutinen unterstützen Sie bei der Wartung, da Änderungen an Datenzugriffsroutinen jeweils nur ein Mal durchgeführt werden müssen.

  • Ermöglicht es, Komponenten flexibel jederzeit auf mehrere physische Computer zu verteilen. Dies unterstützt Sie bei der Skalierung und verbessert die zentrale Konsolidierung von Code.

  • Zusätzlicher Vorteil: Zentrale Datenzugriffsebene.

  • Zusätzlicher Vorteil: Anwendungsskalierbarkeit - Sie können eine Webfarm hinzufügen, um enorme Belastungen durch Benutzeranforderungen an die Datenbank zu verarbeiten.

  • Zusätzlicher Vorteil: Benutzer können über das Internet eine Verbindung herstellen und dennoch über eine Desktop- oder webbasierte Anwendung auf die Daten zugreifen.

Nachteile


Eine Anwendung mit n Ebenen, die einen XML-Webdienst verwendet, hat einige Nachteile. Die meisten Nachteile sind mit den Nachteilen identisch, die im Zusammenhang mit der Verwendung des Entwicklungsszenarios der logischen Anwendung mit n Ebenen beschrieben wurden.

  • Die Entwicklung dauert ein wenig länger, da Sie separate Komponenten programmieren müssen.

  • Die Anzahl der zu verfolgenden Komponenten ist etwas höher. Daher ist diese Entwicklungsmethode für unerfahrene Programmierer etwas schwieriger zu verstehen.

  • Wenn der XML-Webdienst nicht funktionsfähig ist, kann die Anwendung nicht verwendet werden.

Weitere Techniken für Anwendungen mit n Ebenen

Für den Aufbau einer Anwendung mit n Ebenen können viele unterschiedliche Techniken verwendet werden. Sie können beispielsweise .NET Remoting verwenden, um von der Clientebene mit der Geschäftsregelebene zu kommunizieren. Dies ist in Abbildung 6 dargestellt.

Bild06
Abbildung 6. Sie können eine Kombination von .NET Remoting und XML-Webdiensten verwenden, um die maximale Skalierbarkeit und einfaches Verwalten für Ihre Anwendung zu erreichen.


Es gibt eine Vielzahl von Möglichkeiten, eine Anwendung mit n Ebenen zu konfigurieren, nachdem Sie sie mithilfe entsprechender Techniken entwickelt haben. Sie können die in .NET verfügbaren Methoden kombinieren, um die Ebenen einer Anwendung zu trennen.

Migrieren einer Visual-Basic-6.0-Anwendung mit n Ebenen

Programmierer haben in früheren Versionen von Microsoft Visual Basic® seit Jahren Techniken für n Ebenen verwendet. Wenn Sie aktuell über COM-Komponenten verfügen, können Sie diese problemlos mit einem .NET-Wrapper umgeben. Sie verfügen anschließend über eine Architektur, die der in Abbildung 7 gleicht.
Weitere Informationen zum Verwenden von COM-Komponenten in .NET finden Sie in weiteren Artikeln dieser Reihe oder mithilfe des MSDN-Suchmoduls auf der MSDN-Website.

Bild07
Abbildung 7. Mit .NET können Sie problemlos eine Schnittstelle zu Ihren vorhandenen COM-Komponenten nutzen.


Wann ist die Verwendung der Visual-Basic-Migrationstechnik zu empfehlen
Diese Technik ist besonders gut geeignet, wenn Sie über eine große Codebasis von COM-Komponenten verfügen, in denen Ihre Geschäftsregeln und Datenzugriffsroutinen bereits enthalten sind. Auf diese Weise können Sie die Kosten Ihres Wechsels zu .NET Framework senken, da Sie vorhandenen Code in beträchtlichem Umfang nutzen werden.

Standardoptionen für die Implementierung
Zum Aufbau einer Anwendung dieses Typs werden meist die folgenden Entwicklungstechniken verwendet:

  • Erstellen der Front-End-Benutzeroberfläche mit Windows Forms oder Web Forms.

  • Festlegen eines Verweises zu Ihrer alten COM-DLL. Microsoft .NET erzeugt automatisch einen .NET-Wrapper um diese DLL, so dass Sie auf die Eigenschaften und Methoden wie auf eine beliebige .NET-Komponente zugreifen können.

  • Wenn Sie ADO-Recordsets von dieser DLL zurückgeben, sollen diese in der Regel in ein DataSet umgewandelt werden - die einfachste Möglichkeit, eine Bindung an die .NET-Steuerelemente herzustellen.

Vorteile
Das Verwenden des .NET-Wrappers um eine COM-Schnittstelle kann Ihren Entwicklungszyklus beschleunigen, da Sie die Vorteile der neuen .NET-Features nutzen und zugleich den vorhandenen Code verwenden.

Nachteile
Das Verwenden eines COM-Wrappers in .NET hat folgende Nachteile:

  • Die Leistung ist weniger gut als beim Verwenden von Code, der vollständig in .NET geschrieben wurde.

  • Zum Konvertieren eines ADO-Recordsets in ein ADO.NET-DataSet ist möglicherweise zusätzlicher Code erforderlich.

Zusammenfassung

Bei der Entwicklung von .NET-Anwendungen stehen Ihnen unzählige Architekturvarianten zur Verfügung. Die besten dieser Architekturen sind einfach zu erstellen und zu warten. Weitere Entwicklungsziele wie Skalierbarkeit, Zuverlässigkeit und das einfache Verwalten spielen jedoch ebenfalls eine Rolle. Viele dieser Themen sind in anderen Whitepapern beschrieben, die Sie auf der MSDN-Site finden.

Über die Informant Communications Group
Die Informant Communications Group, Inc. (wm) www.informant.com ist ein vielseitiges Medienunternehmen mit dem Schwerpunkt Informationstechnologie. Die ICG wurde 1990 gegründet und ist auf Softwareentwicklungspublikationen, Konferenzen, Katalogveröffentlichungen und Websites spezialisiert. Im Bereich Medien und Marketing hat sich die ICG als Integrationsunternehmen für Inhalte Respekt erworben und als Anbieter für den wachsenden Bedarf der IT-Spezialisten an qualitativ hochwertigen technischen Informationen einen Namen gemacht. Niederlassungen der ICG finden sich in den USA und Großbritannien.

Links zu verwandten Themen

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.