it-swarm.dev

Best Practices für die Verlagerung großer MS Access-Anwendungen in Richtung .Net?

Wir haben eine wirklich riesige MS Access-Anwendung, die ursprünglich für unsere persönlichen Bedürfnisse entwickelt wurde und dann in eine kommerzielle Software umgewandelt und erfolgreich verkauft wurde. Die Software ist eine Art "Allround-Software für Ihr Unternehmen" und enthält mehrere Module, darunter Dokumentenmanagementsystem, Enterprise Resource Planning, Bestandsmanagement, Kundenbeziehungsmanagement, Datenanalyse usw. Wir sind mit dem aktuellen Stand sehr zufrieden Funktionalität der Anwendung, aber um die Anforderungen unserer Kunden zu erfüllen, erkennen wir, dass wir auf etwas Neues umsteigen müssen.

Wir haben uns entschlossen, unsere Anwendung schrittweise auf .Net umzustellen, da wir uns an Visual Basic .Net halten können: Obwohl es für die meisten Entwickler hier eine neue Sprache ist, verfügen wir über fundierte Kenntnisse in VBA und über mehrere Dutzend kleine Projekte, die in VB6 implementiert sind.

Wir haben bereits damit begonnen, die Datenschichtfunktionalität unserer Anwendung auf MS SQL Server zu verschieben, sodass jede Datenmanipulation und -suche direkt auf dem Server ausgeführt wird.

Was wir suchen, sind Best Practices für die schrittweise Verschiebung unserer umfangreichen Benutzeroberfläche (ca. 500-600 verschiedene Formulare, einschließlich Unterformulare, ca. 200 Berichte mit mehrsprachiger Unterstützung usw.). Nach der jüngsten Anfrage unseres potenziellen Kunden, die asynchrone Datenverschlüsselung für Dokumente in DMS zu implementieren, würden wir diesen Teil auch gerne vollständig von MS Access entkoppeln und in .Net implementieren.

Die Frage ist, wie die .Net-Anwendung nahtlos in das vorhandene MS Access-System integriert werden kann, damit wir sie mit bestimmten Parametern (Benutzerrechten usw.) aufrufen und den Datenaustausch zwischen dieser Anwendung und der Ausführung der MS Access-Anwendung ermöglichen können.


EDIT :

Wir haben versucht, einige Methoden aus Martin Fowlers Buch " Enterprise Intergration Patterns " anzuwenden, um eine gewisse Integration zwischen der MS Access-Anwendung und einigen kleinen Dienstprogrammen zu erreichen, die wir in .Net für verschiedene Anforderungen implementiert haben. Wir konnten jedoch nur das Muster "Shared Database" verwenden und waren mit unserer Lösung nicht wirklich zufrieden.

Zum Beispiel haben wir ein kleines Dienstprogramm implementiert, das als Windows-Dienst ausgeführt wird und automatisch alle Nachrichten vom Mailserver über eine POP3-Verbindung herunterlädt und in einer Tabelle speichert, während alle Anhänge im Dateisystem gespeichert werden.

Wir haben hauptsächlich ADO.NET verwendet, um direkt auf MS Access-Datenbanken im MDB-Format zuzugreifen und die Tabelle mit einigen verarbeiteten Daten zu füllen (wie die Daten zu E-Mail-Nachrichten aus dem obigen Beispiel: Wir haben Felder für FROM, TO, CC, BCC, Subjekt und Körper).

Es ist absolut kein Problem, mit dem MDB-Datenformat von .Net zu arbeiten Außerdem möchten wir nicht bei MDB bleiben und fast alles auf MS SQL Server 2008 erweitern - dies gibt uns viel mehr Freiheit in Bezug auf Datenverwaltung und Skalierbarkeit.

Das Hauptproblem hierbei ist, dass wir wissen nicht, wie eine Art "Rückruf" implementiert werden soll in Access, damit wir die Ausführung bestimmter VBA-Codes bei der Datenaktualisierung auslösen können.

Wir hatten große Hoffnungen, dass MS Access 2010 Trigger für Datentabellen aktualisieren und einfügen unterstützt, aber es stellte sich heraus, dass wir nur MS Access-Makros für diese Trigger verwenden können und es keine Möglichkeit gibt, benutzerdefinierte Ausführungen auszuführen VBA-Code im Trigger.

Wir haben auch einige Lösungen mit Senden von Tastenanschlägen direkt an das MS Access-Fenster ausprobiert, um eine vom Benutzer aufgerufene Datenanforderung nachzuahmen. Dies funktioniert, aber wir glauben nicht, dass dies eine realisierbare Lösung ist, die in der Produktion verwendet werden kann.

Wir haben uns auch mit DDE für MS Access befasst, aber wir konnten keine gute Beispiellösung finden, die DDE-Befehle implementiert Und sie für speicherinterne Daten und den Befehlsaustausch verwenden.

Das Hauptproblem besteht also darin, dass MS Access und .Net-Anwendung nebeneinander existieren und miteinander interagieren.

EDIT2:

Ich habe vergessen zu erwähnen, was wir haben auch die MSMQ-Bibliothek in VBA implementiert für die Nachrichtenübertragung zwischen .Net und MS Access. Das Problem war wiederum das Fehlen eines Rückrufs hier: Wir mussten die Warteschlange wirklich nach neuen abfragen Nachrichten und da VBA Multithreading nicht wirklich unterstützt, war es keine wirklich gute Lösung.

26

Dies wird ein großes und sehr kompliziertes Projekt sein. Ich war viele Male für die Migration von Access-Datenbanken nach .NET verantwortlich, aber nie in dieser Größenordnung. Ich stimme zu, dass ein schrittweiser Ansatz wahrscheinlich der realistischste sein wird. Der Versuch, alles auf einmal zu übernehmen, ist ein einfacher Weg, um zu scheitern.

Wie bei anderen Antworten besteht der erste und wichtigste Schritt darin, alles auf SQL Server zu verschieben. Dokumentieren Sie dabei die Datenbank, falls dies noch nicht geschehen ist, und identifizieren Sie Bereiche für das Refactoring, falls vorhanden. Zugriffsdatenbanken, die wachsen, um den sich ändernden Anforderungen gerecht zu werden, verfügen häufig über Datenmodelle, die verbessert werden können, wenn Sie das Gesamtbild betrachten.

Identifizieren Sie als Nächstes Module der Anwendung, die "in sich geschlossen" sind. Da es sich um eine Alleskönner-Datenbank handelt, wird es wahrscheinlich Module geben, die fast vollständig voneinander getrennt sind. Identifizieren Sie nach diesen disjunkten Teilen eines der kleineren Module, das am meisten von der Aktualisierung profitiert, und übernehmen Sie es zuerst.

Erstellen Sie bei der Migration zu .NET nicht nur eine einfache 1: 1-Kopie der Anwendung. Sammeln Sie Eingaben von Benutzern, um Schwachstellen mit der aktuellen Anwendung zu identifizieren. Sie möchten, dass Ihre erste Migrationseinheit ein großer Erfolg wird, um das vollständige Buy-In von allen anderen zu erhalten.

Nachdem Sie die erste Einheit fertiggestellt haben, schauen Sie sich an, was in Bezug auf Herausforderungen, Schwierigkeiten usw. passiert ist, und nutzen Sie diese für die Zukunft.

Eine Sache, von der ich dringend abraten würde, wäre die Implementierung teilweise funktionierender Module (Beispiel: "Wir haben das CRM migriert, aber die Funktionen X, Y, Z sind noch nicht im neuen System enthalten"). Dies führt dazu, dass Benutzer schnell frustriert sind, ein unvollständiges System zu haben, wenn das alte für sie "vollkommen in Ordnung" war. Diese Art der Entwicklung funktioniert möglicherweise gut für andere Domänen, jedoch nicht in Unternehmen, in denen Benutzer "nichts Falsches" am alten Access-Monolithen sehen und die Migrationsanforderungen nicht verstehen.

17
bunglestink

Hier ist eine Art Plan, um Ihre MS Access-Anwendung durch Mutation in eine VB.Net-Anwendung umzuwandeln.

Dies ist kein allgemeiner Plan. Der folgende Plan hängt von dem von Ihnen beschriebenen Projekt ab.

Schritt 1: Migrieren Sie alle Daten zu SQL Server

Verwenden Sie nicht ODBC für den Verbindungszugriff auf SQL Server, sondern verwenden Sie stattdessen ein Access Project (ADP). Ein Access Project ist eine Access-Datei mit der Erweiterung .adp. Es verfügt über vollständige Access-Funktionen (Makros, Formulare, Berichte, Module), aber die Verbindung befindet sich direkt in einer SQL Server-Datenbank anstelle einer MDB-Datei. ADP-Dateien sind sehr kompatibel mit MDB-Dateien. Sie scheinen in Access 2010 nicht unterstützt zu werden, obwohl die Funktion tatsächlich ausgeblendet ist wird sehr gut unterstützt. Wie MDE können ADP-Dateien in ADE-Dateien "kompiliert" werden.

Die Migration in SQL Server kostet nur wenige Änderungen an Datenstruktur und Code, aber die Migration ist recht einfach. Und es ist schließlich ein endgültiges Ziel.

Vergessen Sie das Auslösen von Datenbankereignissen in VBA- oder VB.Net-Code. Dies kann technisch mit SQL Server Extended Stored Procedures durchgeführt werden, ist jedoch ein sehr schlechter Trick. Ihr Projekt hat ein zukünftiges Leben, daher ist es besser, seine Datenstruktur durchzusetzen, indem Sie eine solche Destrukturierungsbrücke vermeiden. Spielen Sie im Allgemeinen mit Datenbank-Triggern, es ist intelligent, aber ziemlich schwierig zu warten.

Schritt 2: Authentifizierung vereinheitlichen

Es ist gut, dass Ihre Anwendung nicht auf der Zugriffssicherheit (MDW-Datei) basiert.

Erstellen Sie einen Plan für die Zielauthentifizierung für die VB.Net-Anwendung und definieren Sie dann eine Möglichkeit, die Access-Authentifizierung auf dieses Ziel zu migrieren, um eine einheitliche Authentifizierung zwischen den beiden Anwendungen zu gewährleisten.

Da die Authentifizierung in einer Anwendungsarchitektur transversal ist, ist es einfacher, zwischen der Access-Version und der VB.Net-Version zu wechseln.

Schritt 3: Bereiten Sie eine Token-Funktion vor, um eine Brücke zwischen Access und VB.Net zu schlagen.

Sie sagten, die Access-Benutzeroberfläche muss eine VB.Net-Benutzeroberfläche mit einigen genauen Parametern und auch Authentifizierung öffnen. Und wahrscheinlich müssen Sie dasselbe auch anders machen.

Eine gute Lösung besteht darin, ein kleines Token-Feature basierend auf einer Token-Tabelle zu erstellen: Spalten können eine Token-ID (Ganzzahl), ein Token-Schlüssel (lange Zeichenfolge), ein Token-Datum und eine Parameterliste (lange Zeichenfolge oder Text) sein. Jedes Mal muss Access einen VB.Net-Bildschirm öffnen, dann ein Token mit den Parametern in der Datenbank speichern und dann Ihre VB.Net-Anwendung nur mit der Token-ID und dem Token-Schlüssel öffnen. Das VB.Net wird geöffnet, die Token-ID in der Datenbank durchsucht, der Schlüssel überprüft (dies gilt als Authentifizierung) und die Parameter gelesen. Dann öffnet es sich zu entsprechender Form und tut, was erforderlich ist. Vergessen Sie nicht, Token eine Dauer zu geben und alte Token zu reinigen.

Wenn Sie von VB.Net zu Access zurückrufen müssen (wahrscheinlich auch), ist es meiner Meinung nach möglich, mit OLE VBA-Code in einer geöffneten MDB Access-Datei zu aktivieren.

Schritt 4: Benutzeroberfläche und Module Bildschirm für Bildschirm, Modul für Modul migrieren

Jetzt ist die große Vorbereitung abgeschlossen. Sie können mit der Migration der Benutzeroberfläche von MS Access nach VB.Net beginnen.

Dafür gibt es keine guten automatischen Werkzeuge. VBA und .Net sind zu unterschiedlich. Sie müssen Ihre Arbeit auf eine solche Migration vorbereiten. Beginnen Sie mit einem kleinen Formular wie dem Feld "Info" und fahren Sie von einfachen Formularen zu komplizierten Formularen fort. Natürlich müssen Sie einige Migrationen bündeln und planen, aber Sie werden Ihre Bildschirme, Berichte und Bibliotheken schrittweise von MS Access auf VB.Net migrieren.

7
Skrol29

Ich bin erstaunt, dass Sie das alles mit Access gemacht haben. Es gibt eine sehr wichtige Frage, die Sie .NET Windows Forms oder .NET WPF nicht stellen. WPF hat eine steilere Lernkurve, aber meiner Meinung nach ist es leistungsfähiger mit einer besseren Benutzeroberfläche. Wir haben kürzlich unsere kommerzielle Anwendung von Forms auf WPF umgestellt und erzielen bereits mehr Umsatz. Wir haben auch neue Funktionen hinzugefügt, aber die WPF-Benutzeroberfläche ist einfach sexy. Überprüfen Sie Ihr Tischdesign und räumen Sie es auf - jetzt ist es an der Zeit. Stellen Sie sicher, dass Sie alle Ihre FKs deklarieren. In Access können Sie Dinge ganz einfach hinzufügen, wenn diese Dinge manchmal verrutschen. Wenn dies Ihre erste WPF-Benutzeroberfläche ist, erstellen Sie einige Prototypen. Wir könnten mehr in WPF packen, dass die neue App mehr Funktionen, weniger Bildschirme und weniger viel weniger Code hat. Sie werden vom Hassen von XAML zum Lieben davon übergehen. Stellen Sie sich eine Struktur wie MVVM vor. Sie können sich entscheiden, MVVM nicht zu verwenden (wir haben es nicht getan), aber bei dieser Entscheidung.

1
paparazzo

Da Sie bereits ein gutes Verständnis des Access-Objektmodells haben, würde ich denken, dass Sie Access Interop aus Ihrer .NET-App verwenden möchten. Es sollte Ihnen (mehr oder weniger) ermöglichen, die Steuerung einer Access-App ohne die Undurchsichtigkeit von DDE zu automatisieren.

0
sq33G