Come gestisco il dibattito tecnico su WCF vs. API Web?

Ora sto gestendo un team di circa 15 sviluppatori e siamo bloccati a un certo punto sulla scelta della tecnologia, in cui il team è suddiviso in due team completamente opposti, discutendo sull'uso di WCF vs. API Web.

Il team A che supporta l'utilizzo dell'API Web, presenta questi motivi:

1. L'API Web è solo il modo moderno di scrivere servizi ( Wikipedia )
2. WCF è un overhead per HTTP. È una soluzione per TCP, Net Pipes e altri protocolli
3. I modelli WCF non sono POCO, a causa di [DataContract] & [DataMember] e di quegli attributi
4. SOAP non è così leggibile e maneggevole come JSON
5. SOAP è un overhead per la rete rispetto a JSON (trasporto su HTTP)
6. Nessun metodo di sovraccarico

Il team B che supporta l'utilizzo di WCF, afferma:

1. WCF supporta più protocolli (tramite configurazione)
2. WCF supporta transazioni distribuite
3. Esistono molti buoni esempi e storie di successo per WCF (mentre l'API Web è ancora giovane)
4. Il duplex è eccellente per la comunicazione bidirezionale

Il dibattito continua e non so cosa fare adesso. Personalmente, penso che dovremmo usare uno strumento solo per il suo giusto posto di utilizzo . In altre parole, sarebbe meglio usare l'API Web, se vogliamo esporre un servizio su HTTP, ma usare WCF quando si tratta di TCP e Duplex.

Cercando in Internet, non possiamo ottenere un risultato solido. Esistono molti post per supportare WCF, ma al contrario troviamo anche lamentele da parte delle persone. So che la natura di questa domanda potrebbe sembrare discutibile, ma abbiamo bisogno di alcuni buoni suggerimenti per decidere. Siamo bloccati in un punto in cui la scelta casuale di una tecnologia potrebbe farci pentirci in seguito. Vogliamo scegliere ad occhi aperti.

Il nostro utilizzo sarebbe principalmente per il web e esporremmo i nostri servizi su HTTP. In alcuni casi (diciamo dal 5 al 10 percento) potremmo aver bisogno di transazioni distribuite.

Cosa dovrei fare ora? Come gestisco questo dibattito in modo costruttivo?

Quando entrambe le parti hanno buone argomentazioni e le opinioni sulla questione sono troppo forti per giungere a un consenso, tu come manager devi prendere una decisione e terminare il dibattito. Altrimenti girerà semplicemente in cerchio e rafforzerà ulteriormente le posizioni di tutti i partecipanti. Più a lungo aspetti, più difficile sarà 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. Probabilmente il tuo progetto può essere portato a termine con successo con entrambe le tecnologie, e perdere tempo prezioso con dibattiti inutili costerà solo denaro inutile.

Supponendo che entrambe le parti siano corrette al 100% in tutti i loro argomenti, quali contano?

I modelli WCF non sono POCO, a causa di [DataContract] & [DataMember] e di quegli attributi

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

WCF supporta transazioni distribuite

Ancora una volta è qualcosa che hai intenzione di usare e che devi costruire se non ce l'hai perché hai preso l'altra strada?

Fondamentalmente arriva al 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 il minimo lavoro).
• Offre la minima quantità di spazzatura che non hai intenzione di utilizzare ma che devi comunque sopportare.

Qualsiasi argomento avanzato che non sia sulla strada di ciò che è necessario realizzare è irrilevante e non dovrebbe tenere conto della tua decisione, con qualche margine di manovra per considerare l'espansione futura.

Metti dentro i miei due centesimi.

Come manager, dovresti chiedere ai tuoi compagni di squadra di tenere presente il principio Yagni . Ciò contribuirà a ridurre l'elenco dei motivi presentati da entrambe le squadre.

Il nostro utilizzo sarebbe principalmente per il web e esporremmo i nostri servizi su HTTP. In alcuni casi (diciamo dal 5 al 10 percento) potremmo aver bisogno di transazioni distribuite.

Invece di immergerti in una transazione distribuita, dovresti considerare di lavorare con una compensazione .

L'ultima cosa da prendere 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 o no.

Se hai un sacco di tempo da perdere, vai per una sorta di Giornata dell'innovazione in cui i team A e B avrebbero un giorno per produrre prove di concetti basati sugli stessi requisiti.

A proposito, al ragazzo che dice "I modelli WCF non sono POCO, a causa di [DataContract] & [DataMember] e quegli attributi ", digli che i POCO sono generalmente intesi come entità di dominio e che non è una buona pratica esporre il tuo dominio si oppone a qualsiasi tipo di client, ecco a cosa servono i DTO.

Cosa dovrei fare ora? Come gestisco questo dibattito in modo costruttivo?

Innanzitutto, mantieni la soggettività. Nelle argomentazioni del tuo team WebAPI, trovo "L'API Web è solo il modo moderno" *, "I modelli WCF non sono POCO, a causa di quegli attributi" e "SOAP non è leggibile e maneggevole come JSON" piuttosto supponente, se non del tutto sbagliato e non aiuterà a prendere una decisione.

Quindi, cosa fare: decidi cosa vuoi fare con i tuoi servizi , quindi scegli una tecnica che soddisfi quell'obiettivo e la sua manutenibilità ed estensibilità con la minima quantità di dolore. Puoi farlo semplicemente ricercando se un determinato aspetto è supportato dal framework da usare.

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 ti riferisci a Wikipedia per questo, dove la citazione è: " Le applicazioni web Web 2.0 si sono allontanate da un'architettura orientata ai servizi (SOA) con servizi web basati su SOAP 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 va oltre il "come gestire la discussione" : utilizzerei WCF se i servizi non dovessero essere utilizzati da client non web, poiché i suoi metadati consentono una generazione di client fortemente tipizzata sorprendentemente semplice.

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 vietare le procedure del negozio quando il team utilizza il framework di entità.

Il nostro utilizzo sarebbe principalmente per il web e esporremmo i nostri servizi su HTTP. In alcuni casi (diciamo dal 5 al 10 percento) potremmo aver bisogno di transazioni distribuite.

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

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

Se si tratta solo di una chiamata Ajax specifica per la pagina, puoi semplicemente utilizzare Asp.Net MVC.

Non scegliere, abbracciali tutti. Le API Web WCF e Asp.net hanno scopi diversi. Nessuno dice che non puoi avere mela e arancia nella tua macedonia. Cercare di sceglierne uno sopra l'altro e spingerlo giù in ogni singolo scenario è solo pigrizia.

La nostra squadra ha avuto una discussione simile un paio di mesi fa. Il fattore decisivo per noi è dipeso dal modo in cui avremmo creato e implementato ogni tecnologia. Dato che stavamo già costruendo un'applicazione MVC e usavamo Knockout.js per l'associazione dei dati, stavamo effettivamente utilizzando MVVM con i controller che erano solo 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 API per le chiamate knockout e Ajax, rendendoli i nostri comandi per il modello MVVM. La nostra logica aziendale per l'applicazione Web è racchiusa in questo livello attraverso una serie di classi, repository e fabbriche.
• WCF viene quindi utilizzato per il nostro archivio di dati, esponendo i dati dal nostro database non solo per questo sito Web, ma 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 di cosa hai bisogno prima e come o se la tecnologia aiuterà è ciò che ha aiutato il mio team a decidere quale tecnologia utilizzare dove.

In altre parole, sarebbe meglio usare l'API Web, se vogliamo esporre un servizio su HTTP, ma usare WCF quando si tratta di TCP e Duplex.

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

Giusto per correggere alcuni argomenti:

I modelli WCF non sono POCO, a causa di [DataContract] & [DataMember] e di quegli attributi

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

SOAP non è così leggibile e maneggevole come JSON

Non è vero, ma i servizi Web WCF di solito portano XML semplice anziché 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 seguire la linea con WCF Data Services? belle query in stile OData / webapi e usabilità con i poteri di WCF, e la possibilità di tornare JSONbene. Inoltre Wcf non è poi così male se hai un bel codice di hosting wcf automatico come il seguente:

https://github.com/ImaginaryDevelopment/MvcOdata

Direi che non sono del tutto separati, tranne che quando siamo andati a utilizzare WebApisul front-end e WCF data servicessul livello intermedio, WebApiho vomitato su cose semplici come la stringa contiene o gli operatori di odata di corrispondenza delle stringhe.

Un buon architetto ritarda le decisioni tecnologiche fino a quando non sono assolutamente necessarie da prendere.

In altre parole, non prendere la decisione fino a quando un client non deve effettivamente connettersi. È possibile creare un livello di servizio completamente testato senza in realtà inserire un meccanismo di trasporto / comunicazione su di esso. Il 95% + del lavoro può essere eseguito "sotto" l'adattatore, al di fuori del framework.

Arriva il momento di esporre questi servizi ai clienti remoti, puoi scegliere il framework più trendy dallo scaffale e scrivere wrapper sottili su un livello di servizio versatile.

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

Questa è la risposta dogmatica, comunque. In pratica , potresti voler scegliere lo strumento più semplice dallo scaffale per facilitare test di integrazione precoci e frequenti - ma, ancora limitare la tua dipendenza da esso e trattarlo rigorosamente come un semplice livello di comunicazione sui servizi reali .

Se segui questo approccio, probabilmente scoprirai che scegli lo strumento più semplice da utilizzare inizialmente e nessuno si agiterà , perché il team sa di poter implementare uno strumento o un framework più sofisticato o di tendenza in un secondo momento, se necessario , con il minimo sforzo.

Quindi ora sto affrontando la stessa scelta, mi sono chiesto quale sia il sottoinsieme di funzionalità di WCF che il nostro team sta usando al momento. Usiamo protocolli diversi? No. Utilizziamo il supporto per le transazioni? No (sebbene utilizziamo eventuali meccanismi personalizzati di coerenza). Usiamo il duplex? No.

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

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

Se fossi nella tua posizione, inizierei esaminando le abilità delle tue squadre. 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.

Sicuramente se hai tempo, investilo nell'apprendimento e nel miglioramento della tua base di conoscenze, ma non a spese delle esigenze aziendali e della produttività dell'azienda.

Vorrei chiedere quale modello di interazione è necessario supportare? L'interfaccia esterna desiderata assomiglia di più a RPC o REST? Nella mia esperienza di solito è da qualche parte tra ma soprattutto l'uno o l'altro.

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

Detto questo, se si prevede di avere client 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, dovrai diventare molto più bravo a documentare come interagire con i tuoi endpoint e API.

In generale, suggerirei di scrivere un semplice documento API che indichi come inviare i dati e come si desidera una risposta per una singola struttura di oggetti richiesta. Scrivi il tuo test nel modo più universale e documentalo come tale. Consiglierei una semplice dichiarazione a ricciolo. Quindi chiedi a molti dei tuoi membri di implementarlo utilizzando WCF e con l'API Web. Quindi vedi quale vince.

Personalmente, nonostante abbia realizzato progetti e implementazioni relativamente grandi con WCF, in realtà mi rivolgo all'implementazione più semplice che nella mia mente è in realtà WCF diretta con l'utilizzo di risultati JSON e alcuni comportamenti prioritari in Global.asax.cs per gestire le condizioni di errore. Se la documentazione di un'API include istruzioni di arricciatura ed è possibile esercitare tutte le funzionalità dell'API con esempi di arricciatura, diventa molto più semplice implementare i client in qualsiasi lingua che supporti le interfacce Web. Questo è davvero dove WCF inizia a cadere. Avere un'API ben definita con documentazione agnostica è meglio che avere strutture con strumenti automatizzati quando si ha a che fare con sistemi stranieri. Parlando come un consumatore di quei sistemi da altre piattaforme.

Una cosa oltre a ciò, è implementare il tuo client in due lingue diverse. Esegui un client in C #, ma esegui anche uno in Node.js o Python e vedi come si adattano effettivamente. Solo questo esercizio ti aiuterà a scovare le estremità libere nella tua API.