[c#] advies nodig wcf of alternatief

[DShadow]

Hoi medetweakers,

Ik ben bezig een software oplossing op te zetten.
Deze zal uit een 5 tal modules bestaan.
Een client die bij klanten geinstalleerd word.
Een jobserver
Een management console voor mij.
Een website waar klanten hun jobs kunnen beheren

En als laatste een centrale database om de boel aan elkaar te knopen.

Ik richt mij voornamelijk op bedrijven waar soms de boel redelijk dicht getimmerd is.
Nu is het de bedoeling dat klanten in de client kunnen inloggen en van daaruit een job kunnen maken en hun bestanden kunnen opsturen.

Ik ben nu aan het bedenken hoe ik het beste de boel aan elkaar kan knopen. Ik heb nu alles in c# geprogrammeerd. En ik zat te denken om alles aan elkaar te knopen door middel van wcf. Alleen mijn probleem is. Ik ken wcf nog niet voordat ik hier veel tijd in ga steken vroeg ik mij af er betere of makkelijkere alternatieven zijn.

Om misschien al wat mensen voor te zijn. Ik dat onderwerpen beveiliging enzo een expertise opzich is. Ik verwacht geen bank beveiliging. En het is ook mijn intentie om dit later opnieuw te laten maken door een specialist wanneer mijn product aanslaat. Maar daar heb ik nu weinig budget voor.
Of er moet iemand zijn die voor weinig geld voor elkaar kan krijgen.

[MueR]

Kan je een betere titel bedenken? Advies nodig is niet echt veelzeggend. Een voorstel mag via een topicreport ()

[Woy]

Voor communicatie/webservices is WCF enorm eenvoudig in gebruik. Zeker als je gewoon standaard configuratie gebruikt.

Wat ik me vooral afvraag, waarom maak je het zo ingewikkeld. Je hebt het er over dat het bij de klant redelijk dichtgetimmerd kan zitten qua netwerk. Waarom maak je dan niet gewoon een web-applicatie. Als er iets bij een klant gaat werken is dat het wel, tevens hoef je een stuk minder na te denken over hoe de applicaties met elkaar kunnen communiceren.

Eventueel kun je ook een soort hybride applicatie maken d.m.v. MVC en een Web API.

Zou je verder wat op je enter gebruik willen letten? Het leest erg lastig als je bijna na elke zin zelf een enter invoegt. Het leest een stuk makkelijker als je je tekst gewoon opdeelt in alinea's

[sopsop]

In een half uurtje heb je de basics van wcf onder de knie.

Zie bijvoorbeeld deze tutorial: http://www.codeproject.co...for-understanding-Windows

Voor de security zijn er verschillende mogelijkheden, let op dat er verschillende gebieden zijn die je kunt beveiligen: het bericht en de verbinding, En dat je binnen die opties ook nog verschillende mogelijkheden hebt. Over de security zijn boeken vol geschreven, maar zorg dat je een basale vorm hebt waarin de verbinding en/of het bericht zijn versleuteld en er ook een vorm van identificatie in het bericht zit, aangezien je meerdere partijen wilt aansluiten (en met identificatie bedoel ik niet een property in de request met het userid).

[EfBe]

Ik zou voor WebAPI gaan, omdat dat de toekomst is voor het schrijven van services in .NET en het is eenvoudiger in gebruik dan WCF.

[ Voor 23% gewijzigd door EfBe op 22-07-2013 09:57 ]

[Phyxion]

EfBe schreef op maandag 22 juli 2013 @ 09:56:
Ik zou voor WebAPI gaan, omdat dat de toekomst is voor het schrijven van services in .NET en het is eenvoudiger in gebruik dan WCF.

Ik sluit mij hier min of meer bij aan. WCF werkt opzich mooi, maar zodra je tegen een probleem aanloopt hoef je niet te verwachten dat er documentatie over is. WCF heeft echter ook voordelen, je kan echt veel aanpassen tot je eigen wensen, is (mits de juiste binding gebruikt wordt) sneller dan Web API. Het is echter wel veel configuratie werk allemaal, en het hangt helemaal van je wensen af.

Ik weet wel, ik heb nu een WCF service draaien, zodra ik wat meer tijd heb ga ik dit omzetten naar een Web API.

[Rutix]

Phyxion schreef op maandag 22 juli 2013 @ 10:07:
[...]

Ik sluit mij hier min of meer bij aan. WCF werkt opzich mooi, maar zodra je tegen een probleem aanloopt hoef je niet te verwachten dat er documentatie over is. WCF heeft echter ook voordelen, je kan echt veel aanpassen tot je eigen wensen, is (mits de juiste binding gebruikt wordt) sneller dan Web API. Het is echter wel veel configuratie werk allemaal, en het hangt helemaal van je wensen af.

Ik weet wel, ik heb nu een WCF service draaien, zodra ik wat meer tijd heb ga ik dit omzetten naar een Web API.

WCF configuratie is in 4.5 heel wat makkelijker geworden though dus zo heel veel configuratie is er niet meer. Ja je moet je endpoints ect. setten maar zoveel werk is dat niet .

[DShadow]

Woy schreef op maandag 22 juli 2013 @ 08:21:
Wat ik me vooral afvraag, waarom maak je het zo ingewikkeld. Je hebt het er over dat het bij de klant redelijk dichtgetimmerd kan zitten qua netwerk. Waarom maak je dan niet gewoon een web-applicatie. Als er iets bij een klant gaat werken is dat het wel, tevens hoef je een stuk minder na te denken over hoe de applicaties met elkaar kunnen communiceren.

De Jobserver en Client zijn beide plugins in een ander pakket. De client trek informatie uit de plugin host. Via de webservice word deze info beheerd en in de queue gezet. De jobserver leest de info in het andere programma voert een heel stel berekeningen uit en stuurt de output terug. Naar de client.

De applicaties moeten communiceren met de applicaties daarom kan ik het niet met een webservice doen.

Een hybride applicatie zal ik als optie eens gaan bekijken. Ook zal ik de Webapi optie gaan onderzoeken.

[Hooiopdevork]

Ik zou ook voor de WebAPI gaan, het word ook nog eens vervelend met WCF als je klanten gebruik maken van proxyservers.

[Woy]

Hooiopdevork schreef op dinsdag 23 juli 2013 @ 06:22:
Ik zou ook voor de WebAPI gaan, het word ook nog eens vervelend met WCF als je klanten gebruik maken van proxyservers.

Onzin, als je gewoon een HTTP binding gebruikt werkt dat net zo goed met een proxy als een WebAPI.

[InZane]

Woy schreef op dinsdag 23 juli 2013 @ 08:35:
[...]

Onzin, als je gewoon een HTTP binding gebruikt werkt dat net zo goed met een proxy als een WebAPI.

Wat hij zegt ^

Heb toevallig net een WCF webservice met HTTP binding opgeleverd. Heb ook wel ervaring met Web API, maar gezien de complexiteit en een derde partij die er mee moet kunnen werken, ben ik gegaan voor een WCF service.

Hier kun je trouwens een mooi tabelletje vinden met de voor- en nadelen van WCF en Web API: MSDN: WCF and ASP.NET Web API

Qua hoeveelheid werk maakt het niet echt uit.

[lier]

InZane schreef op woensdag 24 juli 2013 @ 10:32:
Heb ook wel ervaring met Web API, maar gezien de complexiteit en een derde partij die er mee moet kunnen werken, ben ik gegaan voor een WCF service.

Juist Web API is super eenvoudig (zeker in vergelijking met de mogelijkheden van WCF). En het lijkt me dat REST en JSON toch wel voldoende ingeburgerd is om ook met andere partijen ermee/over te praten.

[__fred__]

Je hebt alle andere zaken al geprogrammeerd zeg je? Ik zou zeggen dat je keuze dan ook afhankelijk is, van wat je al hebt... Als je toch al een ASP.NET MVC webapplicatie hebt gemaakt voor het jobbeheer, dan is webapi wel logisch.

Als je nog de oude membership providers gebruikt voor gebruikersbeheer, en asp.net forms gebruikt voor je website, dan zou WCF of zelfs .NET 2.0 webservices ook prima werken en wellicht meer code te vinden zijn voor die specifieke techniek.

Ga je een .NET 2.0 client maken vanwege compatibiliteitsdoeleinden dan is wellicht webapi weer niet zo logisch, omdat je dan vrijwel zeker een 3rd party library nodig hebt voor je JSON webservices.

Een werkende oplossing is niet afhankelijk van de techniek. De kans is veel groter dat je het tot een goed einde brengt als je vertrouwde technieken kiest en iets dat past bij de architectuur van de rest van je applicaties. Daar lees ik nog niet zoveel over.

[InZane]

lier schreef op donderdag 25 juli 2013 @ 15:31:
[...]

Juist Web API is super eenvoudig (zeker in vergelijking met de mogelijkheden van WCF). En het lijkt me dat REST en JSON toch wel voldoende ingeburgerd is om ook met andere partijen ermee/over te praten.

Je hoeft natuurlijk niet persé alle mogelijkheden van WCF te gebruiken. Als je een WCF service hebt die alleen over HTTP(S) babbelt, is het net zo makkelijk ontwikkelen, debuggen en deployen als met Web API.
Verder kun je met WCF ook prima RESTful en JSON doen.

Met complexiteit bedoelde ik eigenlijk meer de complexiteit van de berichten. Misschien was ik daar niet helemaal duidelijk over

__fred__ schreef op donderdag 25 juli 2013 @ 15:48:
Je hebt alle andere zaken al geprogrammeerd zeg je? Ik zou zeggen dat je keuze dan ook afhankelijk is, van wat je al hebt... Als je toch al een ASP.NET MVC webapplicatie hebt gemaakt voor het jobbeheer, dan is webapi wel logisch.

Daar ben ik het dan wel mee eens

[ Voor 29% gewijzigd door InZane op 25-07-2013 16:15 ]

[Alexji]

Kijk ook eens naar ServiceStack in plaats van WebApi. Message-based op basis van simpele DTO's. Echt een genot om mee te werken.