Laden...

Welche Technologien verwende ich am Besten beim Implementieren von Server und DB (Client: WPF)?

Erstellt von Silver80 vor 6 Jahren Letzter Beitrag vor 6 Jahren 3.097 Views
S
Silver80 Themenstarter:in
9 Beiträge seit 2017
vor 6 Jahren
Welche Technologien verwende ich am Besten beim Implementieren von Server und DB (Client: WPF)?

Nabend,
Ich hoffe ich habe den richtigen Platz für meine Frage gewählt. Naja werde ich ja gleich merken.
Ich programmiere seit je her normale clientanwendungn (C#-WPF) die eine direkte Anbindung an eine DB haben. Logischerweise liegt dann beim Client auch die ganze Funktionalität.
Jetzt möchte ich mich einfach mal ein bisschen weiterentwickeln und möchte zwischen DB und Client einen Server setzen. Dieser soll Daten aus der DB Laden ( auch Updaten) und vorallem eine Menge an bestimmten Berechnungen durchführen und dann das Ergebnis im Speicher halten. Wenn jetzt ein Client (C#; WPF Anwendungen) sich beim Server anmeldet soll der Server diese Daten zur Verfügung stellen.

Meine Frage nun. was nehme ich als Server? Und was zur Kommunikation?
schreibe ich den Server in c#? Die Berechnungen die der Server durchführen muss ist jetzt keine Raketenwissenschaft... Aber halt auch nicht gerade return calc(1+2)
Ich möchte mich in das Thema einarbeiten. Also bitte nur ein Vorschläge. Clientanzahl würde ich kleiner 100 sagen. Also jetzt nicht mega viele.

Kann mir da jemand helfen?

Vielen Dank

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Silver80,

klassisch wird dein Server als "Application Server" bezeichnet. Grob schaut das so aus:


+--------+       +--------------------+        +----+
| Client | ----> | Application Server | --+--> | DB |
+--------+       +--------------------+   |    +----+
                                          |
                                          |    +----------------+
                                          +--> | anderer Dienst |
                                               +----------------+

Aktuell gibt es aber einen Trend hin zu "Micro services", indem mehrere kleine "Application Server" vorhanden sind und die nur eine Aufgabe übernehmen. Dies hat u.a. den Vorteil dass dieser Mini-Service isoliert entwickelt und getestet werden kann. Aber auch den Nachteil, dass eben mehrere Services betreut werden müssen.
Schaut z.B. so aus (es gibt hier viele Möglichkeiten):


                                           +-----------------+       +----------------+
                                      +--> | Micro Service 1 | ----> | anderer Dienst |
+--------+       +----------------+   |    +-----------------+       +----------------+
| Client | ----> | Service Facade | --+    ...
+--------+       +----------------+   |    +-----------------+       +----+
                                      +--> | Micro Service n | ----> | DB |
                                           +-----------------+       +----+

schreibe ich den Server in c#?

Klar 😉

was nehme ich als Server?

Da gibt es viele Möglichkeiten und die hängen v.a. auch davon ab auf welche Plattform du dich "festlegen" möchtest.

Rein Windows -> Asp.net Core WebAPI od. WCF
.net Core (Windows, Linux, MacOs) -> Asp.net Core WebAPI (ev. in einem Docker Container)
Cloud / Azure -> Asp.net Core WebAPI gehostet und in einem App-Service od. per Azure Functions

Und was zur Kommunikation?

Alle Varianten basieren auf HTTP.
Die oben erwähnten Micro-Services können somit auch in einer anderen Sprache / Technologie erstellt werden, da HTTP wirklich plattform- und technologieunabhängig ist.

WCF bietet auch TCP, Named Pipes, Message Queues an, aber bei WCF bist du auf Windows beschränkt.

Es kommt also darauf an was du genauer willst, denn einen einzigen Königsweg gibt es nicht.

Wenn du die Zeit hast, so schau dir alle Variante an, denn dadurch lernst du eine Menge und kannst du selbst ein gutes Bild über die einzelnen Möglichkeiten mit den Vor-/Nachteilen und deren potentiellen Einsatzmöglichkeiten bilden.

Bei allen Variante würde ich für den Client eine Fassade bereitstellen, welche zum Einen den Zugriff auf den/die "Server" wegabstrahiert und den Zugriff auch einfach möglich macht.
So lässt sich der Server auch mit geringen Aufwand (für den Client) tauschen und zudem kann der Client besser getestet werden, da der Server bzw. dessen Fassade einfach gemockt werden kann.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.806 Beiträge seit 2008
vor 6 Jahren

Micro Services haben auch noch folgende zu erwähnende Vorteile:

  • Durch die physikalische Trennung der Services können je nach Anforderung unterschiedliche Technologien zum Einsatz kommen
  • Die Ersetzbarkeit sowie die Wartbarkeit wird immens erhöht
  • Die Ausfallwahrscheinlichkeit des Gesamtsystems wird minimiert
  • Die Skalierung wird vereinfacht (bzw. teilweise erst möglich)
  • Nicht nur die Services, sondern auch die Daten sind isoliert; es ist also einfacher je nach Einsatzzweck eine andere Datenbank zu verwenden.

Service Facades sind nicht zwangsläufig ein Teil von Microservice Architekturen.
Die Facade wird in Architektur-Lektüren i.d.R. als Composite Service bezeichnet und spielt bei der Service Orchestration eine Rolle.
Bei der Service Choreography, was besonders für kleinere Szenarien einfacher ist, gibt es weder eine Facade noch ein Composite Service.

Für die Kommunikation nutzt man schlechte, technologieunabhängige Protokolle; o.d.R. JSON-basiert.

Nachteile gibt es aber natürlich auch:

  • Tracing bzw. allgemein die Nachvollziehbarkeit über mehrere Services ist komplex
  • Choreography erfordert ein gutes organisatorisches Management, was die API Kompatibilitäten betrifft (Versionierung, Umbrellas -> DevOps!)
S
Silver80 Themenstarter:in
9 Beiträge seit 2017
vor 6 Jahren

Wow, top vielen Dank für die Antwort.

Der unterschied zwischen asp.net und wcf muss ich mal noch verstehen aber ich schau mal. Ich finde ess gibt aktuell einfach zu viele Möglichkeiten wie man was umsetzen kann.

ich komme aktuell mit den ganzen Technologien durcheinander. Ob REST, NODEJS, ASP.NET ,WCF, Angular etc..... es gibt aktuell zu viele...
Aber wenn ich dich richtig verstehe ist wäre zum Beisiel nodejs als microservice einsetzbar.

16.806 Beiträge seit 2008
vor 6 Jahren

In meinen Augen - ich weiß, dass gfoidl das anders sieht - halte ich WCF in diesem Szenario als ungeeignet.
WCF ist ein riesiger Monolith und nicht so schlank wie ASP.NET Core. Die Zukunft von WCF ist auch ungewiss.
Wer SOAP braucht, was mit das letzte Argument für WCF bislang war: seit kurzem gibt es auch eine entsprechende Middleware für ASP.NET Core.
Wer kein altes Projekt mit WCF übernehmen muss, der braucht sich auch WCF nicht mehr anschauen.

Mir ist noch kein produktiver Einsatz von WCF in einem Microservice Szenario unter gekommen; geschweige denn, dass WCF in entsprechenden Konzepten und Vergleichen im Netz auf wichtigen Seiten auch nur ansatzweise erwähnt wird.

Wenn Du im Web neu bist, so scheint es mir, wird es auch eine ganze Weile brauchen, bis Du mit den Technologien zurecht kommst.
Entwickler, die Jahre nur auf dem Desktop unterwegs sind, sind hier häufig überfordert.
Kein Entwicklungsbereich ist so anspruchsvoll und schnell verändernd wie der ganze Web- und Cloudbereich/Stack und dessen Technologien.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Abt,

täusch dich mal nicht 😉
Ich sehe es nicht allgemein anders, nur je nach konkretem Kontext.
Da du auf Windows Dienst mit WCF oder Alternative anspielst (hatte ich extra nicht verlinkt, damit die (ziellose) Diskussion nicht neu durchgemacht werden braucht), so würde ich dort -- Windows-Service lt. Frage -- WCF nehmen.

Hier sehe ich die Frage aber eher allgemein und zur Orientierung des OT, daher ist meine Antwort auch neutral, sogar eher Richtung HTTP-basierten Diensten, ausgefallen.

Bin ich aufgrund der Rahmenbedingungen, wie z.B. IT-Richtlinien, Intranet, etc., auf Windows beschränkt, so ist für mich WCF eine Option.
Bin ich aber in den Rahmenbedingungen freier und weiß nicht was kommen wird (in Hinsicht auf potentielle Clients), so ist ein HTTP-basierter Dienst die bessere Wahl. Kann ich Azure, etc. nutzen, so ist meine Wahl auch klar, und es ist nicht WCF...
Im anderen Thread hab ich das auch nicht anders dargestellt.

SOAP braucht, was mit das letzte Argument für WCF bislang war

Aber nicht von mir. Von SOAP an sich halte ich nicht viel, da es ja trotz Protokoll und Standard leider nicht mit verschiedenen Plattformen / Technologien einwandfrei klappt.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.806 Beiträge seit 2008
vor 6 Jahren

Allein die Tatsache - Windows-only hin oder her - dass Microsoft sich nicht positiv zur Zukunft von WCF äußert - sondern im Gegenteil: negativ! - schließt für mich aus, dass ich WCF in irgendeiner Richtung empfehlen würde.

Wenn man bestehendes Zeug mit WCF hat: okay!
Neue Wiese: WCF keine Option mehr.

Gleiches empfehlen direkt in dem GitHub-Link auch die MS-Leute wie Fritz oder Miller...
Versteh nicht, wie man da noch auf WCF beharren kann.
Es gibt ja (neue) Technologien, die (fast) den gesamten Stack von WCF abdecken und zukunftsorientiert sind: ASP.NET Core!

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Abt,

wie man da noch auf WCF beharren kann.

Wenn du mit "man" mich meinst, so zeig mir wo ich in diesem Thread auf WCF beharre. Und du kannst mich auch direkt ansprechen, wir kennen uns ja lange genug 😉
Solange WCF nicht definitiv tot ist, gehört es, mit samt der Abhängigkeit zu Windows und .net Full, eben auch erwähnt.
Ich glaub nicht dass WCF sterben wird -- das lese ich aus der GitHub-Issue, die mir bekannt ist, nicht heraus. Zumal es auch die Möglichkeit gibt WCF (Server) als open source Projekt weiter zu entwickeln. Und MS hat ihre Wege in Bezug auf .net Core auch schon öfters radikal geändert (project.json, asp.net Core und .net Full, etc.), vllt. es auch hier der Fall (hab dazu aber keinerlei Infos).

Wie du erwähnst gibt es bei asp.net Core Möglichkeiten, welche fast den gesamten WCF-Stack abbilden. Passt ja so.
Aber nur als Beispiel: wenn ich lokal eine IPC brauche*, so bin ich mit WCF besser dran, als mit asp.net Core. Da sehe ich weiterhin eine Daseinsberechtigung. Und wenn es über mehere Server geht, die noch dazu heterogen sein können, so -- ich wiederhole mich -- sehe ich WCF nicht als passend.

Im anderen Thread, beharre ich auch nicht auf WCF, sondern schreibe dass ich WCF nehmen würde, da ich damit am effizientesten zum Ziel komme.

Gegen asp.net Core, etc. spreche ich mich auch nicht aus, aber du versuchst mir das unterzuschieben (kommt mir halt vor).
Je nach Anforderung nehme ich das Mittel her, mit dem ich am effektivsten weiterkomme.

Wenn es neue Mittel und Wege gibt, so ist das gut, aber nur weil sie "in" sind, ist das noch kein ausreichendes Argument sie als besser zu betrachten wie bisherige Mittel.
Dabei sollte und muss aber betrachtet werden warum etwas "in" ist. Ist es nur "in" weil es gehypt wird bzw. werden muss, so ist das schön, bringt aber nichts. Ist es "in" weil aus bisherigen Methoden / Ansätzen gelernt wurde und die Verwendung für das Aufgabengebiet einfacher und passender wird, so ist das gut und tatsächlich ein Grund dass es "in" ist.
Ich bin weder naiv, noch so konservativ dass ich mit Biegen und Brechen an bestehenden Technologien hänge. Aber solange neue Technologien, bezogen auf die Anforderung, keinen nennenswerten Vorteil bringen schmeiß ich eine bestehende Technologie nicht über Bord.

Die Entwicklung von .net Core macht durchaus Sinn und ich begrüße die. Darin gibt es ein paar super Ansätze die mir sehr gut gefallen und bestimmte "Dinge" besser als in .net Full gelöst wurden (asp.net Core ist endlich vernüftig und hat nur einen Controller anstatt zwei, DI ist dabei, Logging ist besser, weit mehr Abstraktionen, usw.).
Zumal auch aus der Erfahrung mit .net Full jede Menge gelernt wurde und dies in die neue Entwicklung mit einfließen konnte. Andererseits war die Entwicklung von .net Core nötig um für Container- und Cloud-Einsätzte besser od. überhaupt gewappnet zu sein. (Ich weiß dass dir das mehr als genau bekannt ist.)

Es gibt jedoch auch eine .net-Welt außerhalb der Cloud und außerhalb von Containern bzw. eine die auf Windows beschränkt ist.
Und warum sollte ich hier auf eine Möglichkeit verzichten, nur weil sie nicht mehr "in" ist?

Wie oben erwähnt glaube ich nicht dass WCF sterben wird. Ich glaub aber auch nicht dass es 1:1 in .net Core übernommen werden wird, falls überhaupt. Da kann ich mir eher vorstellen, dass es eine "Core"-Version geben wird, die eben auch aus der Erfahrung gelernt hat und bestimmte unhandliche Punkte von WCF besser löst bzw. überhaupt weglässt, da sie selten bis kaum benötigt werden.

mfG Gü

* auch in Zeiten von Micro-Services, etc. sind diese nicht überall passend und eine klassische IPC kann noch angebracht sein

PS: .net Core und asp.net Core verwende ich auch produktiv in verschiedenen Umgebungen, da hänge ich nicht unbedingt an .net Full

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
Silver80 Themenstarter:in
9 Beiträge seit 2017
vor 6 Jahren

Ich freue mich ja wenn dieser Eintrag zu Diskussionen anregt, aber
ich finde es aber eher verwirrend mit welchen Begrifflichkeiten hier diskutiert wird (Und es macht es einem nicht leichter sondern schwieriger, sorry). 🤔

Ob WCF tot ist, sein wird oder auch nicht kann ich nicht beurteilen.... Ich bin jedoch davon überzeugt das es andere Technologien so gesehen, wenn sie aktuell neu und modern sind, auch schon in der Versenke verschwinden werden... Die Anzahl der Möglichkeiten sind einfach zu groß (meine persönliche Meinung) und Softwareentwickler wollen nicht jedes halbes Jahr sich neue "Skills" aneignen...

Gibt es zu Micro Service ein paar --> gut verständliche <-- Links um sich in die Sache einzuarbeiten ?

Merci...

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Silver80,

ja da hast du recht -- sorry wenn wir dich mehr verwirren als helfen. Mit der Anzahl der Möglichkeiten hast du auch recht und es kann sich so ergeben wie du sagst. Es kann gut sein dass gem. Evolution sich das wieder beruhigen wird, wenn sich bessere Wege herauskristallisieren. Aktuell kann ich mir das aber nicht so ganz vorstellen, das wird noch eine Weile dauern und in dieser Zeit gibt es wieder etwas Neues...

Gibt es zu Micro Service ein paar --> gut verständliche <-- Links um sich in die Sache einzuarbeiten ? Free eBook/Guide on ‘.NET Microservices – Architecture for Containerized .NET Applications’ und die Links in All about Microservices kann ich dir da empfehlen.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

16.806 Beiträge seit 2008
vor 6 Jahren

Die Anzahl der Möglichkeiten sind einfach zu groß (meine persönliche Meinung) und Softwareentwickler wollen nicht jedes halbes Jahr sich neue "Skills" aneignen...

Das wirst Du aber müssen, wenn Du im Web mit Expertise vorne mitspielen willst.
Kein anderer Bereich entwickelt sich so stark und so schnell, wie das Web. Und in Sachen Cloud, die vieles an Technologie beschleunigen - und damit den Gesamtmarkt - wird die Geschwindigkeit auch eher schneller als langsamer.
Ein halbes Jahr Urlaub als Experte und Du hast quasi eine Entwicklungsdekade verpasst.

Deswegen gibt es aber auch Spezialisten (oft Evangelisten, Advocates und Co genannt), die dafür da sind, dieses Wissen für Anwendungsfälle zu filtern und als Berater zur Seite zu stehen.
Dass das so im Alltag mit der Geschwindigkeit nicht klappen wird: das muss man auch organisieren können.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Abt
Stimmt, aber es gibt auch Firmen, die z.B. langlebige Produkte entwickeln und pflegen müssen.
Dann hat man den Fall, dass man auch noch in X Jahren die gleiche Technologie verwenden muss bzw. soll.
So sollte unser neustes Projekt auch noch mit Web Forms umgesetzt werden, was aber allen Entwicklern klar war, dass dies nicht sinnvoll ist und wir dies nicht machen wollen.
So haben wir uns dann dazu entschieden direkt mit Angular 2/4 eine SPA mit WebAPI umzusetzen.

In diesem Fall verwenden wir primär bei unseren bestehenden Projekten noch massiv WCF und in ganz alten Projekten auch noch SOAP.
Da wir unsere neuen und alten Projekte auch koppeln müssen, kommen wir auch nicht um WCF in neuen Projekten herum.
Zwar bin ich auch der Meinung, dass man auf den neusten Stand der Dinge sein sollte.
Aber es gibt häufig Fälle, dass man dies nicht vollständig machen kann.

WCF und SOAP wird es auch zukünftig geben, da es eben öffentliche Schnittstellen gibt und noch sehr lange geben wird, die darauf aufbauen.
WCF wird sich, selbst wenn MS noch heute den Support beendet würde, in 5 Jahren und teilweise mehr, noch zum Einsatz kommen.

Aus Entwicklersicht wäre dies natürlich nicht ratsam, gerade wenn es mit WebAPI samt JSON als Format einen leichtgewichtieren Ansatz gibt.
Aber gerade im Business Bereich muss man Schnittstellen umsetzen, die dann eben lange Online bleiben müssen und nicht einfach so ihr Format ändern können.

Nachtrag:
Es wäre vielleicht ratsam das Thema in einem eigenen Thread auszulagern, da es genug Stoff liefert und vom Thema abweicht.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 6 Jahren

@Abt
Stimmt, aber es gibt auch Firmen, die z.B. langlebige Produkte entwickeln und pflegen müssen.

Da dagegen hab ich auch kein Wort verloren.
Aber Technologien und das Fachwissen wird sich nicht bremsen, nur weil Firmen langfristige Projekte haben.
Da werden Firmen auch lernen >müssen< agiler zu sein. So hart (und unreal) sich das anhört.

Ich hab auch nie gesagt, dass WCF heute weg ist, nur weil die Zukunft nicht geklärt ist.
Aber noch Projekte damit anzufangen, wenn es für den gleichen Zweck modernere und zukunftssichere(re) Alternativen gibt... 🤔

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Abt
Ist korrekt.
Das Problem ist nur, dass man es manchmal verwenden muss, auch bei neuen Projekten.
So haben wir einige Dienste, die eben noch auf SOAP/WCF aufbauen und deshalb auch neue Projekte noch per WCF diese Dienste ansteugern müssen.
Auch in unserem neuen Projekt haben wir diesen Fall.
So sollen Geopositionen und Adressen geocodiert werden.
Dafür haben wir noch eine .Net 4 Projekt was einen WCF Dienst anbietet.
Entsprechend müssen wir in der WebAPI dann per WCF auf diesen Dienst zugreifen.

Wenn es aber darum geht neue Dienste umzusetzen, die eigene Schnittstellen anbieten, würde ich diese auch mit aktuellen Ansätzen wie WebAPI auf JSON Basis umsetzen.
In diesem Punkt sind wir uns einig.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

78 Beiträge seit 2016
vor 6 Jahren

Um Silver80 die Bedenken ein wenig zu nehmen.
REST gehört eigentlich nicht zur Kategorie „eine neue Sau durchs Dorf treiben“.
Los gelöst von Docker, .NET Core, Angular, React, Vue, Microservices, … gibt es REST als Architekturstil schon sehr lange. Somit haben wir wenigstens da eine gewisse Stabilität.
Und das gute dabei ist, egal welches Framework/Sprache/Runtime .. etc. ich nehme, HTTP und REST gehen immer.

Ich würde eine neue Applikation nicht mehr mit WCF und SOAP umsetzen wollen.
Bestandsapplikationen sind natürlich eine andere Geschichte. Da muss man sich schon sehr genau überlegen ob eine Migration sinnvoll ist (aber so war es ja schon immer).

http://dotnet-paderborn.azurewebsites.net/

16.806 Beiträge seit 2008
vor 6 Jahren

T-Virus, nich böse sein - aber ich antworte da jetzt nicht mehr drauf.
Wir drehen uns im Kreis. Das wird nichts. Besonders zum Thema SOAP und wie man damit modern umgehen kann, ist alles gesagt.

Um mit den Technologien umgehen zu können, muss man sie auch einordnen können.
HTTP konkurriert mit AQMP, aber nicht mit Angular.
HTTP ist ein Kommunikationsprotokoll; Angular ein Client-Framework.
Dieses Abstrakt muss man lernen.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@Abt
Ich bin dir doch nicht böse deshalb 😃
Ich hatte leider wieder mehr um den heißen Brei geschrieben als nötig.

Die Kurzform soll nur sein, dass es manchmal nicht einfach so möglich ist nur noch auf neue Techniken zu setzen und man eben auch WCF und co. noch wegen Abhängigkeiten benötigt.
Gerade wenn man Softwareabhängigkeiten geschaffen hat wie WCF/SOAP Dienste und diese eben nicht einfach mal so umgeschrieben werden können.

Passt vielleicht nicht ganz zu deiner Aussage, dass man bei neuen Projekten auf WCF verzichten sollte.
Aus meiner Sicht lässt der GitHub Link schon erahnen, dass WCF keine größere Zukunft mehr erwarten kann.
Die Argumente dafür sind auch nachvollziehbar und kann ich auch zustimmen.
Die heutigen Möglichkeiten mit Formaten wie JSON, die auch noch bei älteren Projekten gerade bei unseren Kunden angefragt werden, sind da schon Zielführender.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.