<\/p>\n
Access ist – rein architektonisch betrachtet – auf das Anlegen monolithischer Anwendungen mit Objekten mit starker Abhängigkeit ausgelegt. Formulare und Berichte sind starr mit den zu Grunde liegenden Datenherkünften verbunden und der Code liegt jeweils im passenden Formular- oder Berichtsmodul oder, falls nötig, in einem Standard- oder Klassenmodul. Wie man auch mit Access mehrschichtige Anwendungen baut, zeigt dieser Beitrag.<\/b><\/p>\n
Im Gegensatz zu objektorientierten Programmiersprachen gibt es in Access-Anwendungen keine einzelnen Dateien, die unterschiedliche Klassen repräsentieren, sondern nur eine einzige Datei mit der Endung .mdb, die alle Objekte enthält.<\/p>\n
Wenn Sie hier eine mehrschichtige Anwendung bauen möchten und dies von richtigen objektorientierten Programmiersprachen gewohnt sind, müssen Sie von dem Gedanken Abschied nehmen, jede Klasse fein säuberlich in einer eigenen Datei zu speichern.<\/p>\n
Davon abgesehen funktioniert das Programmieren mehrschichtiger Anwendungen aber genauso wie in anderen objektorientierten Programmiersprachen – nur dass Sie auf Eigenschaften wie Vererbung und Polymorphie verzichten müssen und alle Klassen in der .mdb-Datei enthalten sind.<\/p>\n
Ein Grund, eine mehrschichtige Anwendung zu erstellen, ist die starke Verzahnung von Benutzeroberfläche und Anwendungslogik. Das gilt vor allem für den in Formularen und Berichten enthaltenen Code, der nicht nur die Benutzeroberfläche steuert, sondern auch die Businesslogik und die Funktionen für den Datenzugriff enthält. Letztere sind dabei noch tiefer verborgen, nämlich in den passenden Formular-, Berichts- und Steuerelementeigenschaften, die für die Bindung an die entsprechenden Tabellen und Abfragen sorgen. Teilweise befindet sich die Businesslogik sogar direkt in den Tabellen – etwa in Form der Gültigkeitsregeln und der übrigen Integritätsmechanismen wie der referentiellen Integrität und der darin enthaltenen Lösch- und Aktualisierungsweitergabe.<\/p>\n
Wegen dieser Aufteilung kann die Pflege solcher Anwendungen sehr zeitintensiv werden: Wenn Sie etwa eine Meldung, die auf einen falschen Datentyp bei der Eingabe in ein Formularfeld hinweist, ändern oder entfernen möchten, sind Sie unter Umständen lange unterwegs, da sich der Auslöser in verschiedenen Ereignissen des Formulars oder auch im Tabellenentwurf befinden kann.<\/p>\n
Ganz klar: Wer eine konsistente Vorgehensweise bei der Programmierung von Anwendungen an den Tag legt, der wird auch genau wissen, wo in seiner Anwendung sich welche Funktionen befinden. Aber erstens kann es ja auch sein, dass sich mal jemand anders um die Wartung oder Weiterentwicklung der Anwendung kümmern muss, und zweitens entwickeln Sie sich selbst ja auch weiter und erkennen nach einer gewissen Zeit die funktionale Struktur früherer Anwendungen nicht mehr wieder. Und Access ist natürlich zunächst einmal dafür ausgelegt, auf schnellstem Wege Anwendungen für den Zugriff auf und die Verwaltung von Daten zu entwickeln. Wenn eine Anwendung allerdings ein gewisses Maß an Komplexität überschritten hat und man für kleine Ónderungen beinahe genauso lange braucht, als wenn man die halbe Anwendung neu programmieren würde, sollte man über alternative Vorgehensweisen nachdenken.<\/p>\n
Diese liegen beispielsweise in der Verwendung eines mehrschichtigen Datenmodells. Solche Modelle gibt es in mehreren Varianten mit unterschiedlicher Interpretation.<\/p>\n
Im Folgenden lernen Sie ein Modell kennen, das je nach Sichtweise aus drei oder vier Schichten besteht: Der Benutzeroberfläche (GUI-Schicht), der Business-Schicht, der Datenzugriffsschicht und den Daten. Manch einer betrachtet die Datenzugriffsschicht und die Daten als Einheit, andere sehen zwei Schichten darin. Im Rahmen dieses Beitrags werden Datenzugriffsschicht und Daten als zwei Schichten betrachtet.<\/p>\n
Als Beispiel für den mehrschichtigen Datenzugriff dienen eine Tabelle namens tblPersonal <\/b>(siehe Bild 1) und ein Formular namens frmPersonal <\/b>(siehe Bild 2). Dabei verwenden wir aus Gründen der Übersicht nur einige der in der Tabelle enthaltenen Felder.<\/p>\n
![\"pic001.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/MehrschichtigeAnwendung-web-images\/pic001_opt.jpeg\")
<\/p>\n
Bild 1: Diese Tabelle dient als Datenherkunft des Formulars.<\/span><\/b><\/p>\n Bild 2: Das Formular zum Anzeigen der Daten ist ungebunden.<\/span><\/b><\/p>\n Das Formular ist komplett ungebunden und enthält die folgenden Steuerelemente:<\/p>\n Die GUI-Schicht<\/p>\n Die GUI-Schicht – also die Benutzeroberfläche – bildet für das nachfolgende Beispiel das Formular frmPersonal <\/b>aus Bild 2. Die GUI-Schicht enthält nur Methoden für den Zugriff auf die Business-Schicht, auf keinen Fall kann sie direkt auf eine der darunter liegenden Schichten zugreifen. Das ist bei herkömmlichen Access-Anwendungen der Fall: Hier werden Datenherkunft und Steuerelemente direkt an die Datenschicht gebunden. Andersherum kann keine der anderen Schichten auf die GUI-Schicht zugreifen – das ist eine der Hauptprämissen bei der Entwicklung mehrschichtiger Anwendungen. Sie minimieren damit die Abhängigkeit, indem Sie dafür sorgen, dass diese lediglich einseitig ist.<\/p>\n Beim hier verwendeten Schichtenmodell greift die GUI-Schicht ausschließlich auf die Objekte der Business-Schicht zu: auf die Datenobjekte mit den anzuzeigenden Informationen und auf das Controller-Objekt, das die Funktionen zum Füllen der Datenobjekte, zum Speichern der per GUI-Schicht geänderten Inhalte der Datenobjekte, zum Speichern neuer Datenobjekte und zum Löschen bestehender Datenobjekte bereitstellt.<\/p>\n Die Business-Schicht enthält zwei Typen von Objekten: Der erste Typ repräsentiert die in den Datensätzen der Tabellen enthaltenen Daten (Daten-Objekte), der zweite enthält die Steuermechanismen für den Transfer der Daten zwischen der Datenzugriffsschicht und der GUI-Schicht (Controller-Objekte).<\/p>\n Genau genommen ist das nicht ganz richtig: Die Controller-Objekte steuern zwar die Objekte der Datenzugriffsschicht und andere Objekte der Business-Schicht, aber die Kooperation zwischen der GUI-Schicht und den Controller-Objekten geht immer von der GUI-Schicht aus. Wie bereits erwähnt – die oberen Schichten können zwar auf die unteren zugreifen, aber niemals umgekehrt.<\/p>\n Und da auch nie eine Schicht übersprungen werden darf, muss die GUI-Schicht immer über die Business-Schicht auf die Datenzugriffsschicht zugreifen, die dann die gewünschten Daten nach oben reicht.<\/p>\n Wie viele und welche Objekte sich in der Business-Schicht befinden, hängt von der Art der enthaltenen Daten und der Benutzeroberfläche ab. Sie werden vermutlich für jede Tabelle, die objektartige Daten enthält, ein eigenes Objekt erstellen. Außerdem müssen Sie entscheiden, ob Sie ein Controller-Objekt pro Element der Benutzeroberfläche oder vielleicht sogar ein großes Controller-Objekt verwenden. Übersichtlicher dürfte ein Objekt pro Formular sein.<\/p>\n Die Datenzugriffsschicht enthält Datenzugriffsobjekte. Zu jedem Datenobjekt gibt es ein Datenzugriffsobjekt, das verschiedene Operationen ausführen kann:<\/p>\n Damit entkoppelt die Datenzugriffsschicht die Business-Schicht von den Daten. Der Vorteil liegt darin, dass Sie ohne Probleme die Datenquelle wechseln können – etwa, um von einem Access-Backend auf einen SQL-Server umzusteigen oder vielleicht sogar um eine XML-Datei als Datenquelle zu verwenden.<\/p>\n Sie müssen lediglich die Klassen der Datenzugriffsschicht anpassen – die GUI-Schicht und die Business-Schicht bleiben von einem Wechsel der Datenquelle unberührt.<\/p>\n Im Beispiel erfahren Sie, wie die fünf Operationen eines Datenzugriffsobjekts aussehen. Man benötigt je ein Datenzugriffsobjekt pro Businessobjekt der Business-Schicht.<\/p>\n Das Beispiel verwendet lediglich ein Datenzugriffsobjekt für den Zugriff auf die Datenbank per DAO. Sie können alternativ ein Datenzugriffsobjekt mit den gleichen Methoden, aber anderen Anweisungen für den Zugriff auf die Daten verwenden, um etwa die ADODB-Bibliothek statt der DAO-Bibliothek zu verwenden. Oder Sie erstellen ein drittes Datenzugriffsobjekt, das den Zugriff auf eine XML-Datei über das mit der Bibliothek MSXML gelieferte Document Object Model ermöglicht. Wenn Sie bezüglich des Datenzugriffs derart flexibel sein möchten, empfiehlt sich die Verwendung einer Schnittstelle.<\/p>\n Die Datenschicht enthält die eigentlichen Daten. Im vorliegenden Beispiel ist das eine Tabelle in einer Access-Datenbank, es kann sich aber auch um eine Tabelle in einer SQL-Server-Datenbank oder um eine XML-Datei handeln.<\/p>\n Diese Flexibilität erhalten Sie durch die Aufteilung der Anwendung auf verschiedene Schichten – um etwa auf eine XML-Datei statt auf eine Access-Datenbank zuzugreifen, müssten Sie nur die Objekte der Datenzugriffsschicht anpassen. Die Benutzeroberfläche und die Business-Schicht bleiben unangetastet.<\/p>\n Nach der Theorie zurück zum Beispiel: Das Formular aus Bild 2 soll nun also über die einzelnen Schichten auf die in der Datenbank gespeicherten Daten zugreifen, diese anzeigen, neue Datensätze anlegen oder bestehende Datensätze ändern oder löschen. Beginnen wir also einfach mal am Anfang: den Zustand beim Öffnen des Formulars.<\/p>\n Person-Objekt erstellen<\/p>\n Während der Arbeit mit dem Formular werden die Daten der Mitarbeiter, wie bereits erwähnt, nicht direkt aus der Tabelle ins Formular transportiert, sondern über ein spezielles Objekt, das im Prinzip mit einem Datensatz einer Tabelle vergleichbar ist, mit dem Unterschied, dass es statt Felder Eigenschaften aufweist und dass Sie seine Methoden selbst definieren können beziehungsweise müssen. Da Sie dieses Objekt auf Basis einer Klasse erzeugen und die Beschreibung dieser Klasse die folgenden Erläuterungen unnötig behindern würde, legen Sie diese Klasse schnell vorab an. Die Klasse heißt clsPerson <\/b>und enthält den Code aus Listing 1. Dazu gehören lediglich die Membervariablen, die die Eigenschaften speichern, sowie zu jeder Membervariablen eine Property Get<\/b>– und eine Property Let<\/b>-Methode. Wenn Sie sich noch nicht mit der Programmierung von Klassen auskennen, finden Sie in [1] weitere Informationen.<\/p>\n Listing 1: Code der Klasse clsPerson<\/p>\n Direkt nach dem Öffnen soll das Formular keinen Datensatz anzeigen. Lediglich das Kombinationsfeld cboSchnellsuche <\/b>soll alle enthaltenen Personen zur Auswahl anbieten. Das Füllen dieses Steuerelements ist dann auch die erste Funktion, die programmiert und auf mehrere Schichten aufgeteilt werden soll.<\/p>\n Der Beginn sieht unspektakulär aus: Die beim Öffnen des Formulars ausgelöste Routine initialisiert das im Kopf des Moduls deklarierte Controller-Objekt und ruft die Prozedur cboSchnellsucheAktualisieren <\/b>auf. Das Controller-Objekt befindet sich im Übrigen in einer eigenen Klasse, die Sie weiter unten erstellen. Den Code aus Listing 2 speichern Sie im Klassenmodul des Formulars frmPersonal<\/b>. Außerdem müssen Sie noch die Eigenschaft Beim Öffnen <\/b>auf den Wert [Ereignisprozedur] <\/b>einstellen.<\/p>\n Listing 2: Initialisieren des Formulars<\/p>\n Die Prozedur cboSchnellsucheAktualisieren<\/b> soll das Kombinationsfeld mit den in der Tabelle tblPersonal<\/b> enthaltenen Daten füllen. Unter Access brauchen Sie dafür keine einzige Codezeile, sondern weisen einfach der Eigenschaft Datensatzherkunft <\/b>eine passende Abfrage zu. Bei der Programmierung einer mehrschichtigen Anwendung wird das Ganze hingegen schon mächtig interessant – Sie füllen dazu zunächst in der Datenzugriffsschicht ein Collection<\/b>-Objekt, das dann nach oben gereicht und von der GUI-Schicht in das Kombinationsfeld gefüllt wird.<\/p>\n <\/p>\n Fangen Sie also ganz unten an und erstellen Sie eine Klasse namens clsPersonal_Datenzugriffsobjekt<\/b>. Dieser fügen Sie eine Methode namens Find <\/b>hinzu, die nichts anderes erledigen soll, als eine Collection <\/b>mit allen in der Tabelle tblPersonal <\/b>enthaltenen Mitarbeitern zurückzuliefern. Um späteren Anwendungszwecken vorzubeugen, fügen Sie dieser direkt einen optionalen Parameter namens varSearch <\/b>hinzu, dem Sie eine Zeichenkette mit einer WHERE<\/b>-Klausel übergeben können – dazu jedoch später mehr. Die komplette Routine finden Sie in Listing 3. Sie durchläuft in einer Do While<\/b>-Schleife alle in der Tabelle gespeicherten Datensätze und schreibt diese in jeweils ein eigenes Objekt des Typs clsPerson<\/b>. Jedes dieser Objekte landet dann in der Collection objPersonen<\/b>. Wichtig ist hierbei, dass beim Anfügen der Objekte an die Collection der Primärschlüsselwert des Datensatzes mit dem zweiten Parameter der Add<\/b>-Methode der Collection als Schlüssel des aktuellen Elements angehängt wird. Anderenfalls können Sie die Elemente der Collection später nicht mehr identifizieren. Die Collection dient im Übrigen als Rückgabewert der Funktion Find <\/b>an die aufrufende Instanz.<\/p>\n Listing 3: Die Find-Methode des Datenzugriffsobjekts clsPerson_Datenzugriffsobjekt<\/p>\n Wer ruft nun diese Funktion auf und wohin geht die Collection Nun, dafür ist das Controller-Objekt zuständig. Dieses legen Sie ebenfalls zunächst in Form einer eigenen Klasse namens clsController <\/b>an.<\/p>\n Für den Aufruf der Find<\/b>-Methode ist in diesem Fall die kleine Methode GetPersons<\/b> zuständig. Diese Methode liefert ein Collection<\/b>-Objekt zurück, das in dem Objekt objPersonen <\/b>gespeichert wird. Die Methode sieht wie in Listing 4 aus.<\/p>\n Listing 4: Die Methode GetPersons der Klasse clsController<\/p>\n Nun kennt diese Methode das Objekt objPerson_Datenzugriffsobjekt <\/b>aber noch gar nicht. Das wird ihm indirekt wiederum von der darüberliegenden Schicht, nämlich der GUI-Schicht mitgeteilt. Indirekt deshalb, weil diese das Controller-Objekt instanziert und dadurch das im Controller-Objekt enthaltene Ereignis Class_Initialize <\/b>ausgelöst wird. Damit dies alles geschieht, fügen Sie auch noch die Deklarationen und die Prozedur Class_Initialize <\/b>aus Listing 5 zur Klasse clsController <\/b>hinzu.<\/p>\n Listing 5: Initialisieren der Klasse clsController der Business-Schicht<\/p>\n Nun endlich können Sie auch der GUI-Schicht die für das Füllen des Kombinationsfelds notwendige Funktionalität hinzufügen. Diese manifestiert sich in Form der Routine cboSchnellsucheAktualisieren<\/b> und kann nicht nur beim Öffnen des Formulars, sondern auch durch andere Ereignisse aufgerufen werden. Die Routine aus Listing 6 deklariert zunächst ein Objekt des Typs clsPerson <\/b>und eine Collection. Die oben vorgestellte Methode GetPersons <\/b>des Controller-Objekts liefert (über die Find<\/b>-Methode des Datenzugriffsobjekts) die Collection mit den einzelnen Personen-Objekten. Diese durchläuft die Routine in einer For Each<\/b>-Schleife und trägt den Vor- und den Nachnamen in eine Semikola-separierte Zeichenkette ein. Diese muss die Routine nun nur noch der Datensatzherkunft des Kombinationsfelds zur Schnellauswahl zuweisen – fertig! Natürlich müssen Sie die Eigenschaft Herkunftstyp <\/b>des Kombinationsfelds noch auf Wertliste <\/b>sowie die beiden Eigenschaften Spaltenanzahl <\/b>und Spaltenbreite <\/b>auf 2 <\/b>und 0cm<\/b> einstellen.<\/p>\n Listing 6: Zuweisen einer Datensatzgruppe mit allen Personen an das Kombinationsfeld zur Schnellsuche<\/p>\n Wenn Sie nun das Formular in der Formularansicht öffnen und das Kombinationsfeld aufklappen, sollte sich etwa ein Bild wie in Bild 3 präsentieren. Glückwunsch! Sie haben Ihr erstes Kombinationsfeld mittels objektorientierter, mehrschichtiger Datenbankentwicklung gefüllt. Zugegebenermaßen ist der Aufwand nicht gerade gering, aber die fehlende Datenbindung und die gewünschte Flexibilität erfordern diesen Weg. Nun geht es aber schnell weiter – immerhin soll der ausgewählte Datensatz ja auch noch komplett im Formular angezeigt werden.<\/p>\n Bild 3: Kombinationsfeld mit Daten aus einer Collection von Personen-Objekten<\/span><\/b><\/p>\n Beim Füllen des Formulars kommt wiederum die Klasse clsPerson <\/b>ins Spiel. Sie dient als Transportmittel der Daten aus der immer noch in der Klasse objController <\/b>befindlichen Collection objPersonen<\/b>.<\/p>\n Ja, genau: Nach der Auswahl des anzuzeigenden Datensatzes aus dem Kombinationsfeld greift die Anwendung nicht etwa über die Zwischenschichten auf die Datenschicht zu, sondern bezieht die Informationen aus der im Controller zwischengespeicherten Collection, die alle im Kombinationsfeld auswählbaren Personen in Form von Objekten des Typs clsPerson <\/b>enthält. Die Ereigniseigenschaft Nach Aktualisierung <\/b>löst dabei über die Prozedur aus Listing 7 die Routine in Listing 8 aus.<\/p>\n Listing 7: Diese Prozedur ruft die eigentliche Routine zum Laden eines Mitarbeiters auf.<\/p>\n Listing 8: Diese Routine wird nach der Auswahl eines Eintrags des Kombinationsfelds aufgerufen.<\/p>\n Und das sieht so aus: Nach dem Deklarieren der Objektvariablen objPerson <\/b>wird diese mit Hilfe der Methode LoadPerson <\/b>des Controller-Objekts (siehe weiter unten) gefüllt. Als Parameter wird dabei das gebundene Feld des Kombinationsfeldes übergeben, das die PersonalID <\/b>des anzuzeigenden Mitarbeiters enthält (s. Listing 9).<\/p>\n Listing 9: Weiterdelegieren des Ladens von Personendaten in das entsprechende Objekt<\/p>\n Zum Füllen der Eigenschaften mit den Inhalten der Felder des Datensatzes mit der gesuchten PersonalID <\/b>ist die Methode LoadPerson <\/b>des Controller-Objekts zuständig.<\/p>\n Diese Methode deklariert zunächst ein Objekt des Typs clsPersonen <\/b>und weist diesem das Objekt aus der Collection objPersonen <\/b>mit dem passenden Wert der Eigenschaft PersonID <\/b>zu, der in der Collection als Schlüsselwert eines jeden Elements gespeichert ist.<\/p>\n Sollte ein solches Objekt einmal nicht in der Collection zu finden sein, greift die Funktion über die Methode Read <\/b>des Objekts objPersonDAO <\/b>auf die in der Datenschicht beziehungsweise der Datenbank enthaltenen Daten zu – dazu später mehr.<\/p>\n Anderenfalls dient die in der Auflistung vorgefundene Instanz des gesuchten Personenobjekts der Rückgabewert der Methode (s. Listing 9).<\/p>\n Listing 17: Vorbereitung der Aktualisierung eines Datensatzes im Controller-Objekt<\/p>\n Für den in diesem Beispiel eigentlich nicht vorgesehenen Fall, dass ein Mitarbeiter-Objekt angezeigt werden soll, das nicht in der Collection objPersonen <\/b>enthalten ist, greift die Methode LoadPerson <\/b>des Controller-Objekts mit der Read<\/b>-Methode der Datenzugriffsklasse auf den in der Datenbank gespeicherten Personendatensatz zu.<\/p>\n Diese öffnet zunächst eine Datensatzgruppe aller Datensätze mit der übergebenen PersonalID<\/b>, wobei die Anzahl logischerweise 1 <\/b>ist.<\/p>\n Die dort enthaltenen Informationen werden nun in ein frisch instanziertes Personen<\/b>-Objekt eingetragen, das anschließend als Rückgabewert der Funktion festgelegt wird (s. Listing 10).<\/p>\n Listing 10: Einlesen eines Datensatzes in ein Objekt der Business-Schicht<\/p>\n Von hier aus geht es dann über die Business-Schicht direkt in die GUI-Schicht. Dort wartet die Routine aus Listing 9 bereits und trägt die Eigenschaften der gewünschten Person in die entsprechenden Textfelder des Formulars ein.<\/p>\n Das Anlegen neuer Datensätze verläuft in ungebundenen Formularen erstaunlich ruhig. Damit ist natürlich vor allem die Interaktion mit der Datenbank gemeint, denn bevor man nicht die OK<\/b>-Schaltfläche anklickt oder zu einem anderen beziehungsweise neuen Datensatz wechselt, geschieht gar nichts.<\/p>\n Falls noch ein Datensatz im Formular angezeigt wird, soll dieser allerdings erst einmal gespeichert und das Formular geleert werden.<\/p>\n Dazu verwenden Sie die Schaltfläche mit der Beschriftung Neu<\/b>. Die durch das Klicken ausgelöste Routine (s. Listing 11) ruft eine weitere Funktion namens FormularLeeren <\/b>auf, die alle Textfelder des Formulars leert (s. Listing 12).<\/p>\n Listing 11: Diese Routine ruft eine weitere Routine zum Leeren des Formulars auf.<\/p>\n Listing 12: Leeren der Textfelder des Formulars<\/p>\n Nach der Eingabe der Daten ist es sinnvoll, diese zu speichern. Das soll entweder beim Anzeigen eines anderen Datensatzes, beim Anlegen eines weiteren Datensatzes oder beim Schließen des Formulars geschehen. Letzteres erfolgt mit der Schaltfläche cmdOK<\/b>. Diese löst die Prozedur aus Listing 13 aus, die – Sie ahnen es bereits – eine weitere Methode des Controllers aufruft, die wiederum eine Methode der Klasse clsPerson_Datenzugriffsobjekt <\/b>einsetzt.<\/p>\n Listing 13: Auslösen des Speicher-Vorgangs im Formular<\/p>\n Die Routine prüft, ob der Datensatz bereits einen Wert im Feld PersonalID <\/b>hat oder nicht. Falls nicht, handelt es sich um einen neuen Datensatz und die Funktion CreatePerson <\/b>des Controller-Objekts wird aufgerufen.<\/p>\n Anderenfalls ist der Datensatz vorhanden und es wird nur die neue Version gespeichert. Dafür ist die Funktion UpdatePerson <\/b>zuständig.<\/p>\n Datensatz neu anlegen oder aktualisieren<\/p>\n Der beim Betätigen der OK<\/b>-Schaltfläche im Formular befindliche Datensatz kann bereits in der Datenbank vorhanden sein oder auch nicht. Ein eindeutiges Kennzeichen dafür ist das Vorhandensein eines Wertes in der Eigenschaft PersonID<\/b>.<\/p>\n Diese ID wird nur beim Anlegen eines Objekts in der Datenbank erledigt.<\/p>\n Die Methode SavePerson <\/b>(s. Listing 14) prüft dies und reicht die zu speichernden Daten entweder an die Routine CreatePerson <\/b>oder UpdatePerson <\/b>weiter.<\/p>\n Listing 14: Diese Methode entscheidet, ob ein Objekt in der Datenbank gespeichert oder nur aktualisiert werden soll.<\/p>\n Die Funktion CreatePerson <\/b>gibt die Daten des anzulegenden Objekts an die Methode Create <\/b>des Datenzugriffsobjekts weiter.<\/p>\n Dies geschieht in der Form, dass zunächst ein Personen-Objekt mit den Eigenschaften der Person erstellt und dieses dann an das Datenzugriffsobjekt übergeben wird (s. Listing 15).<\/p>\n Listing 15: Die Funktion CreatePerson des Controller-Objekts erwartet die zu speichernden Eigenschaften des Person-Objekts als Parameter.<\/p>\n Die Create<\/b>-Methode kümmert sich nun um das Anlegen des Datensatzes in der Tabelle tblPersonen<\/b>. Dabei wird neben dem Anlegen des Datensatzes auch die Eigenschaft PersonID <\/b>mit dem in der Tabelle angelegten Wert gefüllt.<\/p>\n Wenn das Anlegen erfolgreich war, liefert die Methode den Wert True <\/b>zurück. Die Methode aus Listing 16 kann dann aus dem per Referenz übergebenen Objekt den neuen Wert der Eigenschaft PersonID <\/b>auslesen.<\/p>\n Listing 16: Die Create-Methode des Datenzugriffsobjekts legt einen neuen Datensatz auf Basis des übergebenen Objekts an.<\/p>\n Das Aktualisieren bestehender Datensätze erfolgt analog.<\/p>\n Diesmal ruft die Methode SavePerson<\/b> die Funktion UpdatePerson <\/b>auf, wobei im Vergleich zum Anlegen des Datensatzes der Wert der Eigenschaft PersonID <\/b>mit übergeben wird (s. Listing 17). Die Methode Update<\/b> des Datenzugriffsobjekts öffnet eine Datensatzgruppe, die lediglich einen Datensatz enthält – den mit der übergebenen PersonalID<\/b> (s. Listing 18).<\/p>\n Listing 18: Aktualisieren eines Datensatzes auf Basis des passenden Objekts<\/p>\n Um den aktuell im Formular angezeigten Datensatz zu löschen, klicken Sie auf die Löschen<\/b>-Schaltfläche. Diese ruft wie gehabt die Business-Schicht auf und übergibt den Wert des Feldes PersonalID <\/b>an die dortige Methode DeletePerson<\/b>. Nach erfolgreichem Löschvorgang leert die Routine das Formular, aktualisiert das Kombinationsfeld zur Schnellsuche und leert auch dieses (s. Listing 19).<\/p>\n Listing 19: Starten des Löschvorgangs<\/p>\n Die Methode DeletePerson <\/b>des Controller-Objekts (s. Listing 20) reicht die ID des zu löschenden Datensatzes direkt an die Methode Delete <\/b>der Datenzugriffsklasse weiter.<\/p>\n Listing 20: Die Methode DeletePerson des Controller-Objekts<\/p>\n Diese löscht den Datensatz mit einem DELETE<\/b>-Statement und gibt bei Gelingen den Wert True <\/b>zurück (s. Listing 21).<\/p>\n Listing 21: Entfernen eines Datensatzes aus der Tabelle tblPersonen<\/p>\n Üblicherweise geht man heutzutage davon aus, dass Ónderungen an einem Datensatz beim Wechsel zu einem anderen Datensatz gespeichert werden. Dies soll auch hier der Fall sein: Dazu fügen Sie an zwei Stellen der GUI-Schicht noch eine Anweisung zum Speichern des aktuellen Datensatzes ein.<\/p>\n Die passende Anweisung lautet folgendermaßen:<\/p>\n Einfügen müssen Sie diese in die Routine, die nach dem Auswählen eines neuen Mitarbeiters über das Schnellsuche-Kombinationsfeld ausgelöst wird, und zwar vor dem Füllen der Textfelder mit den neuen Werten, sowie in die Routine, die das Formular zum Anlegen eines neuen Mitarbeiters leert. In der Beispieldatenbank finden Sie die notwendige Zeile bereits in den entsprechenden Routinen.<\/p>\n Fraglich ist nur, wie man einmal vorgenommene Ónderungen wieder verwerfen kann. Dazu braucht man noch eine Abbrechen<\/b>-Schaltfläche. Diese soll einfach den Zustand des bearbeiteten Mitarbeiters vor der Bearbeitung wiederherstellen.<\/p>\n Das ist allerdings nicht ganz so einfach, denn immerhin gibt es bei ungebundenen Textfeldern, die ja hier nun einmal vorliegen, keine Eigenschaft wie OldValue<\/b>, mit der man die ursprünglichen Werte ermitteln könnte, oder gar eine Undo<\/b>-Funktion.<\/p>\n Also lädt man in dieser Situation einfach wieder den letzten gespeicherten Stand in das Formular. Die Abbrechen<\/b>-Schaltfläche statten Sie dazu mit der Routine aus Listing 22 aus.<\/p>\n Listing 22: Die Abbrechen-Schaltfläche macht Ónderungen am aktuellen Mitarbeiter rückgängig.<\/p>\n Dieses Beispiel zeigt, wie Sie zwei Pattern der objektorientierten Welt mit VBA und Access einsetzen – das Model View Controller-Pattern und das DAO-Pattern (wobei DAO auch Data Access Objects bedeutet, aber nichts mit der DAO-Klasse von Access zu tun hat) – diese Stichwörter nur für diejenigen, die sich ein wenig genauer mit der Materie auseinandersetzen möchten.<\/p>\n Was bringt das Ganze nun Immerhin geht hier eine Menge Code für eine Aufgabe drauf, die sonst mit wenigen Zeilen zu lösen wäre. Dafür erhalten Sie aber auch eine Menge mehr Flexibilität und Übersicht.<\/p>\n Sie können die Businessregeln komplett in der Business-Schicht versenken, was sich natürlich erst dann auszahlt, wenn Sie nicht nur mit einem, sondern mit mehreren Objekten, einer umfangreicheren Benutzeroberfläche und einem dementsprechenden Datenmodell arbeiten.<\/p>\n Die Validierung der Daten kann man je nach Anforderung in die GUI-Schicht verfrachten oder in die Business-Schicht integrieren. Wenn Werte direkt nach der Eingabe in ein Textfeld auf ihre Gültigkeit geprüft werden sollen, macht eine entsprechende Validierung in der GUI-Schicht sicher Sinn. Geschäftsregeln, die sich auf einen größeren Zusammenhang beziehen und gegebenenfalls mehrere Projekte betreffen, lassen sich bestens in der Business-Schicht unterbringen.<\/p>\n Der Artikel zeigt, dass mehrschichtige Architekturen eine code-intensive Sache sind. Wenn Sie das Prinzip des hier verwendeten Model-View-Controller-Modells einmal verinnerlicht haben, ist die Programmierung aber reine Fleißarbeit. <\/p>\n Es bleiben jedoch noch einige Funktionen offen: Wie werden verknüpfte Daten angezeigt, wie erfolgt die Validierung und welche Vorteile bietet die objektorientierte Entwicklung noch Dieses Thema wird sicher in einer der folgenden Ausgaben von Access im Unternehmen weiter behandelt.<\/p>\n Quellen<\/p>\n [1] Ausgabe 5\/2004, Objektorientiertes Programmieren mit Klassen, Shortlink 232<\/p>\n Enthaltene Beispieldateien:<\/p>\n MehrschichtigeAnwendung.mdb<\/p>\n![\"pic002.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/MehrschichtigeAnwendung-web-images\/pic002_opt.jpeg\")
<\/p>\n\n
Die Business-Schicht<\/h2>\n
Die Datenzugriffsschicht<\/h2>\n
\n
Die Datenschicht<\/h2>\n
Beispielanwendung<\/h2>\n
Option Compare Database\r\nOption Explicit\r\nDim mPersonalID As Long\r\nDim mVorname As String\r\nDim mNachname As String\r\nDim mPosition As String\r\nDim mAnrede As String\r\nDim mEinstellung As Date\r\nPublic Property Get PersonalID() As Long\r\n PersonalID = mPersonalID\r\nEnd Property\r\nPublic Property Let PersonalID(lngPersonalID As Long)\r\n mPersonalID = lngPersonalID\r\nEnd Property\r\nPublic Property Get Vorname() As String\r\n Vorname = mVorname\r\nEnd Property\r\nPublic Property Let Vorname(strVorname As String)\r\n mVorname = strVorname\r\nEnd Property\r\nPublic Property Get Nachname() As String\r\n Nachname = mNachname\r\nEnd Property\r\nPublic Property Let Nachname(strNachname As String)\r\n mNachname = strNachname\r\nEnd Property\r\nPublic Property Get Position() As String\r\n Position = mPosition\r\nEnd Property\r\nPublic Property Let Position(strPosition As String)\r\n mPosition = strPosition\r\nEnd Property\r\nPublic Property Get Anrede() As String\r\n Anrede = mAnrede\r\nEnd Property\r\nPublic Property Let Anrede(strAnrede As String)\r\n mAnrede = strAnrede\r\nEnd Property\r\nPublic Property Get Einstellung() As Date\r\n Einstellung = mEinstellung\r\nEnd Property\r\nPublic Property Let Einstellung(strEinstellung As Date)\r\n mEinstellung = strEinstellung\r\nEnd Property<\/pre>\n
Initialisieren des Formulars<\/h2>\n
Dim objController As clsController\r\nPrivate Sub Form_Open(Cancel As Integer)\r\n Set objController = New clsController\r\n cboSchnellsucheAktualisieren\r\nEnd Sub<\/pre>\n
Public Function Find(Optional varSearch As Variant) As Collection\r\n ''On Error GoTo Find_Err\r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset\r\n Dim strSQL As String\r\n Dim objPerson As clsPerson\r\n Dim objPersonen As Collection\r\n Set db = CurrentDb\r\n strSQL = "SELECT * FROM tblPersonal"\r\n If Not IsMissing(varSearch) Then\r\n strSQL = strSQL & " WHERE " & varSearch\r\n End If\r\n Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)\r\n Set objPersonen = New Collection\r\n Do While Not rst.EOF\r\n Set objPerson = New clsPerson\r\n With objPerson\r\n .PersonalID = rst!PersonalID\r\n .Vorname = Nz(rst!Vorname, "")\r\n .Nachname = Nz(rst!Nachname, "")\r\n .Position = Nz(rst!Position, "")\r\n .Anrede = Nz(rst!Anrede, "")\r\n .Einstellung = Nz(rst!Einstellung, "")\r\n End With\r\n objPersonen.Add objPerson, CStr(objPerson.PersonalID)\r\n rst.MoveNext\r\n Loop\r\n Set Find = objPersonen\r\nFind_Exit:\r\n On Error Resume Next\r\n Set db = Nothing\r\n Exit Function\r\nFind_Err:\r\n GoTo Find_Exit\r\nEnd Function<\/pre>\n
Public Function GetPersons() As Collection\r\n Set objPersonen = objPerson_Datenzugriffsobjekt.Find\r\n Set GetPersons = objPersonen\r\nEnd Function<\/pre>\n
Dim objPerson_Datenzugriffsobjekt As clsPerson_Datenzugriffsobjekt\r\nDim objPersonen As Collection\r\nPrivate Sub Class_Initialize()\r\n Set objPerson_Datenzugriffsobjekt = New clsPerson_Datenzugriffsobjekt\r\nEnd Sub<\/pre>\n
Private Sub cboSchnellsucheAktualisieren()\r\n Dim objPerson As clsPerson\r\n Dim objPersonen As Collection\r\n Dim str As String\r\n Set objPersonen = objController.GetPersons\r\n If Not objPersonen Is Nothing Then\r\n For Each objPerson In objPersonen\r\n str = str & objPerson.PersonalID & ";" & objPerson.Nachname _\r\n & ", " & objPerson.Vorname & ";"\r\n Next objPerson\r\n Me.cboSchnellsuche.RowSource = str\r\n Else\r\n MsgBox "Personenliste konnte nicht geladen werden."\r\n End If\r\nEnd Sub<\/pre>\n
![\"pic003.tif\"](\"..\/fileadmin\/_temp_\/2007_02\/MehrschichtigeAnwendung-web-images\/pic003_opt.jpeg\")
<\/p>\nAuswählen und anzeigen eines Datensatzes<\/h2>\n
Private Sub cboSchnellsuche_AfterUpdate()\r\n MitarbeiterLaden\r\nEnd Sub<\/pre>\n
Private Sub MitarbeiterLaden()\r\n Dim objPerson As clsPerson\r\n Set objPerson = objController.LoadPerson(Me!cboSchnellsuche)\r\n objController.SavePerson Nz(Me!txtPersonalID, 0), Me!txtVorname, _\r\n Me!txtNachname, Me!txtPosition, Me!txtAnrede, Me!txtEinstellung\r\n With objPerson\r\n Me!txtPersonalID = .PersonalID\r\n Me!txtVorname = .Vorname\r\n Me!txtNachname = .Nachname\r\n Me!txtPosition = .Position\r\n Me!txtAnrede = .Anrede\r\n Me!txtEinstellung = .Einstellung\r\n End With\r\nEnd Sub<\/pre>\n
Public Function LoadPerson(lngPersonalID As Long) As clsPerson\r\n Dim objPerson As clsPerson\r\n Set objPerson = objPersonen(CStr(lngPersonalID))\r\n If objPerson Is Nothing Then\r\n Set LoadPerson = objPerson_Datenzugriffsobjekt.Read(lngPersonalID)\r\n Else\r\n Set LoadPerson = objPerson\r\n End If\r\nEnd Function<\/pre>\n
Private Function UpdatePerson(lngPersonalID As Long, strVorname As String, _\r\n strNachname As String, strPosition As String, strAnrede As String, _\r\n strEinstellung As String)\r\n Dim objPerson As clsPerson\r\n Set objPerson = New clsPerson\r\n With objPerson\r\n .PersonalID = lngPersonalID\r\n .Vorname = strVorname\r\n .Nachname = strNachname\r\n .Position = strPosition\r\n .Anrede = strAnrede\r\n .Einstellung = strEinstellung\r\n End With\r\n objPerson_Datenzugriffsobjekt.Update objPerson\r\nEnd Function<\/pre>\n
Einlesen von Personen, die nicht in der Collection enthalten sind<\/h2>\n
Public Function Read(PersonID As Long) As clsPerson\r\n On Error GoTo Read_Err\r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset\r\n Dim objPerson As clsPerson\r\n Set db = CurrentDb\r\n Set rst = db.OpenRecordset("SELECT * FROM tblPersonen " _\r\n & "WHERE [PersonID] = " & PersonID, dbOpenDynaset)\r\n Set objPerson = New clsPerson\r\n With objPerson\r\n .PersonalID = rst![PersonalID]\r\n .Vorname = rst![Vorname]\r\n .Nachname = rst![Nachname]\r\n .Position = rst![Position]\r\n .Anrede = rst![Anrede]\r\n .Einstellung = rst![Einstellung]\r\n End With\r\n Set Read = objPerson\r\nRead_Exit:\r\n On Error Resume Next\r\n Set objPerson = Nothing\r\n rst.Close\r\n Set rst = Nothing\r\n Set db = Nothing\r\n Exit Function\r\nRead_Err:\r\n GoTo Read_Exit\r\nEnd Function<\/pre>\nNeuen Datensatz anlegen<\/h2>\n
Private Sub cmdNeu_Click()\r\n FormularLeeren\r\nEnd Sub<\/pre>\n
Private Sub FormularLeeren()\r\n With Me\r\n !txtPersonalID = Null\r\n !txtVorname = ""\r\n !txtNachname = ""\r\n !txtPosition = ""\r\n !txtAnrede = ""\r\n !txtEinstellung = ""\r\n End With\r\nEnd Sub<\/pre>\n
Speichern eines Datensatzes<\/h2>\n
Private Sub cmdOK_Click()\r\n Me!txtPersonalID = objController.SavePerson( _\r\n Nz(Me!txtPersonalID, 0), Me!txtVorname, Me!txtNachname, _\r\n Me!txtPosition, Me!txtAnrede, Me!txtEinstellung)\r\n cboSchnellsucheAktualisieren\r\n DoCmd.Close acForm, Me.Name\r\nEnd Sub<\/pre>\n
Public Function SavePerson(lngPersonalID As Long, strVorname As String, _\r\n strNachname As String, strPosition As String, strAnrede As String, _\r\n strEinstellung As String) As Long\r\n If lngPersonalID = 0 Then\r\n lngPersonalID = CreatePerson(strVorname, strNachname, _\r\n strPosition, strAnrede, strEinstellung)\r\n Else\r\n UpdatePerson lngPersonalID, strVorname, strNachname, _\r\n strPosition, _strAnrede, strEinstellung\r\n End If\r\n SavePerson = lngPersonalID\r\nEnd Function<\/pre>\n
Neuen Datensatz anlegen<\/h2>\n
Public Function CreatePerson(strVorname As String, strNachname As _\r\n String, strPosition As String, strAnrede As String, strEinstellung _\r\n As String) As Long\r\n Dim objPerson As clsPerson\r\n Set objPerson = New clsPerson\r\n With objPerson\r\n .Vorname = strVorname\r\n .Nachname = strNachname\r\n .Position = strPosition\r\n .Anrede = strAnrede\r\n .Einstellung = strEinstellung\r\n End With\r\n If objPerson_Datenzugriffsobjekt.Create(objPerson) = True Then\r\n CreatePerson = objPerson.PersonalID\r\n End If\r\n Set objPerson = Nothing\r\nEnd Function<\/pre>\n
Public Function Create(objPerson As clsPerson) As Long\r\n On Error GoTo Create_Err\r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset\r\n Set db = CurrentDb\r\n Set rst = db.OpenRecordset _\r\n ("SELECT * FROM tblPersonal WHERE [PersonalID] = 0", dbOpenDynaset)\r\n With objPerson\r\n rst.AddNew\r\n rst![Vorname] = .Vorname\r\n rst![Nachname] = .Nachname\r\n rst![Position] = .Position\r\n rst![Anrede] = .Anrede\r\n rst![Einstellung] = .Einstellung\r\n .PersonalID = rst![PersonalID]\r\n rst.Update\r\n End With\r\n Create = True\r\nCreate_Exit:\r\n On Error Resume Next\r\n Set rst = Nothing\r\n Set db = Nothing\r\nExit Function\r\n Create_Err:\r\n Create = False\r\n GoTo Create_Exit\r\nEnd Function<\/pre>\nAktualisieren eines Datensatzes<\/h2>\n
Public Function Update(objPerson As clsPerson)\r\n On Error GoTo Update_Err\r\n Dim db As DAO.Database\r\n Dim rst As DAO.Recordset\r\n Set db = CurrentDb\r\n Set rst = db.OpenRecordset("SELECT * FROM tblPersonal WHERE [PersonalID] = " _\r\n & objPerson.PersonalID, dbOpenDynaset)\r\n With objPerson\r\n rst.Edit\r\n rst![Vorname] = .Vorname\r\n rst![Nachname] = .Nachname\r\n rst![Position] = .Position\r\n rst![Anrede] = .Anrede\r\n rst![Einstellung] = .Einstellung\r\n rst.Update\r\n End With\r\n Update = True\r\nUpdate_Exit:\r\n On Error Resume Next\r\n Set rst = Nothing\r\n Set db = Nothing\r\n Exit Function\r\nUpdate_Err:\r\n Update = False\r\n GoTo Update_Exit\r\nEnd Function<\/pre>\nLöschen eines Datensatzes<\/h2>\n
Private Sub cmdLoeschen_Click()\r\n If objController.DeletePerson(Me!txtPersonalID) = True Then\r\n FormularLeeren\r\n cboSchnellsucheAktualisieren\r\n Me!cboSchnellsuche = Null\r\n End If\r\nEnd Sub<\/pre>\n
Public Function DeletePerson(lngPersonalID As Long) As Boolean\r\n DeletePerson = objPerson_Datenzugriffsobjekt.Delete(lngPersonalID)\r\nEnd Function<\/pre>\n
Public Function Delete(PersonalID As Long)\r\n On Error GoTo Delete_Err\r\n Dim db As DAO.Database\r\n Set db = CurrentDb\r\n db.Execute "DELETE FROM tblPersonal WHERE [PersonalID] = " & PersonalID, dbFailOnError\r\n Delete = True\r\nDelete_Exit:\r\n On Error Resume Next\r\n Set db = Nothing\r\n Exit Function\r\nDelete_Err:\r\n Delete = False\r\n GoTo Delete_Exit\r\nEnd Function<\/pre>\n
Bei Datensatzwechsel speichern<\/h2>\n
objController.SavePerson Nz(Me!txtPersonalID, 0), Me!txtVorname, Me!txtNachname, Me!txtPosition, Me!txtAnrede, Me!txtEinstellung<\/pre>\n
Private Sub cmdAbbrechen_Click()\r\n If IsNull(Me!txtPersonalID) Then\r\n FormularLeeren\r\n Else\r\n MitarbeiterLaden\r\n End If\r\nEnd Sub<\/pre>\n
Businesslogik und mehr<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n
Downloads zu diesem Beitrag<\/h3>\n