Vorteile der Migration von der MS Access-Anwendung zur .Net-Anwendung

IMHO ein allgemeiner Vergleich ".NET" vs "MS-Access" macht keinen Sinn. Sie können Ihre aktuelle Anwendung natürlich mit den erwarteten Funktionen / Leistung / Sicherheit / etc. Ihrer migrierten Anwendung vergleichen, aber Sie müssen mehr über die Details Ihrer Anwendung wissen und darüber, wie Sie Ihren ".NET" -Port entwerfen .

Wenn Sie nach Gründen suchen, um die Bemühungen der Migration zu rechtfertigen, sollten Sie sich die folgenden Fragen stellen:

• Fehlt jemand in Ihrer aktuellen Anwendung, die mit dem Access-Frontend nicht einfach zu entwickeln ist? Das wäre ein guter Grund, auf .NET umzusteigen.
• Wer macht die Wartung in der Zukunft? Ein C # -Programmierer, der nur wenig Erfahrung mit VBA hat, oder ein erfahrener Access-Programmierer, der kein oder nur ein kleines bisschen Wissen über C # hat? Oder ist es Ihnen völlig frei, irgendeinen Wartungsentwickler zu wählen, den Sie mögen, so macht das keinen Unterschied?
• Sind Sie mit Ihrer Access-Anwendung an eine bestimmte MS-Office-Version gebunden? Oder kann es leicht auf eine neuere Version migriert werden? Sich von einer bestimmten Office-Plattform zu entkoppeln, kann ein guter Grund sein, die Entwicklungsplattform zu ändern.
• Was ist mit Ihrem Backend? Sind Sie damit zufrieden (Sie können Access als Backend behalten, selbst wenn Ihr Frontend auf .NET zugreift), oder benötigen Sie eine echte Client-Server-Datenbank (in den meisten Fällen ist es möglich, Ihre Access-Anwendung als Frontend dafür zu halten mit viel weniger Aufwand als eine vollständige .NET-Migration)? Eine CS-Datenbank wie MS-SQL-Server ermöglicht Ihnen mehr simultane Benutzer und hat ein verbessertes Sicherheitsmodell (natürlich für die Kosten des Verwaltungsaufwands), aber in Wirklichkeit gibt es kein Argument, warum Sie Access nicht als Frontend behalten können.
• Wie viele der "RAD" -Funktionen von Access in Ihrer aktuellen Anwendung verwendet werden (z. B. die Möglichkeit, dass ein Zugriffsformular automatisch in einen tabellenartigen Modus oder die Berichtsfunktionen wechselt). Für einige dieser Funktionen gibt es keine fertige Lösung im .NET-Framework, die Sie anders lösen müssen oder mit Drittanbieter-Tools. Das wäre andererseits ein guter Grund, bei Access zu bleiben.

EDIT: hier ist ein mehr als 10 Jahre alter Artikel von Joel Spolsky

Ссылка

scheint etwas mit diesem Thema zu tun zu haben. Lesen Sie, was er über das Wegwerfen einer bestehenden Anwendung denkt, um von vorne zu beginnen.

MS Access scheint eine gute Übereinstimmung zu sein, wenn Ihre Anwendung hauptsächlich ein Werkzeug zum Anzeigen und Bearbeiten von Datensätzen in einer Datenbank mit einfachen Formularen ist, die eng mit den Tabellenlayouts gekoppelt sind und Sie im ganzen wenig oder keine Berechnungslogik benötigen Prozess.

Ich habe gerade eine MS Access-Anwendung mit etwa 2000 Zeilen VBA-Code, 10 Formularen, 50 Tabellen und 80 Abfragen für Java neu implementiert, weil sie eine Menge von Berechnungen und I / O-Operationen enthielt, die nicht mit Datenbanken zusammenhingen. Die Java-Anwendung erreicht das gleiche Ziel in etwa 18000 Codezeilen. Der Aufwand für die Integration der verschiedenen Datenbanken war beträchtlich. Dies wäre ein wenig besser mit C # oder einer anderen .NET-Technologie, aber nicht signifikant.

Alles hängt davon ab, wofür Ihre Access-Anwendung entwickelt wurde.

Anstatt .NET mit Access zu vergleichen, vermute ich, was Sie wirklich vergleichen müssen, ist das Speichern von Daten in Access zum Speichern von Daten in SQL Server.

Denken Sie daran, dass alle folgenden Kombinationen gültig sind:

1. Daten und Frontend in Access
2. In Access gespeicherte Daten, Frontend in .net
geschrieben
3. Daten in SQL Server, Frontend in Access
gespeichert
4. In SQL Server gespeicherte Daten, Frontend in .net

Im Allgemeinen, wenn Ihre Datenbank und die Anzahl der Benutzer wächst, aber die Komplexität des Frontends nicht, würde ich Option 3 vorschlagen. Wenn sowohl die Daten als auch die Komplexität wachsen, könnte es das Ganze wert sein hog und upgraden zu einer Windows / Web .net App, die SQL Server trifft und eine komplette Neuschreibung durchführt. Dies erfordert mehr fachliche Fähigkeiten und möglicherweise längere Entwicklungszeiten, aber unermesslich mehr Flexibilität und mehr Optionen für die Optimierung der Leistung.