Konzeptüberlegungen zu Webapp zu vorhandener WinFormsAnwendung

Ich überlege schon seit einiger Zeit im Kreis herum wie ich am besten folgende Problemstellung angehe und würde mich über ein paar Denkanstöße freuen:

Ich habe eine WinForms-Anwendung (inkl. Userverwaltung) die die Daten per EF in Postgres verwaltet und bei einer Reihe von Kunden im Einsatz ist.

Jetzt soll es eine WebApp geben, die in einem anderen Netzbereich läuft, und zur Erfassung von simplen Meldungen (erfolgt bisher per Zettel oder Telefon)dienen soll.

Bisher gehen meine Gedanken Richtung .netCore 2.1 Ich habe auch bereits ausgehend von der Projektvorlage eine App erstellt die im wesentlichen (ohne bisher die Details umzusetzen) die Anforderungen erfüllt.

Jetzt kommt die für mich entscheidende konzeptionelle Frage:
die Webapp benötigt regelmäßig Stammdaten aus der Hauptanwendung und die Meldungen müssen von der Webapp in die Hauptanwendung.

Aktuell überlege ich hierfür zwei Wege:

Entweder die Datenbank der Webapp (evtl. auch Postgres) wird direkt aus der Hauptanwendung aufgerufen und bearbeitet.

oder

Die Webapp muss einen Service zur Verfügung stellen, den die Hauptanwendung anspricht (und die Webapp kommt dann evtl mit SQLite aus).

Beides setzt natürlich ein Routing aus dem Netz der Hauptanwendung ins Netz der Webapp voraus. Ein Zugriff aus der anderen Richtung soll nicht möglich sein.

Idealerweise sollte der Konfigurationsaufwand für die Webapp beim Kunden möglichst gering sein, da das KnowHow der Admins bei den Kunden extrem unterschiedlich (teilweise kaum vorhanden) ist.

Hier ist der zweite Punkt an dem ich unschlüssig bin:

.net Core Applikation die direkt "installiert" wird,

oder das ganze in Docker verpacken.

Sowohl ASP (egal in welcher Variante) aber auch Docker sind für mich Neuland, da ich seit Jahren nahezu nur mit WinForms arbeite.

Insofern würde ich mich über den einen oder anderen konzeptionellen Denkanstoß freuen, um mit etwas Glück zu große Umwege und Sackgassen bei der Einarbeitung und Umsetzung zu umgehen.

Schönen Abend

Michael

Klingt nach sehr schlechtem Design der Architektur!
Deine WinForms Anwendungen sollte nicht direkt mit der DB kommunizieren.
Hier sollte deine WebApp als zentraler Dienst laufen und deine WinForms Anwendungen sollten hier die Daten über die WebApp austauschen.

Schau dir dazu das Thema ASP .NET WebAPI in Verbindung mit JSON als Format an.
Dies dürfte der passende Ansatz sein.

Link:
https://docs.microsoft.com/de-de/aspnet/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api

Deine WebApp wird dadurch zur zentralen Schnittstelle für deine WinForms Anwendungen.
Diese wiederum werden dann "nur noch" zu Clients und sprechen nur noch über die WebApp.
Somit hast du gleich deine DB abgeschottet, diese darf niemals im einem größeren Netz oder gar im Internet einfach offen erreichbar sein.
Zusätzlich zu der Abschottung, die auch einen Teil der DB Absicherung ist, kannst du durch die zentrale WebApp auch per Menge an Verbindungen gegen die DB begrenzen.
Ebenfalls kannst du durch Caching und Optimierungen die DB entlasten, was bei direkten Zgriffen durch jeden Client nicht der Fall ist.

Das bearbeiten/anlegen/löschen von Daten in der WinForms App ist dann auch weiterhin möglich, nur eben über den Webservice der dann die eigentliche Operation ausführt.
Gerade bei Client Anwendungen die auf zentrale Stellen, wie die WebApp zugreifen sollen, ist dies sinnvoller um eine gewisse Kontrolle über die Abläufe zu haben.

Wenn du bei ASP und Docker auch noch im Neuland bist, dann solltest du dich in die Themen erst einmal einarbeiten bevor du größere Pläne und Projekte planst.
Es empfiehlt sich hier auch direkt ein Auge auf .NET Core sowie ASP .NET Core zu werfen, da beides die Zukunft im .NET Bereich ist.

T-Virus

Prinzipiell:

Deine WinForms Anwendungen sollte nicht direkt mit der DB kommunizieren.

In der pauschalen Form stimmt das nicht.
Bei einer Client Server Infrastruktur sollte der Client nicht direkt mit der Datenbank kommunizieren - egal ob WinForms oder nicht.

Prinzipiell hat aber T-Virus Recht: eine Direktkommunikation zur Datenbank bei solch einer Anwendungs- und Strukturanforderung ist Käse.

Der Name ASP.NET WebAPI bringt Dich mittlerweile auf den falschen Weg, denn WebAPI ist ein Microsoft Produkt der ASP.NET Familie.
Der _eigentlich _technologische Name ist eine sogenannte HTTP API, die dann mit ASP.NET Core umgesetzt werden kann - mit der Mvc Middleware. Das Nameing ist aber in der Doku noch nicht durchgezogen (auch weil die Microsoft Leute ja gerne von einer WebAPI sprechen, der Historie wegen).

Der Link von T-Virus zeigt auch leider auf die veraltete Doku.
Der korrekte Link mit ASP.NET Core 2.1 (zu erkennen am ApiController Attribut und der ControllerBase Basisklasse) ist: Erstellen einer Web-API mit ASP.NET Core und Visual Studio

Aber:
90% meiner Arbeit sind APIs und deren Architekturen; aber in diesem Fall Stimme ich mit T-Virus nicht zu: eigentlich ist das nämlich enorm Oversized für Deine Anforderung, wenn man das KISS-Prinzip beachtet.
Für Dich reicht es völlig, wenn Du eine ASP.NET Core MVC (mit Server Side HTML) baust, die die entsprechenden Formulare zur Verfügung stellt.
Damit brauchst Du die WinForms Applikation auch nicht; die Webanwendung ist Deine zentrale Benutzerapplikation; willst Du die Desktop Applikation für die Benutzer beibehalten - dann würdest Du jedoch die HTTP API durchaus benötigen.
Mit einer guten Software Architektur kann man sich unnötigen Overhead in den Operations und der Solution Architektur sparen.

Daher ist es sehr wichtig, dass Du ein gemeinsamen Code hast in Form einer Klassenbibliothek für die Logik.
Diese kannst Du dann sowohl von der ASP.NET Core Anwendung für den Nutzer ansprechen, wie auch für "Tools Applikationen" wie Dein Sync.

Es ist bei Dir nicht wirklich notwendig so jedenfalls, was man hier lesen kann, dass das Sync-Tool über die API spricht.
Eine eigenständige API baut man vor allem dann, wenn man zum Beispiel Multi-Versionierung in den Operations betreiben muss, viele (evtl. auch unbekannte, da Dritte) Clients hat oder die API an Externe vergibt...
Und solltest Du das später doch brauchen, dann kannst Du die Logik einfach ansprechen, da Du ja ein sauberes OOP gebaut hast 😉

@Abt
Ich hatte die WinForms Anwendung erst einmal als Teil der Anforderung betrachtet und diese auch in der Architektur erhalten wollen.
Wenn diese aber keine fixe Anforderung ist, ist es natürlich sinnvoller direkt die WebApp als Anwendung im Browser zu verwenden.
Spart dann auch die API sowie ie WinForms Anwendung ein.
Nachteil wäre natürlich, dass der TE dann die ganze funktionalität von WinForms in die WebApp portieren muss.
Ich vermute aber mal, dass hier das Drei-Schichten-Modell nicht vorhanden ist und somit hier erst einmal der Code der WinForms Anwendung in die Schichten aufgeteilt werden müsste.
Falls der TE diese aber schon umgesetzt hat, dürfte der Aufwand sich recht in Grenzen halten um hier alles in einer WebApp zu kapseln.

Würde sich auch schon deshalb anbieten, da dann auch die Verteilung der aktuellen WinForms Anwendungen nicht mehr nötig wären, da die WebApp dann den aktuellen Funktionsumfang vorgibt.
Dürfte dem TE einiges an Arbeit einsparen, wenn die Kunden damit einverstanden sind.

T-Virus

Nachteil wäre natürlich, dass der TE dann die ganze funktionalität von WinForms in die WebApp portieren muss.

Die logische Funktionalität muss so oder so technologieneutral umgesetzt sein, sonst ist das ohnehin ein Fehler.

Ich vermute aber mal, dass hier das Drei-Schichten-Modell nicht vorhanden

Solche Annahmen stell ich nicht; hab schließlich keine Glaskugel 😃

ist und somit hier erst einmal der Code der WinForms Anwendung in die Schichten aufgeteilt werden müsste.

Und das wäre so oder so ratsam; und wäre auch bei der API der Fall.

@Abt
Ich gehe immer bei fehlenden Informationen vom Worst-Case aus.
Leider zeigt mir meine Erfahrung, dass ich damit meistens richtig liege.
Kann mich hier natürlich irren, da eben die Anzeichen dafür unklar sind 😃
Meistens sind solche Anwendungen die dann direkt auf die DB zugreifen, ohne Schichten umgesetzt.
Teilweise hat man dann auch noch direkt in der UI die ganzen DB Abfragen etc. also genau das was wir vermeiden wollen.

T-Virus

Schonmal Danke für Eure Rückmeldungen.

zum besseren Verständnis: ein Redesign der bestehenden Anwendung (die nicht in letzter Konsequenz aber zumindest grundsätzlich schon in Schichten aufgeteilt ist) und auch eine vollständige Aufhebung der Trennung zwischen den beiden Netzbereichen steht zum jetzigen Zeitpunkt aus verschiedenen Gründen nicht zur Debatte. Die gewünschte Webapp bildet auch nicht die Funktionalität der Hauptanwendung ab, sondern soll nur als "Input" für bestimmte Meldungen dienen (die bisher eben per Bote und Zettel oder eben Telefon in der Verwaltung landen).

Insofern geht es tatsächlich wie von Abt angesprochen eher um eine kleine WebApp, die im einen Netz läuft und mit zwei minimalen Datenklassen auskommt. Und dann eben einem Tool, das die relevanten Daten zwischen den beiden System "synchronisiert". Wobei hier auch synchronisieren viel zu hoch gegriffen ist. Es würde genügen die Stammdaten (zwischen 300 und max 1200 Zeilen mit 4 Spalten reine Strings) jeweils neu zu übertragen (muss nicht einmal täglich sein). Und alle paar Minuten alle Meldungen des aktuellen Tages(3 Strings pro Zeile und ca. maximal 100 Zeilen) abzurufen. Die bestehende Anwendung würde dann nur wieder die Daten in der DB konsumieren und hätte mit dem "Sync" nichts zu tun.

Hinsichtlich der Webapp habe ich bereits in core 2.1 mit Razorpages angefangen und es sieht so aus als würde das die Anforderungen erfüllen, und so wie ich es verstehe ist es in diesem Rahmen im Prinzip egal ob ich hierfür MVC oder Razorpages nutze.

Hinsichtlich des Sync-Tools bin ich mir nicht ganz sicher ob ich dich richtig verstehe:

Es ist bei Dir nicht wirklich notwendig so jedenfalls, was man hier lesen kann, dass das Sync-Tool über die API spricht.

d.h. du würdest hier den direkten DB-Zugriff ohne eigene API in Erwägung ziehen?

ein Redesign der bestehenden Anwendung (die nicht in letzter Konsequenz aber zumindest grundsätzlich schon in Schichten aufgeteilt ist) und auch eine vollständige Aufhebung der Trennung zwischen den beiden Netzbereichen steht zum jetzigen Zeitpunkt aus verschiedenen Gründen nicht zur Debatte.

Dann wirst Du Deine Wünsche jedoch nicht vollständig in dieser Form erfüllen können, da Du viel doppelt machen müssen wirst.

d.h. du würdest hier den direkten DB-Zugriff ohne eigene API in Erwägung ziehen?

Wenn es eine WebApp ist, dann ja. Arbeitest Du jedoch mit Desktop-Clients und willst diese beibehalten, dann solltest Du auf eine API gehen.
Ein Direktzugriff eines Clients auf die Datenbank hat man schon seit 1960 nicht empfohlen 😃

Ich wollte mich noch einmal kurz melden und bedanken.

Unterm Strich habt ihr mich jetzt letztlich darauf gebracht, dass ich zu kompliziert gedacht habe...

Ich nehme jetzt (und bin schon relativ schnell sehr weit gekommen) die Variante, dass die Webapp per Routing auf die original-DB der bestehenden Applikation zugreift. Dies ist im Rahmen der Vorgaben realisierbar, da es nur ein Host mit einem Port ist, der geroutet werden muss.

Die ASP.NET Core Authentication - Tabellen landen einfach zusätzlich in der bestehenden DB in einem eigenen Schema, somit komme ich komplett um eine neue DB herum.

Und die Clients die die neue WebApp nutzen sollen "sehen" nur den WebServer...

Der DBContext für die Webapp war schnell erstellt, da alle wesentlichen Modellklassen bereits in der ursprünglichen Win-Forms App in eine eigene Bibliothek ausgelagert waren. Und viel Businesslogik gibt es nicht, da die Daten relativ simpel sind...

Und zusätzlich habe ich jetzt so die Möglichkeit das Ganze bei Bedarf ohne große Umstände um weitere Funktionen zu erweitern, da ich so auf den gesamten Datenbestand der Hauptanwendung zugreifen kann. Insofern evtl. auch der erste Schritt dann längerfristig doch die Winforms-Anwendung abzulösen...

👍 In diesem Sinne Danke für die Denkanstöße! 👍