Best Practise für Server - Client Applikation (Middle-Tier)

  • C#

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von kaifreeman.

    Best Practise für Server - Client Applikation (Middle-Tier)

    Hallo Leute,
    ich bräuchte mal das Schwarmwissen zum Thema Server Client / Middletier Applikation.

    Ausgangspunkt:
    Ich arbeite aktuell an einer CRM Software diese ist auf WPF C# (vor ein paar Wochen noch vb.net) Basis aufgebaut und folgt MVVM und Multilayer (also View, Viewmodel, DataaccessLayer, Businesslogic usw.) für den Datenzugriff benutze ich EF Core. Das ganze funktioniert eigentlich perfekt hat aber aus meiner Sicht ein großes Problem, die Zugriffsdaten auf den Datenbank Server liegen in jedem Client und jeder User muss als DB User mit CRUD Rechten geführt werden. Ich habe natürlich die Connection verschlüsselt und möglichst versteckt aber auf Dauer ist das keine Lösung.

    Bis dato sind alle Softwarelösungen in diesem Bereich mit denen ich gearbeitet habe so aufgebaut das es einen Client gibt, der mit einer Middletier kommuniziert welche dann wieder den Datenzugriff regelt, nebenbei dann auch noch so Geschichten wie Mail Versand übernimmt usw.

    Ich hoffe die Ausgangsbasis ist klar.

    So nun zu meinem Problem:

    Was ist der Best Practise für eine Middletier Anwendung?
    Ich habe viel recherchiert es gibt / gab mal früher wie WCF (Windows Communication Foundation) diese gibt es aber anscheinend im .net 5.0 Framework nicht mehr. Weiters bin ich auf ZeroMQ gestoßen das Framework unterstützt ebenfalls verteilte Anwendungen. Des weiteren wird von ASP.net Server gesprochen als Middletier..... Irgendwie ist das Thema schwer aufzugreifen...

    Was sind meine Anforderungen:
    - Client soll aktuell auf WPF bleiben, ein ASP.net Client kommt sicher aber irgendwann später dafür fehlt mir die Zeit.
    - Der Middletier soll auf Windows Server 2016 / 2019 lauffähig sein und wenn geht als Dienst ausgeführt werden.
    - Die Datenbank ist ein MsSQL Server
    - Das wichtigste (zumindest soweit ich es überblicken kann) übertragen von typisierten Objekten vom Client zum Middletier und retour (ich hoffe die Aussage ist soweit korrekt).
    (Mein Problem ist das in allen Code Schnipseln die ich gefunden habe immer nur ein String rumgeschubst wird aber niemand im Ansatz erwähnt ob man ein "Objekt" vom Typ T vom Client zum Server kriegt ohne dieses aus irgendeinem Memorystream odg. wieder zusammenbauen zu müssen.).

    Habt ihr einen Tipp für mich?

    Danke.
    mfG.
    Stephan

    kaifreeman schrieb:



    die Zugriffsdaten auf den Datenbank Server liegen in jedem Client und jeder User muss als DB User mit CRUD Rechten geführt werden. Ich habe natürlich die Connection verschlüsselt und möglichst versteckt aber auf Dauer ist das keine Lösung.


    Mal wider der Klassiker. Warum kann der User sich nicht selbst bei jedem Programmstart gegen den SQL Server Authentifizieren? Was ist wenn ein User gesperrt werden soll, dann könnte er trotzt lokaler Credentials einfach weiter arbeiten.
    Bleibt auch die Frage, ob es nicht ein Active Directory oder einen anderen LDPA Dienst gibt welcher die Anmeldung im Single-Sign-Son übernehmen kann.


    kaifreeman schrieb:


    Was sind meine Anforderungen:
    - Client soll aktuell auf WPF bleiben, ein ASP.net Client kommt sicher aber irgendwann später dafür fehlt mir die Zeit.
    - Der Middletier soll auf Windows Server 2016 / 2019 lauffähig sein und wenn geht als Dienst ausgeführt werden.
    - Die Datenbank ist ein MsSQL Server
    - Das wichtigste (zumindest soweit ich es überblicken kann) übertragen von typisierten Objekten vom Client zum Middletier und retour (ich hoffe die Aussage ist soweit korrekt).
    (Mein Problem ist das in allen Code Schnipseln die ich gefunden habe immer nur ein String rumgeschubst wird aber niemand im Ansatz erwähnt ob man ein "Objekt" vom Typ T vom Client zum Server kriegt ohne dieses aus irgendeinem Memorystream odg. wieder zusammenbauen zu müssen.).


    Naja, für mich ganz klar ein ASP.net (Core) REST API. In den Beispielen werden wohl nahezu niemals Strings sondern JSON hin und her geschubst. JSON <> Object ist jetzt nicht wirklich schwer.
    ASP.net kann mit verschiedenen Methoden zur Authentifizierung umgehen.
    Ebenso wäre die Lauffähigkeit auf MS-Server gegeben. Unter Umständen könntest du Teile deines EF-Core Codes im Server weiterverwenden.

    Welcher Typ von Client auf dein API zugreift ist dann später egal. WPF, ASP.net, Angular, Vue .... bis hin zu SOAP UI oder auch Postman zum testen.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.

    MrTrebron schrieb:

    Mal wider der Klassiker. Warum kann der User sich nicht selbst bei jedem Programmstart gegen den SQL Server Authentifizieren? Was ist wenn ein User gesperrt werden soll, dann könnte er trotzt lokaler Credentials einfach weiter arbeiten.
    Bleibt auch die Frage, ob es nicht ein Active Directory oder einen anderen LDPA Dienst gibt welcher die Anmeldung im Single-Sign-Son übernehmen kann.


    Ich hab das vielleicht etwas umständlich beschrieben, die User sind in einem AD und gehören der Gruppe "CRMUser" an, sie Authentifizieren sich ja auch mittels SSO an der DB, wenn ein User also gesperrt wird kriegt das der Server sofort mit.

    Mit ASP.net Core habe ich mich begonnen zu beschäftigen, dann werde ich wohl diesen Weg weitergehen.
    Danke für die Unterstützung.

    Hinweis für alle Nachleser, ich habe mich gerade durch dieses Tutorial gearbeitet:
    https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio

    Eigentlich ziemlich gut erklärt, ich werde mich mal intensiver mit dem Thema auseinandersetzen.
    mfG.
    Stephan

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „kaifreeman“ ()

Facebook
Telefonspende