Hallo
Ich bräuchte mal einen Denkanstoß. Ich habe eine WPF-Applikation die jetzt mit einer Fremdapplikation via einer API-DLL angesprochen werden soll. Es sollen Daten in meine Applikation übergeben, dort verarbeitet und das Ergebnis wieder zurück geliefert werden. Ich habe jetzt probiert, über WCF aus der API-DLL mit meiner Anwendung zu kommunizieren (diese ist dann der WCF-Host). Hier habe ich aber zwei Probleme :
Ist hier WCF überhaupt das richtige Mittel oder würdet Ihr das anders lösen? Wenn WCF richtig ist, dann kann ich ja relevante Teile hier posten und auf Eure Hilfe bezüglich der Probleme hoffen.
mfG
Thomas
Ich würde hier WCF aus dem Spiel lassen und in Deiner Anwendung lieber eine REST-API anbieten. WCF ist ohnehin obsolete und ist von nicht-.NET Anwendungen nur aufwändig zu verwenden.
Dann fällt auch das Problem mit der offenen Verbindung / dem offenen WCF Kanal weg, da alles über ein verbindungsloses (HTTP) Protokoll ausgetauscht wird.
Dass die API Bereit ist kannst Du in der Form gar nicht mitteilen, wenn es nicht schon einen anderen Mitteilungskanal gibt.
Alternative wäre nur ein Windows-Service, der quasi als Proxy fungiert.
Aber auf der Consumer Seite müsste man ein Timeout / NoResponse ohnehin abfangen - das wäre mir persönlich für den Zweck zuviel Aufwand, der sich eher ned lohnt 😉
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Hallo
Danke für die Infos, werde mich mal mit REST beschäftigen.
mfG
Thomas
ASP.NET WebAPI ist der REST-Nachfolger für WCF.
WebAPI (oder NancyFX) können auch via Self Hosted in Deiner WPF Anwendung laufen.
Tu nur leuten einen Gefallen und lass den SelfHost nicht auf localhost:80 laufen.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Tu nur leuten einen Gefallen und lass den SelfHost nicht auf localhost:80 laufen.
😁
Microsoft MVP // Me // Blog // GitHub // @Egghead // All my talks // Speakerdeck
Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca
Da ich nun drei PNs bekommen hab, die sich darauf bezogen, wieso ich WCF obsolete nenne:
WCF in der heutigen Form hat keine Basis mehr, die für die Zukunft geeignet ist.
Warum ist sie das nicht: alle Microsoft-Technologien fokussieren sich Richtung x-plat (Windows, Linux, Mac) - und das geht mit WCF in der heutigen Form nicht.
Von der sehr komplexen Konfiguration mal ganz zu schweigen.
Zudem haben einige Technologien (WCF ist ein superset) von WCF bereits bessere Alternativen gefunden;zB die WebAPI für REST.
Andere Dinge - wie bi-direktionale Kommunikation mit zB. MTOM Encoding - ist WCF aktuell noch sehr alleine da.
Meine persönliche Vermutung - und ich habe hier keine näheren Informationen - ist, dass WCF ein Nachfolger bekommen wird. Wenn wir Glück haben, dann wie KESTREL basierend auf libuv.
Ob dieser WCF heisst, WCF Core 1 oder einen völlig anderen Namen bekommt: keine Ahnung. Ob es ihn wirklich geben wird: auch keine Ahnung.
Ich will hier auch keine Spekulation starten aber rein technologisch ist WCF einfach alt und braucht dringend einen Nachfolger / Alternativen.
Wenn man aber nicht unbedingt irgendwelchen exklusiven WCF Features braucht; mein Rat: sucht Alternativen. Nehmt Alternativen.
Für REST eben die WebAPI oder NancyFX.
WCF wird in meiner Begrifflichkeit jedoch weiterhin als obsolete betitelt - als "tot" werde ich WCF aber solange nicht nennen, bis dieser Zustand auch dann wirklich eingetreten ist.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code