JQuery / JSON + .Net Service Layer - a WCF o Not a WCF?

Se sei in prima linea .Net (4.5), vedo davvero due opzioni:

• API Web (la cosa REST del controller mvc)
• Wcf tramite SOAP

Entrambi possono agire come un livello di servizio in un sistema .Net.

Potresti anche usare Wcf su JSON (REST), ma questa non è una cosa semplice da implementare e mantenere.

Wcf ha una curva di apprendimento elevata, ma una volta passato, Wcf diventa davvero semplice per la maggior parte degli usi, specialmente se si sta contenendo la creazione del proxy del client in modo significativo.

Esito a offrire questo come risposta, poiché non è esattamente obiettivo. Ma la mia esperienza personale è che ogni volta che sono stato coinvolto in un progetto che utilizzava WCF, ce ne siamo pentiti.

Se stai implementando qualcosa che faccia realmente uso della flessibilità di WCF (ad esempio una SOA a cui è necessario accedere tramite HTTP / SOAP sul web e anche tramite TCP su una intranet), allora con tutti i mezzi, vai con WCF. Ma se stai facendo qualcosa che può essere implementato in un altro modo - e qualcosa di semplice come i gestori per restituire le risposte JSON alle query AJAX certamente - non sceglierei WCF. C'è solo troppa complessità là fuori che non avrai alcun bisogno, ma offrirà tutti opportunità per i problemi.

In risposta alla prima parte della tua domanda, sono d'accordo con la valutazione del tuo collega che l'emissione di JSON sarebbe molto più efficiente e amp; semplice da fare. (Principio KISS)

Prima di andare avanti con WCF, ti consiglio vivamente di considerare l'eccellente stack di servizio - un opensource .NET e amp; Mono framework di servizi web REST.

Le prestazioni sono eccellenti (come evidenziato dai benchmark di supporto) e l'esperienza degli sviluppatori (per me personalmente) è molto meglio che lavorare con WCF.

Il tuo collega deve capire cos'è WCF. Una volta che tutto è configurato correttamente, WCF può essere molto potente. Abbiamo recentemente creato un servizio RESTful su WCF e siamo molto contenti del risultato.

Ecco la definizione Microsoft di WCF:

Windows Communication Foundation (WCF) is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments.

Poche cose WCF fa meglio di una pagina ASP.NET standard (o servizio):

Sviluppo del servizio

In un ASP.NET devi collegare tutto tu stesso. Con WCF si aggiungono alcuni attributi come [ServiceContact] e [OperationContract] . Dopo averlo fatto, puoi associare un indirizzo e un'associazione con un tipo di servizio.

Includono BasicHttpBinding (supportando WS-BasicProfile 1.1 e Basic Security Profile 1.0), WSHttpBinding , WSDualHttpBinding , WSFederationBinding , NetTcpBinding , NetNamedPipeBinding , NetMsmqBinding , MsmqIntegrationBinding e amp ; %codice%. Tutto quello che devi fare è cambiare la configurazione. WCF fa il resto.

Hosting

La pagina ASP.NET o il servizio web in genere è ospitato in un sito Web in IIS. WCF consente di ospitare il servizio in ISS ma anche come applicazione autonoma o qualsiasi host compatibile. Di nuovo, senza dover cambiare nulla tranne la configurazione.

Rappresentazione del messaggio

WCF offre funzionalità molto più avanzate, incluso il modo in cui aggiungi l'intestazione nei messaggi.

<service name="Service ">
 <endpoint 
  address="EchoService"
  binding="basicHttpBinding"
  contract="IEchoService ">
  <headers>
  <dsig:X509Certificate 
   xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
   ...
  </dsig:X509Certificate>
  </headers>
 </endpoint>

... e molto altro

WCF ti aiuterà anche con:

• Rappresentazione dei dati
• Descrizione del servizio
• Gestione delle eccezioni
• Gestione dello stato
• La globalizzazione
• e, naturalmente, una delle sue funzioni principali, Sicurezza .

Penso che il meglio che puoi fare adesso sia metterti alla prova. Puoi essere stupito o disgustato. Ma in ogni caso, saprai se WCF è per te o meno.

Ulteriori letture: Confronto tra i servizi Web ASP.NET e WCF in base allo sviluppo

Bene, ho deciso di non usare WCF, se fosse possibile trovare un'alternativa. Ecco i motivi:

1. Difficile da sviluppare (ragazzi della curva di apprendimento, sviluppatori di base e media)
2. Configurazione disordinata (tutti quei binding, endpoint, ecc.)
3. Il client conosce i tipi di dati del server (attributi del contratto)
4. SOAP non è così pratico come JSON (leggibilità per gli sviluppatori)
5. SOAP è MUCH più dettagliato di JSON
6. URL scortesi, che non possono essere richiamati direttamente dal browser (buste SOAP)
7. WctTestClient fa schifo, perché non ha un semplice ordinamento alfabetico per le funzioni
8. Devi soffrire per renderlo RESTful
9. I tuoi modelli non sono POCO, a causa degli attributi [DataContract], [DataMember], ecc.
10. Nessun overload di metodi (che alcuni considerano una forma di polimorfismo)

Personalmente ho l'esperienza di lavorare con WCF in due progetti di medie dimensioni, e in entrambi vorrei poter essere il decisore in modo che potessi decidere di usare qualcos'altro.