Laden...

WinForms-Client + SQL-Datenbankdirektzugriff -> WinForms + WebApp + SQL-Zugriff über Service

Erstellt von Jörg vor 4 Jahren Letzter Beitrag vor 4 Jahren 4.262 Views
J
Jörg Themenstarter:in
152 Beiträge seit 2009
vor 4 Jahren
WinForms-Client + SQL-Datenbankdirektzugriff -> WinForms + WebApp + SQL-Zugriff über Service

Hallo,

wie der Titel schon beschreibt habe ich folgende Ausgangslage:
Eine Windows-Forms-Anwendung (Client), welche per Linq2SQL direkt auf einen Microsoft SQL-Server zugreift (2016 Express). Es handelt sich um eine Intranet-Lösung, daher ist derzeit kein Zugriff von außen möglich.

Nun habe ich schon mehrere Beiträge hier im Forum gelesen, in denen von einem Datenbankdirektzugriff aus Sicherheitsgründen abgeraten wird.

Dieses Thema möchte ich nun in Angriff nehmen.

Grundsätzlich soll weiterhin der WinForms-Client für die Endanwender zur Verfügung stehen. Allerdings möchte ich den Datenbankdirektzugriff umstellen, so dass der WinForms-Client nur noch mit einem Service kommuniziert und dieser wiederum mit der SQL-Datenbank. Nun habe ich durch die Suche von vielen möglichen Technologien gehört, allerdings scheinen hier viele abgekündigt, z.B. Remoting und WCF. Was ist hier ‚Stand der Technik‘? – gRPC? – Hier im Forum gibt es auch einen Artikel von 2006 ‚Client-/Server-Komponente über TCP-Sockets‘ – ist sowas auch noch sinnvoll?

Des Weiteren möchte ich mir gerne die Möglichkeit offenhalten, später auch mal über eine WebApp über den Service auf die Datenbank zuzugreifen, damit auch mal ein Außen-Zugriff möglich ist. Kann ich dafür denselben Service nehmen, der auch die WinForms-Clients bedient? Oder werfe ich gerade verschiedene Technologien durcheinander? Ist hier ASP.NET der richtige Ansatz?

Ich hoffe ich konnte meine Problemstellung einigermaßen verständnisvoll darstellen und freue ich mich auf konstruktive Ideen, Tipps und Ratschläge.

16.806 Beiträge seit 2008
vor 4 Jahren

Was ist hier ‚Stand der Technik‘? – gRPC? –

Im Prinzip HTTP basierte Austauschformate wie Json oder XML.
Gerne mit aufgesetzten Protokollen wie REST, OData oder GraphQL.

Wenn Du die Vorteile von RPC haben willst (da gibts auch ein paar Nachteile); dann eben gRPC.
gRPC ist prinzipiell konzipiert als Service-to-Service Kommunikation; funktioniert aber auch von Service zu Client.

Hier im Forum gibt es auch einen Artikel von 2006 ‚Client-/Server-Komponente über TCP-Sockets‘ – ist sowas auch noch sinnvoll?

Nein, nicht für sowas; ausser Du hast ein Grund, dass Du sehr viel von Grund auf selbst programmieren willst, wie zB Security.

Kann ich dafür denselben Service nehmen, der auch die WinForms-Clients bedient?

Klar, die Idee eines solchen Services ist grundlegend verschiedene Clients zu bedienen bzw. technologie-neutral zu sein.

Ist hier ASP.NET der richtige Ansatz?

ASP.NET Core ja; kann durch verschiedene Middlewares alles mögliche ausliefern.

PS: in Netzwerk verschoben, weil das is ja das eigentliche Thema.

J
Jörg Themenstarter:in
152 Beiträge seit 2009
vor 4 Jahren

Im Prinzip HTTP basierte Austauschformate wie Json oder XML.
Gerne mit aufgesetzten Protokollen wie REST, OData oder GraphQL.

Vielen Dank, mit den Stichworten hab ich erstmal ein bisschen Beschäftigung.

16.806 Beiträge seit 2008
vor 4 Jahren

Hab zu dem Thema seit 2 Jahren eine Vortragsreihe, die ich auf Konferenzen, Usergroups und vor Kunden halte.
Inhalt ist, dass die Evolution von Web-basierten Services von einfachen HTTP Services, über Json basierte Services mit Client SDK bis hin zu Hypermedia Services zeigt.

Code dazu liegt mit Samples hier: https://github.com/BenjaminAbt/2018-Talks-ModernApiDevelopment
Inhalt ist immer noch aktuell.

Zum Thema gRPC in ASP.NET Core: https://github.com/BenjaminAbt/Talks.AspNetCore-3-Basics