Sie sollten einen Webdienst (SOAP), eine HTTP-Web-API (REST) oder eine andere Middleware erstellen, um Ihre Datenspeicherung zu abstrahieren.
Dies hat folgende Vorteile:
- Ermöglicht es Ihnen, einen Großteil der Geschäftslogik aus Ihrer Desktop-Anwendung in die Middleware zu verschieben
- Ermöglicht es Ihnen, Geschäftslogik aus SQL herauszuhalten, was ein Engpass sein könnte
- Ermöglicht es Ihnen, Ihre Geschäftslogik zu aktualisieren, ohne Ihre Desktop-App neu zu verteilen (einfacher, wenn Sie keine direkte Kontrolle über alle Desktops haben).
- Sie können die Authentifizierung steuern (viele Webserver haben ihre eigenen Module und Authentifizierungsmethoden). Ihre App würde den Zugriff kontrollieren und unter ihrem eigenen Dienstkonto auf den Speicher zugreifen.
- Ermöglicht es Ihnen, Ihren Datenspeicher vollständig zu ändern (sagen wir, Sie speichern in Zukunft einige in SQL, einige in Mongodb, einige im Cloud-Speicher – noch einmal, ohne alle Ihre Desktops aktualisieren zu müssen.
- Ermöglicht es Ihnen, Ihre Front-Ends und möglicherweise sogar Ihren Back-End-Speicher (z. B. DB-Replikate mit Lese-/Schreibzugriff) zu skalieren
Wenn Sie bereits mit C# arbeiten, sollte die neue MVC4-Web-API gut passen. Lesen Sie hier mehr:
Wenn Sie diesen Weg wählen, könnten Sie den Zugriff in Ihrem Dienst steuern und Ihren Dienst entweder über Anmeldeinformationen in einer Verbindungszeichenfolge oder, wenn Sie IIS verwenden, Anmeldeinformationen für den Anwendungspool, der Ihrer Site zugeordnet ist, auf die Datenbank zugreifen lassen.
Wenn Sie Ihre Desktop-App ausliefern (Sie hosten die Datenbank nicht), können Sie die Web-API auch selbst in einer eigenen EXE-Datei hosten, wenn Ihre Kunden IIS nicht installieren/verwalten möchten.
Und schließlich, wenn Ihr MySQL online ist, könnte sich Ihre Middleware in der Cloud befinden (Azure usw.)
