ClientServer Entwicklung mit VFP Gary de Witt In diesem Buchauszug bricht der Autor Gary de Witt eine richtig tolle Lanze für Visual FoxPro als Client/Server-Entwicklungsumgebung und liefert detaillierte Argumente für die seines Erachtens sechs wichtigsten Vorteile von Visual FoxPro gegenüber anderen Entwicklungssystemen. Ein Artikel, mit dessen Hilfe man sehr gut argumentieren kann und der alleine schon den Kauf des Buchtitels lohnt – hier in deutscher Übersetzung, damit die Aussagen auch direkt an an Auftrag- oder Arbeitgeber weiterleiten kann, was anempfohlen sei. Kapitel 2Nachdem Sie Kapitel 1 gelesen haben, sollten Sie über ein gutes Verständnis verfügen, was Client/Server-Datenbanken besonders macht und weshalb Sie sie einsetzen sollten. Die $64.000-Frage ist aber: Weshalb sollten Sie Visual FoxPro benutzen, um Ihre Client/Server-Anwendungen zu entwickeln? Dieses Kapitel beantwortet die Frage für Sie, den Entwickler und gibt Ihnen Antworten, die Sie Ihren Kunden geben können, wenn diese die Frage stellen. Mehr als die Hälfte der Softwareentwickler benutzen heute eine der verschiedenen Variationen des Beginner’s Allpurpose Symbolic Instruction Code (BASIC), herausgegeben von Microsoft. Weshalb? Zum Teil, weil sie damit vertraut sind, zum Teile wegen der Vielseitigkeit und zum Teil, weil Popularität neue Popularität erzeugt. Aber erinnern Sie sich was Ihre Eltern Ihnen gesagt haben: „Nur weil es jeder macht musst Du es nicht auch machen“. Dieses Kapitel behandelt sechs Eigenschaften, die Visual FoxPro zum besten heute verfügbaren Werkzeug für die Client/Server-Entwicklung machen:
Viele dieser Features könnten Inhalt eines eigenen Buches sein oder sind es sogar. Auch wenn wir die Features einzeln besprechen, sollten Sie immer im Hinterkopf behalten, dass es die Kombination dieser Features ist, die VFP zu einem großartigen Werkzeug für die Client/Server-Entwicklung machen. Es gibt nicht viele Entwicklungswerkzeuge, die eine Kombination von Features anbieten können, wie wir sie in Visual FoxPro finden. Visual Basic zum Beispiel bietet eine großartige Unterstützung von COM, Unterstützung für ADO und ist eine hervorragende RAD-Umgebung, aber es ist nicht objektorientiert, während C++ eine großartige objektorientierte Programmiersprache ist, aber deutliche Schwächen bei der nativen Unterstützung von Client/Server- oder lokalen Datenbanken aufweist. Außerdem hat nie jemand behauptet, dass C++ gut für RAD ist. Objektorientierte Programmierung (OOP)Lange Zeit war die Wiederverwendbarkeit von Code der heilige Gral der Softwareentwicklung. In einer prozeduralen Umgebung können wir einen gewissen Grad der Wiederverwendbarkeit erreichen, indem wir Bibliotheken mit Funktionen und Prozeduren schreiben, die bei Bedarf aufgerufen werden. Die objektorientierte Programmierung, oder OOP, macht Code durch den Einsatz von Objekten besser wiederverwendbar. In der realen Welt sind wir von Objekten umgeben, die jeweils physikalische Charakteristika aufweisen und von denen viele unterschiedliche Aufgaben ausführen können. In der Terminologie der objektorientierten Programmierung sind die Charakteristika eines Objekts die Eigenschaften und die Aufgaben, die ein Objekt ausführt, werden Methoden genannt. Eine Person hat verschiedene Charakteristika, z. B. Name, Adresse, Größe, Gewicht usw. Eine Person kann auch Aktionen ausführen, beispielsweise alle ihre Charakteristika aufschreiben. Ein Objekt in der Programmierung, das eine Person repräsentiert, könnte für jedes Charakteristikum eine Eigenschaft haben. Das Objekt Person kann auch eine Methode haben, die diese Eigenschaften niederschreibt – oder ausdruckt, wenn Sie so wollen. Die Repräsentation von Einheiten der realen Welt mit programmierten Objekten wird, obwohl ein wichtiger Teil der objektorientierten Programmierung, objektbasierte Programmierung genannt. Die meisten populären, modernen Programmiersprachen wie Visual FoxPro, Visual Basic, C++ und Java unterstützen die objektbasierte Programmierung. Bei der objektbasierten Programmierung handelt es sich durch den Einsatz von abstrakten Objekten, die Objekte der realen Welt darstellen, um einen Schritt in die richtige Richtung bei der Erhöhung der Wiederverwendbarkeit von Code. Es gibt zwei Features, die allen objektbasierten Programmiersprachen gemeinsam sind: Kapselung und Polymorphismus. Die Kapselung ist die Kombination von Daten und Code in einer einzigen Einheit. Die Daten, in Form von dem Objekt zugehörigen Speichervariablen, werden Eigenschaften genannt. Der Code, Methoden genannt, gibt dem Objekt die Fähigkeit, seine Daten zu manipulieren und andere Aktionen auszuführen. Den Vornamen einer Person in einer prozeduralen Sprache zu repräsentieren könnte eine globale Variable mit Namen gcFirstName erfordern. Der Wert der Variablen würde in Etwa so gesetzt:
Ein Objekt würden den Vornamen in einer Eigenschaft als Teil des Objekts kapseln:
Statt zu versuchen zahlreiche Speichervariablen für jede der zahlreichen Personen zu verfolgen, erfordern Objekte lediglich, dass der Programmierer die Speichervariablen für ein Objekt verwaltet. Das Objekt Person kann auch Code enthalten, z. B. die Fähigkeit, die Eigenschaften auszudrucken. Dieser Code ist als Methode bekannt und könnte Print() genannt werden. Um die Charakteristika einer Person in einem prozeduralen Programm auszudrucken, könnten Sie eine Funktion PrintPerson() schreiben, der Sie einen Parameter für die Charakteristika jeder Person übergeben:
Obwohl eine solche Funktion sicherlich wiederverwendbar ist, ist dies nicht einfach. Ein Objekt auf der anderen Seite könnte über eine Methode Print() verfügen, die allen erforderlichen Code enthält, um ihre Eigenschaften auszudrucken. Der Aufruf sieht so aus:
Welchen Aufruf würden Sie lieber wieder und wieder starten? Oder wichtiger: welcher Aufruf ruft beim wiederholten Gebrauch weniger Fehler hervor und erfordert daher weniger Debugging? Polymorphismus ist die Fähigkeit mehrerer Objekte, sich eine Schnittstelle zu teilen. Damit ist gemeint, dass die Eigenschaften die gleichen Namen und Datentypen haben, die Methoden haben die gleichen Namen, Parameter und Rückgabetypen. In der realen Welt ist jedem klar, dass Programmierer und Verkäufer nicht das Gleiche ist. Aber sie verfügen über die gleiche Schnittstelle, sowohl Programmierer als auch Verkäufer haben Namen, Adressen, Größe, Gewicht usw. Außerdem können alle Programmierer und die meisten Verkäufer ihre Charakteristika aufschreiben, auch wenn sie dies vielleicht unterschiedlich machen. Ein Verkäufer würde zweifelsfrei eine erheblich längere Beschreibung zu Papier bringen als ein Programmierer. Der Code der Methode Print() für einen Verkäufer könnte sich von der Methode Print() für einen Programmierer unterscheiden, aber wenn Sie die Objekte benutzen, werden beide auf die gleiche Art aufgerufen. Die objektorientierte Programmierung geht noch einen Schritt weiter. Genau wie in der realen Welt Kinder von ihren Eltern Charakteristika und Fähigkeiten erben können, so erben auch programmierte Objekte in einer objektorientierten Sprache Eigenschaften und Methoden von anderen Objekten. Eine Programmiersprache muss, um objektorientiert zu sein, nicht nur die Kapselung und den Polymorphismus unterstützen, sondern auch die Vererbung. In einer objektbasierten Sprache erfordern das Objekt Programmierer und das Objekt Verkäufer jeweils ihren eigenen Code. Aber in einer objektorientierten Sprache können sie sämtlichen Code für die gemeinsamen Funktionalitäten teilen. Da es sich in beiden Fällen um eine Person handelt, könnten Sie ein Objekt Person erstellen, das alle Eigenschaften und Methoden für alle Personen enthält. Da beide aber eine eigene Methode Print() benötigen, müssen Sie ein Objekt Programmierer und ein Objekt Verkäufer erstellen, von denen jedes alle Charakteristika vom Objekt Person erbt. Anschließend würden Sie die Methode Print() des Programmierers schreiben, die kurz und präzise druckt und die Verkäufer.Print(), die etwas langatmiger ausfällt. Im Pseudocode könnte das in Etwa so aussehen:
Während die objektbasierte Programmierung die Wiederverwendbarkeit des Code durch die Vereinfachung der Methodik des Aufrufs des Code erhöht, unterstützt Sie die objektorientierte Programmierung mit der Vererbung. Von den vier Sprachen im Visual Studio – Visual FoxPro, Visual C++, Visual J++ und Visual Basic – sind außer Visual Basic alle objektorientiert. Visual Basic ist objektbasiert, da es keine Vererbung unterstützt. Es gibt zwei unterschiedliche Arten der Vererbung: die einfache Vererbung und die mehrfache Vererbung. Die einfache Vererbung bedeutet, dass ein untergeordnetes Objekt die Eigenschaften und Methoden nur von einem Objekt erben kann, während bei der mehrfachen Vererbung ein untergeordnetes Objekt von mehreren übergeordneten Objekten erben kann. Bei mehrfacher Vererbung erbt ein Objekt im Normalfall alle Eigenschaften und alle Methoden eines Objekts. Würden wir ein Objekt erstellen, dass sowohl vom Objekt Programmer als auch vom Objekt Salesman erbt, hätte dieses Objekt eine kurze und eine langatmige Methode Print(). Zwar bietet die mehrfache Vererbung einen hohen Grad an Vielseitigkeit, sie aber auch schwieriger zu verwalten als die einfache Vererbung. Um die Verwaltung der mehrfachen Vererbung zu vereinfachen, unterstützen manche Sprachen, z. B. Java, die einfache Vererbung von Klassen und die mehrfache Vererbung von Schnittstellen. Visual FoxPro unterstützt die einfache Vererbung. Unterstützung von COMObjektorientierte Programmierung bietet den höchsten Grad der Wiederverwendung von Code. Trotzdem ist OOP eine sprachenzentrierte Lösung. Um die Vorteile der OOP auszuschöpfen, müssen Ihre Objekte nicht alle in der gleichen Programmiersprache entwickelt worden sein, aber in den meisten Fällen benötigen Sie den Sourcecode. Wurde das Objekt innerhalb Ihrer Firma entwickelt ist das kein Problem, aber wäre es nicht angenehm, auch von den Objekten zu profitieren, die andere geschrieben haben? Und wenn wir schon mal dabei sind: wäre es nicht schön, wenn Sie Ihre Objekte auf unterschiedlichen Maschinen innerhalb Ihrer Firma verteilen könnten, um die Ressourcen auszunutzen, die Verteilung zu vereinfachen oder die Sicherheit zu erhöhen? In diesen Fällen hilft Ihnen die Objektorientierung nicht weiter. Was Sie in hier benötigen ist ein Objektbroker, also eine Technologie wie Microsofts Component Object Model, kurz COM. COM ist der Schlüssel für die Erstellung von Anwendungen, die untereinander kommunizieren können, die von Komponenten oder Anwendungen profitieren, die von anderen Entwicklern erstellt wurden oder die auf verschiedenen Rechnern innerhalb eines Netzwerks verteilt werden können. Die Technologie COM unterstützt uns auf vier unterschiedliche Arten:
Visual FoxPro unterstützt alle vier Technologien. Visual FoxPro kann als Client für ActiveX-Dokumente fungieren. Mit dieser Technologie ermöglicht es eine VFP-Anwendung dem Anwender, auf VFP-fremde Dokumente zuzugreifen und sie zu bearbeiten (früher wurden ActiveX-Dokumente als OLE- oder Object Linking and Embedding-Dokumente genannt). Dabei kann es sich um ein Word-Dokument oder eine Excel-Tabelle handeln, oder auch um die Benutzung eines Menüs oder einer Toolbar von Word oder Excel. Dies geschieht, ohne dass der Anwender die VFP-Anwendung verlassen oder Word bzw. Excel starten muss. Visual FoxPro kann auch als ein Server für ActiveX-Dokumente dienen, die anderen Anwendungen wie Word oder Excel Dokumente zur Verfügung stellt. Visual FoxPro-Anwendungen können ActiveX-Kontrollelemente nutzen, um dem Anwender Funktionalitäten zur Verfügung zu stellen, die mit VFPs nativen Kontrollelementen nicht oder nur schwierig zu erstellen wären. Ein großartiges Beispiel dafür ist die Kontrolle über den Internet Explorer. Mit viel Mühe könnten Sie vielleicht herausfinden, wie Sie ein Formular in VFP erstellen können, mit dem der Anwender sich im Internet bewegen kann. Dies können Sie sich aber sparen, indem Sie das frei erhältliche IE Browser ActiveX-Kontrollelement auf ein VFP-Formular ziehen. Damit erhält Ihre Anwendung ohne großen Aufwand die Fähigkeit, sich im Internet zu bewegen und HTML anzuzeigen. Die meisten ActiveX-Kontrollelemente verfügen aber über die eine oder andere Benutzeroberfläche. Dies gilt aber nicht für alle. Es gab mehrere Jahre lang ein ActiveX-Kontrollelement von Crystal Reports, das es dem Anwender ermöglichte, Berichte innerhalb seiner Anwendung zu drucken, anzusehen und zu ändern. Dieses Kontrollelement hatte keine Benutzeroberfläche. Zur Zeit tauscht Seagate es gegen eine Komponente zur Automatisierung aus. Obwohl Visual FoxPro ActiveX-Kontrollelemente einsetzen kann, ist es doch nicht möglich sie damit zu erstellen. Dies müssen Sie mit anderen Werkzeugen tun, beispielsweise mit Visual C++ oder Visual Basic. Die Automatisierung ermöglicht es einer Clientanwendung, mit einer Serverkomponente oder -anwendung via COM zu kommunizieren oder diese zu steuern. Als die Unterstützung der Automatisierung mit der Version 3.0 von VFP eingeführt wurde, konnte VFP als Client auf eine Serveranwendung wie Word oder Excel zugreifen. Stellen Sie sich als Beispiel vor, eine 1995 geschriebene Anwendung wird von der Gesundheitsbehörde genutzt, um verschiedene Aspekte der Gesundheitspolitik in der dritten Welt zu verfolgen. Da das Budget limitiert ist, war es nicht möglich ein Modul zu entwickeln, das die bestmögliche Investmentstrategie errechnet, das die nationalen Lasten durch Krankheiten reduziert. Statt dessen nutzt die Anwendung die Automatisierung, um eine Komponente von Excel zu kontrollieren und so die beste Strategie herauszufinden. Dafür wurde weniger als ein Tag benötigt. Seit der Version 5.0 lassen sich mit Visual FoxPro auch Serverkomponenten erstellen. Zusätzlich zur Fähigkeit, andere Anwendungen zu kontrollieren, können nun andere Anwendungen die von Ihnen erstellte Anwendung oder Komponente steuern. Nehmen Sie als Beispiel an, Sie benötigen eine Komponente, die es ermöglicht Daten in einem nationalen ASCII-Format zu im- und exportieren. Diese Komponente wird an zwei Stellen innerhalb Ihrer Anwendung benötigt. Auch andere Applikationen benötigen den Zugriff auf die Komponente. Sie könnten jetzt eine COM-Komponente erstellen um diese Funktionalität zu kapseln. Anschließend kann jede Anwendung, nicht nur die in VFP geschriebenen, auf die Methoden für den Im- und Export zugreifen. Das letzte Stück im COM- Puzzle ist die Möglichkeit, die Komponenten der Automatisierung auf mehreren Rechnern zu verteilen. Der erste Schritt in diese Richtung wurde Remote Automation genannt, aber weitgehend durch Distributed COM (DCOM) verdrängt. Warum soll man Komponenten auf unterschiedliche Rechner verteilen? Aus dem gleichen Grund, aus dem Sie im Client/Server-Betrieb auch die Anwendung von der Datenbank trennen. Wir betrachten die verteilten Anwendungen als einen Schritt weitergehend als Client/Server. Aus Gründen der Performance, Skalierbarkeit, Sicherheit und Kosteneffizienz trennen Sie die Clientanwendung von der Datenbank auf dem Server. Aus den gleichen Gründen verteilen Sie auch die Komponenten auf verschiedene Netzwerk-Ressourcen. Unabhängig davon, wo sich die Automation-Server befinden – auf unserem lokalen Rechner oder einem anderen Computer im Netzwerk – die Verwendung in einer Client/Server-Anwendung macht aus einem zweischichtigen Design ein dreischichtiges. Sie können eine dreischichtige Anwendung erstellen, die alleine remote ausgeführt wird oder Sie könnten Komponenten erstellen, die in einer anderen Umgebung laufen, beispielsweise im Microsoft Internet Information Server (IIS) oder im Microsoft Transaction Server. Sowohl IIS als auch MTS sind multi-threading-fähige Hosts, die eine erhöhte Skalierbarkeit bieten. Visual FoxPro ermöglicht Ihnen die Erstellung von Multi-Threaded-COM-Komponenten, die sich auf jedem Host gut skalieren lassen wie auch die Erstellung anderer Komponenten, die das Apartment-Threading-Modell unterstützen. Eingebaute Client/Server-UnterstützungVisual FoxPro hat die Unterstützung für Client/Server-Datenbanken bereits eingebaut. Allerdings unterstützt VFP nicht nur Client/Server-Datenbanken, sondern jede ODBC-Datenbank. Wie im Kapitel 7, „Downsizing“ beschrieben, kann VFP auf seine eigenen Daten nicht nur nativ, sondern auch über ODBC zugreifen. Viele andere populäre Client/Server - Entwicklungssprachen wie Visual Basic oder C++ besitzen keine native Fähigkeit für den Zugriff auf Daten und benötigen dafür entweder eine API des Datenbankservers oder setzen Bibliotheken oder Komponenten für den Datenzugriff ein. Datenbankanwendungen, die in Visual Basic entwickelt wurden, bieten den Zugriff auf die Daten mit DAO (Data Access Objects), RDO (Remote Data Objects) oder ADO (ActiveX Data Objects), je nachdem in welchem Jahr die Anwendung geschrieben wurde und welche Datenbanken eingesetzt werden. VFP nutzt ODBC (Open Database Connectivity), um auf Client/Server-Daten zuzugreifen. ODBC ist zur Zeit die am weitesten verbreitete Technologie für die Verbindung zu einer Datenbank. Visual FoxPro gibt Ihnen die Möglichkeit, auf seine ODBC-Features über remote Ansichten, das sind vordefinierte änderbare Abfragen, oder über SQL Pass Through zuzugreifen, mit dem Sie jeden unterstützten Befehl an den Datenbankserver senden können. Remote Ansichten behandeln wir im Kapitel 4, „Romote Views“ und SQL Pass Through in Kapitel 6, „Extending Remote Views with SQL Pass Through“. Die Recordsets, die entweder mit den remoten Ansichten oder mit SQL Pass Through erstellt wurden, können mit den traditionellen xBase-Befehlen für die Navigation in den Daten und der Datenmanipulation behandelt werden und können genau die native VFP-Daten direkt an Kontrollelemente in VFP-Formularen gebunden werden. Die native DatenengineVisual FoxPro verfügt über eine lokale Datenengine, die keinerlei zusätzliche Komponenten erfordert. Wofür benötigen Sie eine lokale Engine, wenn Sie Client/Server-Anwendungen entwickeln? Dafür gibt es drei gute Gründe: lokale Lookup-Daten, Metadaten und Datenverarbeitung ohne Verbindung zur Datenbank. Einige Daten ändern sich nie oder nur selten. Die Staaten der USA z. B. wurden seit 1959 nicht mehr geändert. Wenn Daten statisch sind und keine Sicherheitsfunktionalitäten erfordern, gibt es keinen Grund sie in der Serverdatenbank zu speichern und sie jedes Mal hin und her zu senden, wenn ein Anwender darauf zugreift. Warum sollte man also diese häufig genutzten Daten nicht lokal auf der Workstation speichern? Visual FoxPros lokale Datenengine ermöglicht die Speicherung dieser Daten auf der lokalen Festplatte, wo schnell auf sie zugegriffen werden kann ohne das Netzwerk und den Server zu belasten. Nur für den Fall dass die Daten geändert werden, können Sie auf dem Server eine Masterkopie halten und beim Starten der Anwendung einfach prüfen, ob die Daten sich geändert haben. Ist dies der Fall werden sie vom Server downgeloadet und die lokale Kopie wird aktualisiert. Anderenfalls wird die lokale Kopie genutzt. Diesen Punkt behandeln wir näher in Kapitel 9, „Some Design Issues for C/S Systems“. Metadaten sind Daten, die andere Daten beschreiben. In der Regel werden die Metadaten von der Anwendung genutzt, nicht vom Anwender. Die Benutzung von Metadaten mit datengesteuerten (statt codegesteuerten) Technologien ermöglicht Ihnen die Erstellung flexiblerer Anwendungen in kürzerer Zeit. Wenn die gleiche oder eine entsprechende Aktion an verschiedenen Stellen ausgeführt werden kann, können Sie die Aktion entweder an allen Stellen hart kodieren oder Sie schreiben eine generische Routine und erstellen eine Tabelle mit einem Datensatz für jede Stelle. Das Hinzufügen und Löschen von Stellen ist genau so einfach wie das Hinzufügen und Löschen von Datensätzen in einer Tabelle und eine Neuordnung der Stellen erfordert lediglich eine Änderung der logischen oder physikalischen Reihenfolge der Datensätze. In einigen Fällen sollten die Metadaten für die Anwender zugänglich sein, in anderen Fällen ist es günstiger, sie den Anwendern nicht zur Verfügung zu stellen. Die lokale Datenengine von VFP ermöglicht es, die Metadaten in Abfragen mit den Client/Server- oder lokalen Daten zu verknüpfen, selbst wenn die Metadaten in die .EXE kompiliert wurden. Sehen Sie sich das Beispiel einer Anwendung an, die Metadaten verwendet, um die Regeln zu prüfen, mit denen die Vollständigkeit der Dateneingabe zu testen. Anwender können ihre eigenen Regeln erstellen. Da die Regeln der Anwender nicht mit den Regeln der Anwendung kollidieren dürfen, können die Anwender nur Regeln für Felder aufstellen, für die keine Regeln der Anwendung existieren. Die SQL Server-Datenbank wird auf eine Feldliste abgefragt und schließt Felder mit Regeln in der Metadatentabelle aus. Ein letzter Vorteil von VFPs lokaler Datenengine für die Client/Server-Entwicklung liegt in der Bearbeitung von Daten ohne Anbindung an die Serverdatenbank. Dies ist sinnvoll für Daten auf Laptops, die mitgenommen werden und daher nicht immer mit dem Server verbunden sind. Eine Kopie aller oder einiger Serverdaten wird lokal gespeichert. Das System kann mit diesen Daten arbeiten, auch wenn der Laptop nicht mit dem Server verbunden ist. Mit Visual FoxPro können Sie diese Daten entweder über die Offline-Ansichten oder durch die Kopie der Daten in Tabellen speichern. Werden lokale Daten nicht unterstützt, muss eine andere Datenengine, beispielsweise MSDE, installiert und genutzt werden. Unterstützung anderer Technologien für den DatenzugriffWährend dieses Buch sich auf die Entwicklung von Client/Server-Anwendungen mit Visual FoxPros eingebauter Technologie konzentriert, unterstützt VFP auch die Verwendung anderer Komponenten für den Datenzugriff, z. B. ADO. Sie wundern sich vielleicht, weshalb das so ist, nachdem wir die Vorteile von VFPs eingebauter Datenbankunterstützung dargelegt haben reden wir über etwas anderes? In einer traditionellen zweischichtigen Client/Server-Anwendung gibt es keinen Grund, sich um ADO Sorgen zu machen. Aber in einer dreischichtigen Anwendung hat ADO ein Feature, das Sie sich ansehen sollten: Daten können von einer Komponente an eine andere wie ein Objekt weitergegeben werden. Wenn eine Komponente des Frontend durch den Anwender geänderte Daten an eine Komponente für die Datenprüfung übergeben soll, die im Microsoft Transaction Server auf einer anderen Maschine läuft, müssen Sie die Daten auf irgendeine Art dort hin senden. Es ist sehr einfach, ein ADO Recordset-Objekt zu senden. Das Frontend kann entweder VFPs eigene Datenunterstützung nutzen und anschließend in ADO umwandeln, oder VFP nutzt in erster Linie ADO. Entscheiden Sie, welche Lösung in der speziellen Situation am besten arbeitet. ADO wird detailliert in Kapitel 12, „ActiveX Data Objects“, behandelt. Rapid Application Development (RAD)Rapid Application Development, kurz RAD, bedeutet für jeden etwas anderes. Visual FoxPro ist aus zwei Gründen ein großartiges RAD-Werkzeug: Sie können schnell einen Prototypen erstellen und diese direkt in Teilen einer Anwendung nutzen; außerdem ist VFP die schnellste uns bekannte Möglichkeit, Anwendungen zu erstellen. Prototypen von Komponenten der Anwendung sind im Entwicklungsprozess sehr praktisch. Sowohl der Entwickler als auch der Anwender haben ihre Vorteile, wenn sie sehen wie das Formular aussehen wird und wie der Arbeitsprozess vor sich geht. Arbeitsfähige Prototypen helfen bei der Verbesserung des Designs, besonders wenn der Anwender damit arbeiten kann. Das Schlüsselwort heißt hier „arbeiten“. Der Blick auf den Bildschirm bringt nicht so viel wie die Arbeit mit Formularen, das Ausfüllen von Feldern und das Klicken auf Schaltflächen. Viele Firmen, die mit C++ arbeiten, benutzen Visual Basic oder Bongo für die Erstellung von Prototypen. Anschließend vernichten sie ihre Arbeit und beginnen in C++ neu. Das ist immer noch schneller als einen Prototypen in C++ zu erstellen, aber wäre es nicht schön, wenn Sie einfach die Prototypen in ein Projekt einbinden und ihnen dann Code hinzufügen? Mit Visual FoxPro ist dies möglich. Mit VFP können Sie einen Prototypen so gut wie in Visual Basic oder in Bongo erstellen, aber anders als mit VB oder Bongo sind die fertigen Prototypen in Visual FoxPro weiter zu verwenden. Wir können die Geschwindigkeit der Entwicklung mit Visual FoxPro nicht messen, aber Gary erzählt eine Erfahrung, die anzeigt, wie schnell VFP sein kann: „In meiner Firma gibt es zwei Entwicklungsteams. Das eine arbeitet mit VFP, das andere mit Java. Als ich mit einem wichtigen Projekt begann, lag ich ein Jahr hinter dem aus drei Entwicklern bestehenden Javateam zurück. Ich war der einzige, der eine ähnliche Anwendung in VFP entwickelte. Das Javateam hatte bereits mehr als 400 gespeicherte Prozeduren für den SQL Server geschrieben. Da meine Anwendung sowohl mit einem VFP-Backend als auch mit dem SQL Server arbeiten sollte, konnte ich keine der gespeicherten Prozeduren nutzen und musste die gesamte Funktionalität selber reproduzieren. In einem sehr schwierigen Bereich habe ich versucht, die Objektstrategie von Java zu duplizieren, da ich mir davon aufgrund einiger Java-Erfahrung eine Zeitersparnis versprach. Nachdem ich daran mehr als einen Monat gearbeitet hatte beendete ich dieses Experiment und begann, von Anfang meine eigenes Modell zu entwickeln. Trotz des verlorenen Monats war mein Projekt neun Monate vor dem des Javateams fertig. Jetzt würde ich gerne sagen, dass ich wahnsinnig schnell bin. Die Wahrheit ist aber, dass Visual FoxPro mich wie einen Star aussehen lies. Berechnet man die Arbeitsleistung und den Zeitaufwand hat Visual FoxPro es mir ermöglicht, die Anwendung neun mal schneller fertig zu stellen und den sechsfachen Umsatz bei einem Zehntel der Kosten zu generieren.“ ZusammenfassungWir sind überzeugt, dass Visual FoxPro das beste Rapid Application Development-Werkzeug ist, das zur Zeit verfügbar ist. Wenn wir noch bedenken, dass Visual Basic nicht objektorientiert ist (na ja, das stimmt nicht ganz – VB 7 bietet in beschränktem Ausmaß objektorientierte Programmierung), hat jeder Entwickler, der VFP für die Client/Server-Entwicklung einsetzt, automatisch einen Vorteil gegenüber der Hälfte der Entwickler. Wir hoffen, dass dieses Kapitel Ihnen für die Verteidigung Ihrer Wahl des Entwicklungswerkzeugs einige Munition geliefert hat. Im nächsten Kapitel lernen Sie die Grundlagen des Microsoft SQL Server kennen. |