Von Access zum Entity Framework: Basics

In den vorherigen Ausgaben haben wir bereits verschiedene Techniken erläutert und unter anderem kleine Desktop- und Webanwendungen programmiert. Dabei sind wir ein wenig vom eigentlichen Ziel des Magazins abgewichen – Access-Entwicklern die Möglichkeiten von Visual Studio und den dortigen Technologien für die Migration von Access-Anwendungen in Desktop- oder Webanwendungen aufzuzeigen. Mit diesem Artikel kehren wir dorthin zurück und erklären, wie Sie den Umzug einer Anwendung von Access zu .NET einleiten und welche Techniken wir dazu in Zukunft nutzen wollen.

Es gibt zahllose Möglichkeiten, wie Sie Desktop-Anwendungen ähnlich denen, die man mit Access erstellt, unter .NET zu programmieren. Das beginnt mit der Wahl der Technik für die Gestaltung der Benutzeroberfläche, geht über die Entscheidung, welches Datenbanksystem man einsetzt bis hin zur Technik für den Datenzugriff.

Benutzeroberfläche

Was die Gestaltung der Benutzeroberfläche angeht, haben wir von der ersten Ausgabe an gezeigt, wie Sie die Benutzeroberfläche mit WPF umsetzen. In der Zwischenzeit haben wir auch einige Artikel darauf verwendet, die Erstellung von Web-Anwendungen auf Basis von HTML zu erläutern.

Backend

Bezüglich des verwendeten Backends haben wir verschiedene Phasen durchlaufen: Zu Beginn haben wir gezeigt, wie Sie über ADO.NET auf die Tabellen einer Access-Datenbank zugreifen können. Access-Datenbanken sind aber aus verschiedenen Gründen nicht die erste Wahl für das Backend: Erstens ist die Dateigröße auf zwei Gigabyte beschränkt, zweitens gibt es kein Berechtigungssystem und drittens kann es nur eine stark begrenzte Anzahl gleichzeitiger Zugriffe verarbeiten. Hier sind andere Lösungen gefragt, weshalb wir auf den SQL Server respektive dessen abgespeckter Version namens LocalDb umgestiegen sind. Für solche Zwecke, wo kein SQL Server vorhanden ist, haben wir den Einsatz von SQLite erläutert.

Datenzugriffstechnik

Um den Umstieg zu erleichtern, haben wir zu Beginn noch auf Basis von Access-Datenbanken gearbeitet und auf diese über ADO.NET zugegriffen. Aus den oben genannten Gründen haben wir uns dann auf SQL Server und SQLite konzentriert. Das hat noch einen anderen Grund: Wer die Vorteile der objektorientierten Entwicklung stärker nutzen möchte und gleichzeitig weniger Zeit in die Programmierung des Datenzugriffs stecken möchte, kann einen sogenannten O/R-Mapper nutzen, einen Mapper, der ein Bindeglied zwischen der objektorientierten und der relationalen Welt bildet. In diesem Fall wollen wir den Zugriff auf die Daten über eine Reihe geeigneter Objekte realisieren, indem wir zum Beispiel auf die in Tabellen gespeicherten Entitäten in Form von Objekten zugreifen – und auf die Gesamtheit dieser Entitäten über entsprechende Auflistungsklassen.

Unsere Wahl fiel dabei auf das von Microsoft entwickelte Entity Framework. Hier haben wir zu Beginn erläutert, wie Sie ein Entity Data Model, also im Prinzip die Abbildung des relationalen Datenmodells, auf Basis einer bestehenden Tabelle erstellen. Dazu ist, wenn Sie von Access aus kommen, zuerst die Migration der Datenbank in eine Datenbank eines geeigneten Datenbanksystems erforderlich. Das Entity Framework bietet Treiber für verschiedene Datenbanksysteme an, zum Beispiel SQLite oder den SQL Server, aber nicht für Access – daher können wir hier nicht bei Access als Backendsystem verharren. Der Einsatz des Entity Frameworks bedingt also die komplette Abkehr von Access.

Wann Access nutzen und wann nicht