Warum noch ein Access-Buch?
Für wen ist das Buch?
Jetzt bestellen
+ direkter Download des eBooks!
Nur EUR 59,95!
Fehler gefunden?
Bitte melden!
Wünsche an das Buch?
Her damit!
Was denken die Leser über dieses Buch?
Lesen Sie aktuelle Rezensionen!
Kapitel des noch nicht veröffentlichten Buchs zum Downloaden, Probelesen und Kommentieren
Beispieldatenbanken
Zusätzliches Material

Das Buch im HTML-Format

Für unbestimmte Zeit bieten Addison-Wesley und André Minhorst den kompletten Inhalt des Buchs als Download an. Schauen Sie rein und informieren Sie sich über den Inhalt! Und wenn Ihnen das Buch nützlich erscheint und Sie glauben, dass Sie etwas gelernt haben oder durch das Gelesene sogar etwas Zeit und somit Geld bei Ihrer Arbeit einsparen konnten, können Sie sich ja beim Autor und beim Verlag revanchieren - beispielsweise durch den Kauf dieses Buchs.

Am schönsten wäre es natürlich, wenn Sie das Buch direkt hier bestellen - Sie erhalten das Buch dann direkt vom Verlag, und der Autor und Verlag haben dann noch mehr davon, als wenn Sie es anderswo kaufen.

Danke für Ihr Interesse!

16.2.8 Schließen-Vorgang des Formulars anpassen

16.3 Mehrschichtige Anwendungen

Im Gegensatz zu objektorientierten Programmiersprachen wie C#, VB.NET oder Java gibt es in Access-Anwendungen keine einzelnen Dateien, die unterschiedliche Klassen definieren. Ganz im Gegenteil: Sämtliche Objekte wie Tabellendefinitionen, Abfragen, Formulare, Berichte, Module und selbst die Daten sind in der .accdb-Datei verborgen. Prinzipiell handelt es sich dabei zwar auch um eigene Dateien, aber diese werden in der Storage von Access für die Augen des Benutzers unsichtbar verwaltet.

Da wird sich der eine oder andere fragen: Mehrschichtige Anwendungen mit diesem aus einem Berg einzelner Objekte und wirr verteiltem VBA-Code bestehenden Klotz? Wie soll das funktionieren? Letztendlich funktioniert das genau wie in anderen objektorientierten Programmiersprachen - nur dass diese natürlich einige Features mehr liefern, wie etwa Vererbung und Polymorphie. Und die Tatsache, dass Access alle Klassen und Objekte intern speichert, spielt letzten Endes nur eine Rolle, wenn Sie den Code örtlich verteilen möchten.

Welche Vorteile bringen mehrschichtige Anwendungen nun konkret? Nun, schauen Sie sich erstmal die Nachteile herkömmlicher Access-Anwendungen an. Benutzeroberfläche und Anwendungslogik sind zu einem sehr hohen Anteil in den Formularen und Berichten konzentriert. Das ist an sich kein Nachteil, wenn nicht verschiedene Funktionen auch noch miteinander vermengt wären: Der Zugriff auf die Daten erfolgt direkt über die Bindung von Formularen und die enthaltenen Steuerelemente auf die Abfragen beziehungsweise Tabellen. Manchmal sorgt eine Gültigkeitsregel oder ein anderer Integritätsmechanismus innerhalb der Tabellen für die Konsistenz der Daten, in vielen Fällen ist diese Funktion jedoch in den Formularen selbst enthalten und wird etwa durch die Ereignisse Vor Aktualisierung des Formulars oder Steuerelements ausgelöst. Andere Felder sind nicht direkt an die Datensatzquelle gebunden, sondern beziehen ihre Daten beispielsweise per VBA über Domänenfunktionen. Sprich: Die Anwendungslogik verteilt sich über mehrere verschiedene Objektarten wie Tabellen, Formulare und VBA-Module - vielleicht gibt es sogar noch ein paar Makros.

Die Pflege solcher Anwendungen kann sehr zeitintensiv werden: Wenn Sie - als einfaches Beispiel - 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.

Das alles muss man natürlich insoweit relativieren, als man mit ein wenig Sorgfalt und konsistenter Vorgehensweise durchaus seine eigenen Anwendungen und die Orte, an denen man die Anwendungslogik unterbringt, im Griff hat. Und Access ist natürlich zuerst 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 Sie für kleine Änderungen beinahe genauso lange brauchen, als wenn Sie die halbe Anwendung neu programmieren, sollten Sie über alternative Vorgehensweisen nachdenken.

Diese liegen beispielsweise in der Verwendung eines mehrschichtigen Datenmodells. Solche Modelle gibt es in mehreren Varianten mit unterschiedlicher Interpretation. 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 Buches werden Datenzugriffsschicht und Daten als zwei Schichten betrachtet.

Nachteile hat die Verwendung einer mehrschichtigen Architektur natürlich auch: Das Schichtenmodell bringt einen immensen zusätzlichen Programmieraufwand mit sich, der sich eindeutig in geringerer Performance niederschlägt - vor allem, wenn die Daten einer oder mehrerer Tabellen komplett in Form von Objekten vorliegen. Das nachfolgende Beispiel kann auch nur einen Eindruck vom Aufbau einer mehrschichtigen Anwendung vermitteln - für den Einsatz in der Praxis müsste man in einige Stellen noch weit mehr Arbeit investieren. So wäre zum Beispiel ein Mechanismus zu schaffen, der sicherstellt, dass die Objekte regelmäßig mit den aktuellen Daten aus der Datenbank gefüttert werden, da auch andere Benutzer auf die enthaltenen Daten zugreifen können.

Nächster Abschnitt:

16.3.1 Beispiel

Unterabschnitte des aktuellen Abschnitts:

    16.3.1 Beispiel

    16.3.2 Die GUI-Schicht

    16.3.3 Die Business-Schicht

    16.3.4 Die Datenzugriffsschicht

    16.3.5 Die Datenschicht

    16.3.6 Zusammenhänge der Objekte und Schichten

    16.3.7 Initialisieren des Formulars

    16.3.8 Initialisieren des Controller-Objekts

    16.3.9 Aufruf der Methode GetPersons der Business-Schicht

    16.3.10 Zugriff des Datenzugriffsobjekts auf die Datenschicht

    16.3.11 Die Klasse clsPerson

    16.3.12 Auswählen und Anzeigen eines Datensatzes

    16.3.13 Einlesen von Personen, die nicht in der Collection enthalten sind

    16.3.14 Neuer Datensatz

    16.3.15 Speichern eines Datensatzes

    16.3.16 Datensatz neu anlegen oder aktualisieren?

    16.3.17 Neuen Datensatz anlegen

    16.3.18 Aktualisieren eines Datensatzes

    16.3.19 Löschen eines Datensatzes

    16.3.20 Businesslogik und mehr

    16.3.21 Objektklassen und Datenzugriffsobjekte automatisch erstellen

© 2006-2008 André Minhorst Alle Rechte vorbehalten.