Come gestisco il dibattito tecnico su WCF vs Web API?

Quando entrambe le parti hanno buone argomentazioni e le opinioni sulla questione sono troppo forti per giungere a un consenso, tu come dirigente devi prendere una decisione e porre fine al dibattito. Altrimenti girerà semplicemente in cerchi e rafforzerà ancora di più le posizioni di tutti i partecipanti. Più a lungo aspetti, più sarà difficile per il lato "perdente" ammettere la sconfitta e lavorare in modo produttivo con il risultato.

Annota tutti gli argomenti, valuta la loro importanza per il progetto e poi prendi la tua decisione. Quando non puoi, lancia una moneta. Il tuo progetto può probabilmente essere completato con successo con entrambe le tecnologie, e sprecare tempo prezioso con discussioni inutili costerà solo denaro inutile.

Supponendo che entrambi i lati siano corretti al 100% in tutti i loro argomenti, quali sono importanti?

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

Ti importa? Stai pensando di fare qualcosa che richiede POCO?

WCF supports distributed transactions

Questo è qualcosa che userete e dovrete compilare se non lo avete perché avete preso l'altro percorso?

Prendi fondamentalmente il cuore di quale:

• Offre tutto ciò di cui hai bisogno (se nessuno dei due offre tutto ciò di cui hai bisogno, il che ti obbliga a fare meno lavoro).
• Offre la quantità minima di spazzatura che non utilizzerai ma devi comunque tollerare.

Qualsiasi argomento esposto che non sia nel percorso di ciò che è necessario portare a termine è irrilevante e non dovrebbe prendere in considerazione la tua decisione, con qualche margine di manovra per considerare l'espansione futura.

Metti i miei due centesimi in.

In qualità di manager, dovresti chiedere ai tuoi compagni di squadra di tenere presente il principio di Yagni . Ciò contribuirà a ridurre l'elenco delle ragioni portate avanti da entrambi i team.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Piuttosto che immergerti nella transazione distribuita, dovresti prendere in considerazione la possibilità di lavorare con compensazione .

L'ultima cosa da tenere in considerazione è la curva di apprendimento. A seconda della scadenza del tuo progetto, come manager, dovresti essere in grado di decidere se è giusto iniziare a imparare una nuova tecnologia oppure no.

Se hai un sacco di tempo da perdere, allora vai per un qualche tipo di Innovation Day dove la squadra A e B avrebbero un giorno per produrre prove di concetti basati sugli stessi requisiti.

A proposito, al tizio che dice " I modelli WCF non sono POCO, a causa di [DataContract] & [DataMember] e quegli attributi ", digli che i POCO sono genericamente pensati per essere entità di dominio e che non è una buona pratica esporre il tuo oggetto di dominio a qualsiasi tipo di client, questo è ciò che servono per DTO.

What should I do now? How do I manage this debate in a constructive way?

In primo luogo, mantieni la soggettività lontana. Negli argomenti del tuo team WebAPI, trovo "Web API è solo il modo moderno" *, "I modelli WCF non sono POCO, a causa di quegli attributi" e " SOAP non è così leggibile e pratico come JSON " piuttosto supponente, se non semplicemente sbagliato, e non aiuterà a prendere una decisione.

Quindi, che cosa fare: decidi cosa vuoi fare con i tuoi servizi , quindi scegli una tecnica che soddisfi questo obiettivo e la sua manutenibilità ed estensibilità con il minor numero di dolori. Puoi farlo semplicemente ricercando se un determinato aspetto è supportato dal framework da utilizzare.

Materiale di lettura interessante:

• Mvc 4 vs Wcf Web Api
• API Web WCF o ASP.NET? I miei due centesimi sull'argomento
• WebAPI o WCF?

*: nota che fai riferimento a Wikipedia per questo, dove la citazione è: " Le applicazioni web Web 2.0 si sono spostate lontano da un'architettura orientata ai servizi (SOA) con web basato su SOAP servizi verso raccolte più coerenti di risorse web RESTful ". Questo è un esempio di utilizzo per quando il tuo servizio deve essere consumato da una pagina web. Questo può anche essere fatto facilmente con WCF, usando WebHttpBinding. Non dice "Usa WebAPI per questo" .

Se questa domanda si estende al di là del "come gestire la discussione" : userei WCF se i servizi devono essere consumati da client non web, perché i suoi metadati consentono di sorprendentemente facilmente generazione client di tipo.

Gestione del team a parte, non si sceglie l'uno sull'altro. È necessario esaminare lo scopo di ciascun servizio Web e utilizzare la tecnologia appropriata per la parte specifica dell'applicazione. È come mettere al bando le procedure di archiviazione quando il team utilizza il framework di entità.

Our usage would be mostly for web, and we would expose our services over HTTP. In some cases (say 5 to 10 percent) we might need distributed transactions though.

Quindi scrivi quei 5 ~ 10% di servizi Web in WCF. Se il servizio deve essere referenziato internamente ad altri progetti, non c'è dibattito. Il vantaggio della possibilità di importare il contratto WCF per creare il proxy client NON è aperto alla discussione. Prende l'intera integrazione, l'efficienza e la sicurezza del tipo a un livello completamente nuovo.

Scrivi ciò che deve essere usato per le API pubbliche (forse) / le richieste Ajax in Asp.net web API.

Se è solo una chiamata ajax specifica per pagina, puoi semplicemente utilizzare Asp.Net MVC.

Non scegliere, abbracciali tutti. WCF e Asp.net web API servono a scopi diversi. Nessuno dice che non puoi avere mele e arancia nella tua macedonia. Cercare di scegliere l'uno sull'altro e spingerlo giù in ogni singolo scenario è solo pura pigrizia.

Il nostro team ha avuto una discussione simile un paio di mesi fa. Il fattore decisivo per noi è venuto da come avremmo creato e implementato ogni tecnologia. Dato che stavamo già creando un'applicazione MVC e stavamo usando Knockout.js per l'associazione dei dati, utilizzavamo efficacemente MVVM con i controller che si limitavano a essere un'API per i dati.

Questo ci ha permesso di categorizzare il nostro uso delle tecnologie con questo progetto come segue:

• L'API Web verrebbe utilizzata come nostra API per le chiamate knockout e Ajax, rendendole i nostri comandi per il pattern MVVM. La nostra logica di business per l'applicazione web è racchiusa dietro questo livello attraverso una serie di classi e repository e fabbriche.
• WCF viene quindi utilizzato per il nostro archivio dati, esponendo i dati dal nostro database per non solo questo sito Web, bit anche per qualsiasi altro sito o servizio che ha consumato i dati esposti.

Anche se questa potrebbe non essere una risposta popolare o iper tecnica, determinare cosa ti serve per prima e come o se la tecnologia ti aiuterà è ciò che ha aiutato il mio team a decidere quale tecnologia usare dove.

In other words, we'd better use Web API, if we want to expose a service over HTTP, but use WCF when it comes to TCP and Duplex.

Questo sarebbe l'approccio più ragionevole. È abbastanza comune avere entrambi i servizi WCF e WebApi nella stessa applicazione Web in cui entrambi servono a scopi diversi.

Solo per correggere alcuni argomenti:

WCF models are not POCO, because of [DataContract] & [DataMember] and those attributes

In molti casi i modelli WCF funzionano senza attributi datacontract / datamember.

SOAP is not as readable and handy as JSON

Non è vero, ma i servizi web WCF di solito portano un semplice XML piuttosto che un SOAP gonfio. Questo sicuramente è leggibile.

Un argomento per WCF: se è disponibile un WSDL, ci sono tonnellate di strumenti in quasi tutte le tecnologie che possono creare proxy dai metadati. D'altra parte, lo schema JSON non è ancora ampiamente supportato.

Perché non camminare su una linea con i servizi dati WCF? belle query in stile OData / webapi e usabilità con i poteri di WCF, e la possibilità di restituire JSON bene. Wcf non è poi così male se si dispone di un buon codice di hosting wcf automatico come il seguente:

link

Direi che non sono affatto lontani, tranne che quando usavamo WebApi nel front-end e WCF data services nel livello intermedio, il WebApi ha lanciato cose semplici come la stringa contiene o stringhe corrispondenti agli operatori odata.

Un buon architetto ritarda le decisioni tecnologiche finché non sono assolutamente necessarie.

In altre parole, non prendere la decisione finché un cliente non ha bisogno di connettersi realmente. È possibile creare un livello di servizio completamente testato senza effettivamente mettere su di esso un meccanismo di trasporto / comunicazione. Il 95% + del lavoro può essere eseguito "sotto" l'adattatore, fuori dal framework.

È giunto il momento di esporre questi servizi ai client remoti, puoi scegliere il framework più trendy e scrivere involucri sottili su un livello di servizio versatile.

Diavolo, se il tuo livello di servizio "reale" è ben fatto, puoi anche provare diversi wrapper con una spesa minima.

Questa è la risposta dogmatica, comunque In pratica , puoi scegliere lo strumento più semplice dallo scaffale per facilitare i primi e frequenti test di integrazione - ma, comunque, limitate la vostra dipendenza da esso e trattatelo rigorosamente come un sottile strato di comunicazione semplicemente sui servizi reali .

Se segui questo approccio, probabilmente troverai lo strumento più semplice da utilizzare inizialmente e nessuno si agiterà , perché il team sa che è possibile implementare uno strumento più sofisticato o di tendenza o quadro successivo, se necessario , con il minimo sforzo.

Se fossi nella tua posizione, inizierei esaminando le abilità della tua squadra. Se tutti i membri del tuo team conoscono già WCF e solo una piccola percentuale conosce l'API Web, la tua decisione è già presa per te.

Con tutti i mezzi, se hai tempo, investilo nell'apprendimento e nel miglioramento della tua base di conoscenze, ma non a discapito delle esigenze aziendali e della produttività aziendale.

Vorrei chiedere quale modello di interazione hai bisogno di supportare? L'interfaccia esterna desiderata è più simile a RPC o REST? Nella mia esperienza di solito è in qualche modo tra ma principalmente uno o l'altro.

Stai consumando i tuoi servizi per altri progetti in .Net? Questa è probabilmente la domanda più significativa che tu possa chiedere. WCF ha il vantaggio di essere in grado di astrarre le interfacce in una libreria di classi separata e di essere in grado di creare e iniettare il client. Come estensione di questo, è possibile montare il progetto basato su WCF con endpoint JSON e SOAP / WSDL, l'ho fatto. WCF offre anche garanzie migliori rispetto alle interfacce definite.

Detto questo, se ci si aspetta di avere clienti da altre piattaforme XML in generale, tanto meno SOAP ha un overhead misurabile oltre a quello che hanno i semplici endpoint JSON. Se segui il percorso dell'API JSON / Web, allora dovrai diventare molto più bravo a documentare come interagire con i tuoi endpoint e le tue API.

In generale, suggerirei di scrivere un semplice documento API che indichi come si invieranno i dati e come si desidera una risposta per una singola struttura di oggetto di richiesta. Scrivi il tuo test case nel modo più universale e documentalo come tale. Consiglierei una semplice dichiarazione di arricciatura. Quindi alcuni dei tuoi membri implementano questo usando WCF e con Web API. Quindi vedi quali vittorie.

Personalmente, nonostante abbia fatto alcuni progetti e implementazioni relativamente grandi con WCF, in realtà mi propongo verso l'implementazione più semplice che nella mia mente sia in realtà un WCF diretto con l'utilizzo di risultati JSON e un comportamento di override nel Global.asax.cs per trattare con condizioni di errore. Se la documentazione di un'API include istruzioni di arricciatura ed è possibile esercitare tutte le funzionalità della propria API con esempi di arricciatura, diventa molto più semplice implementare i client in qualsiasi linguaggio che supporti le interfacce Web. Questo è davvero il punto in cui la WCF inizia a cadere. Avere una API ben definita con documentazione agnostica è meglio che avere strutture con strumenti automatizzati quando si gestiscono sistemi esterni. Parlare come consumatore di quei sistemi da altre piattaforme.

Oltre a ciò, implementa il tuo cliente in due lingue diverse. Fai un client in C #, ma eseguine anche uno in Node.js o Python e vedi come si adattano effettivamente. Solo quell'esercizio ti aiuterà a scuotere le estremità della tua API.

Quindi ora sto affrontando la stessa scelta, mi sono chiesta quale sia il sottoinsieme delle funzionalità di WCF che il nostro team sta utilizzando al momento. Usiamo protocolli diversi? No. Usiamo il supporto per le transazioni? No (anche se usiamo meccanismi di coerenza finali personalizzati). Usiamo il duplex? No.

Perché vorremmo usare l'API Web? Integrazione del frontend più semplice (rimuove il livello di servizio aggiuntivo esistente ora), SignalR per spingere la risposta ai client, la memorizzazione nella cache dei GET.

Può essere, si potrebbero trovare altri motivi :) Inoltre, motivi per rimanere con WCF.