Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

From DNA to .NET strategies

Veröffentlicht: 28. Jun 2001 | Aktualisiert: 18. Jun 2004
Von Bijan Javidi

Microsoft .NET ist die Anwendungsarchitektur und .NET Framework ist die neue Anwendungsplattform. Der Aufwand für die Migration auf .NET-Plattform kann mit Einhaltung von Architekturempfehlungen minimiert werden.

* * *

Auf dieser Seite

Was ist .NET Was ist .NET
From DNA to .NET From DNA to .NET

Was ist .NET

Microsoft .NET ist ein neues Architekturmodell und eine Plattform für die nächste Generation der internetzentrierten Informationsverarbeitung. .NET erlaubt die Transformation von klassischen Applikationen und Websites zu wiederverwendbaren Webservices. Hiermit können Computerprogramme über die Plattformgrenzen hinaus solche Services nutzen. Die Vorteile dieser Strategie liegen auf der Hand: Basierend auf standardisierten Internetprotokollen (z.B. HTTP, HTML, XML, SOAP, UDDI) lassen sich Geschäftsprozesse über Unternehmens- und Plattformgrenzen hinaus integrieren. Auß;erdem erhalten Anwender jederzeit und von jedem beliebigen Gerät aus direkten Zugriff auf ihre Daten.

Microsoft .NET ist die dritte Generation der Entwicklungstechnologien, die das Internet zum Kern der Informationsverarbeitung macht. Die .NET Entwicklungsplattform weist eine innovative Infrastruktur auf, die die Entwicklung und Installation von Anwendungen
im Internetzeitalter erheblich erleichtert. .NET stellt eine völlig neue Richtung in der Entwicklung von Software dar. Sie bietet viele Möglichkeiten, die hinsichtlich Wiederverwendung von Codes, Spezialisierung vorhandener Komponenten, Verwaltung der Ressourcen, Entwicklung von Anwendungen mit verschiedenen Sprachen, Sicherheit, Installation und Administration die Programmierung erheblich erleichtern.

From DNA to .NET

Die bisherige Entwicklungsarchitektur von Microsoft heiß;t Windows DNA. Diese empfiehlt eine Schichtenarchitektur mit Middleware und Komponenten. Die neue .NET Architektur bringt viele Vorteile und vereinheitlicht die bisherigen Programmierungsmodelle wie im Bild 1.

So musste man sich vor .NET für ein Programmierungsmodell entscheiden und auch mit den Einschränkungen und Nachteilen dieses Modells leben. Darüber hinaus verursacht jedes Programmierungsmodell - fast unabhängig voneinander - Kosten, die sich in Form von Personal, Infrastruktur und Tools niederschlagen. Nicht selten sehen wir eine C++/MFC Entwicklergruppe neben der Visual Basic Mannschaft. Die Reduzierung des Programmierungsmodells auf eins ist eine massive Optimierung, die alle Ressourcen der Entwicklung entlastet. Gemeint sind Infrastruktur, Tools, Entwickler und Manager.

Jede Änderung und selbst eine Verbesserung muss erst gelernt, geplant und kontrolliert eingeführt werden. Wie gewohnt, bieten Microsoft und Partner diverse Unterstützungen in Form von Literatur, Schulungen, Schulungsmaterial und Consulting Services an. Das Lernen der neuen Technologie ist der entscheidende Schritt für eine optimale Migration. Genau an dieser Stelle setzt das Projekt "Microsoft .NET developer Tools readiness kit" an. Um das Lernen zu erleichtern und zu beschleunigen, haben wir erstmalig in Deutschland die weltweite Führung bei der Erstellung von Workshop-Material übernommen und dieses Projekt gestartet, das 32 Module produziert, die alle Aspekte der .NET Entwicklungstechnologien abdecken. Drei Module adressieren das Migrationsthema. Diese Module betrachten die Migration aus drei verschiedenen Perspektiven.

Vorweg ist eine Grundsatzentscheidung zu treffen, bevor wir uns mit der Migration auseinandersetzen: Die wichtigste Frage der Portierung ist die Notwendigkeit. Eine Anwendung, die am Ende ihres Lebenszyklus steht, ist kein geeigneter Kandidat. Es gibt keinen Zwang für eine derartige Migration, da die WinDNA Technologien so lange unterstützt werden, wie der Markt es entscheidet.

Jede Migration muss sich rechtfertigen durch z.B. neue Funktionen, Reduzierung der Betriebskosten, bessere Qualität. Auß;erdem muss die Migration strategisch durchdacht sein. Ziel ist eine möglichst sanfte und effiziente Migration. Diese Strategie muss selbstverständlich auch vor allem die Plattform berücksichtigen. Sie muss sich mit Themen wie Planung, Pilotierung, Einführung und der Koexistenz beider Plattformen - alt und neu - auseinandersetzen. Dieser Artikel beschäftigt sich nur mit dem Thema Entwicklung.

So wurden drei Wissensgebiete identifiziert, die eine Migration zu .NET unterstützen können und Ihnen das erforderliche Know-how in einer sehr kompakten Form zur Verfügung stellen:

  1. From DNA to .NET Porting

  2. From DNA to .NET Knowledge Path

  3. From DNA to .NET Design Path

1. From DNA to .NET Porting
Dieses Modul behandelt die klassische Portierung, wo die Kodierung einer vorhandenen Anwendung so lange angepasst wird, bis diese in der neuen Umgebung fehlerfrei läuft. Dieses Themengebiet ist sehr umfangreich und deckt viele Technologien ab. Portierung von Visual Basic 6.0 zur Visual Basic.NET und die Anwendung des Visual Basic.NET Upgrade Wizard sind nur der Anfang.

Ein weiteres Beispiel ist die Migration von J++ Anwendungen. Hierfür gibt es das "JUMP to .NET" Paket - Java User Migration Path. Dieses Paket beinhaltet verschiedene Technologien und Services. Interoperabilitätsunterstützung, Programmierungstools sowie ein Java zu C# Konverter sind Bestandteile dieses Pakets.

2. From DNA to .Net Knowledge Path
Das Programmierungswissen besteht nicht nur aus Syntax-Kenntnissen. Noch viel wertvoller ist das Know-how, wie man z.B. eine bestimmte Aufgabe durch Aufrufe der Laufzeitfunktionen löst. Deshalb ist das "Know-how mapping" das Thema dieses Moduls. .NET Framework bietet zahlreiche neue Klassen mit neuen Namen. Welche Funktion erstellt eine Datei und welche stellt eine Internetverbindung her, sind die Fragen, die gezielt beantwortet werden. Meistens ist eine 1:1-Zuordnung möglich, während in Ausnahmefällen eine Umschreibung der Kodierung notwendig ist.

Tabelle 1 zeigt ein Beispiel aus diesem Modul.

API

MFC

VB

.NET

CreateFile

CFile::Open

Open

System.IO.File.Create

CopyFile


FileCopy

System.IO.File.Copy

MoveFile


Name

System.IO.File.Move

DeleteFile

CFile::Remove

Kill

System.IO.File.Delete

Dieses Modul wird als ein Web Service im Internet publiziert, wo es als "Know-How Lookup Table" jedem zur Verfügung steht.

3. From DNA to .Net Design Path
Das dritte Modul ist rein strategisch und beschäftigt sich mit den Designaspekten. Dieses Thema repräsentiert den Kern der Diskussion. Selbst wenn Sie heute nicht mit .NET anfangen können, ist es ratsam, bestimmte Designempfehlungen zu beachten, die eventuelle Portierungskosten minimieren. Die Idee ist, mit .NET im Hinterkopf zu entwerfen. Unser Motto ist "Design for .NET and build with DNA". So können vor allem Entwicklungsprojekte, die heute noch in den Startlöchern stecken, die Weichen für einen sanften Übergang zu .NET stellen.

Die wirtschaftliche Migration fängt mit der richtigen Architektur an. Jede .NET Richtlinie, die heute in der Architektur eingebaut wird, reduziert die Portierungskosten von morgen erheblich. Bei genauer Betrachtung stellen wir fest, dass solche Empfehlungen sowieso "best practices" sind. Unsere Untersuchungen haben gezeigt, dass z.B. ASP (Active Server Pages) zu ASP.NET einen optimalen Portierungspfad darstellt. Dabei wird die Kodierung in der Regel bis zu 10 mal reduziert, die Performance durch Wegfall der Interpretation um einen Faktor verbessert und die Stabilität erheblich erhöht.

Die generelle Empfehlung ist, das Migrationsprojekt in kleinen überschaubaren Paketen zu planen und nicht gleichzeitig an allen Ecken des Systems umzubauen. Die optimale Strukturierung strebt die Lauffähigkeit des Systems nach jedem abgeschlossenen Schritt an. Die Vorteile bestehen nicht nur aus frühzeitiger Nutzung, sondern auch aus Risikominimierung und Qualitätskontrolle.

Zur Verdeutlichung nehmen wir ein fiktives ASP-Projekt als Beispiel. Dieses Projekt befindet sich in der Design-Phase. Es wurde beschlossen, dass Windows DNA Technologien und Architektur angewendet und die Anwendung später auf .NET portiert wird. Mit .NET im Sinne setzen wir folgende Technologien ein:

ASP: Active Server Pages mit Visual Basic
COM+ Komponenten: Die Komponententechnologie mit Visual Basic
MSXML: Microsoft XML
ADO: Active Data Objects

Hinzu kommen folgende Design-Empfehlungen, die nicht nur die Migration auf .NET erleichtern, sondern auch die Anwendung verbessern.

Schichtenarchitektur
Die Anwendung sollte mindestens aus drei Schichten bestehen: Präsentation, Geschäftslogik und Daten. Eine so genannte Geschäftslogikschicht-Facade verkapselt die Geschäftslogikschicht und ist das einzig Sichtbare für die Präsentationsschicht.

Clientseitiges Scripting
Ist zu vermeiden, da dieses - unter anderem - zur Browserabhängigkeit führt.

Maximale Trennung zwischen Präsentation und Logik innerhalb ASP
Zugegeben ist Scripting in ASP unvermeidbar. Dieses muss aber auf ein Minimum reduziert werden. Die Kodierung muss jedoch mehrheitlich in Komponenten untergebracht werden. Scripting wird als "Klebstoff" zwischen Komponenten genannt. Das Prinzip lautet "den Klebstoff dünn auftragen".

Klare Rollendefinition
Jede Komponente sollte eine klare Aufgabe erfüllen.

Globale
Sollten in Funktionen und Klassen verkapselt sein.

XML/XSLT statt Scripting
Mit XML/XSLT sind Sie auf der sicheren Seite und bestens für die Zukunft ausgestattet.

Die Migration auf .NET kann z.B. folgende Schritte beinhalten:

  1. ASP zu ASP.NET
    ASP Script Code in Objekt-Klassen übertragen. Dabei wird die Kodierung vom Layout getrennt, was eine erhebliche Verbesserung und Übersichtlichkeit erzielt. Dadurch steigt die Kodierungsqualität deutlich und gleichzeitig genieß;t der Anwender eine wesentlich bessere Performance. Die Middleware COM+ Komponenten können ohne weiteres von der Präsentationsschicht angesprochen werden und müssen noch nicht migriert werden. Nach diesem Schritt ist die Anwendung wieder lauffähig. Die Teilinvestition für die Migration hat bereits die Nutzung verbessert.

  2. COM+ zu .NET
    COM+ Komponenten auf .NET portieren. Visual Basic Komponenten lassen sich in der Regel fast ohne Änderung portieren. Voraussetzung hierfür ist die Beachtung von Richtlinien der Komponentenprogrammierung. Neben einer besseren Kodierung steigt auch die Performance. Wiederum dient der zweite Schritt als Meilenstein für die Qualitätskontrolle.

  3. MSXML zu .NET XML
    Microsoft .NET Framework bietet eine neue Gruppe von XML APIs, die auf Industriestandards basieren wie z.B. DOM, XPath, XSD, and XSLT. Der dritte Schritt ersetzt die Aufrufe auf MSXML durch Aufrufe auf .NET XML Klassen. Dieser Schritt ist vor allem eine Investition in offene Standards. Die Anwendung kann anschließ;end eingesetzt werden.

  4. ADO zu ADO.NET
    An der Stelle ersetzen wir ADO durch ADO.NET. Genau wie ADO, ist ADO.NET eine API (Application Programming Interface). Es ist im Gegensatz zu ADO auf einem verbindungslosen Modell aufgebaut. ADO.NET ist vor allem optimiert für den Einsatz im Internet, wo die Verbindungslosigkeit (disconnected) eine Selbstverständlichkeit ist. Datensätze werden in XML zwischen Client und Server transportiert. Nach einer kurzen Verbindung kann der Client mit dieser (XML)-Kopie der Daten arbeiten, während der Server andere Clients bedient.
    Nach diesem Schritt sind alle COM-Aufrufe entfernt.

  5. Optimierung
    Technisch gesehen ist die Migration nach dem vierten Schritt schon abgeschlossen. Es gibt trotzdem die Möglichkeit, neue .NET Technologien in Anspruch zu nehmen, die Verbesserungen in der Anwendung erzielen. Gute Beispiele sind Web-Controls, Validatoren (validators) oder Caching. Diese Technologien verbessern die Performance und Qualität der Anwendung.

Für eine kostenlose .NET readiness kit CD, genügt eine Email mit "NETRK" auf der Betreff-Zeile an bijanj@microsoft.com.


Anzeigen:
© 2015 Microsoft