WCF alza il livello o solo il livello di complessità?

StackOverflow https://stackoverflow.com/questions/50114

  •  09-06-2019
  •  | 
  •  

Domanda

Comprendo il valore del modello in tre parti servizio/host/client offerto da WCF.Ma sono solo io o sembra che WCF abbia preso qualcosa di piuttosto diretto e diretto (il modello ASMX) e ne abbia fatto un pasticcio?

Esiste un'alternativa all'utilizzo della riga di comando di SvcUtil per tornare indietro nel tempo per generare il proxy?Con i servizi ASMX veniva fornito automaticamente un cablaggio di prova;esiste una buona alternativa oggi con WCF?

Apprezzo che il materiale WS* sia più strettamente integrato con WCF e spero di trovare qualche profitto per WCF lì, ma cavolo, altrimenti sono perplesso.

Inoltre, lo stato dei libri disponibili per WCF è nella migliore delle ipotesi spaventoso.Juval Lowy, un autore eccezionale, ha scritto un buon libro di riferimento di O'Reilly "Programmazione dei servizi WCF" ma non fa molto (almeno per me) per imparare ora a usare WCF.Il precursore di quel libro (e un po' meglio organizzato, ma non molto, come tutorial) è Learning WCF di Michele Leroux Bustamante.Ha buoni spot ma è obsoleto e il suo sito Web corrispondente non c'è più.

Hai buoni riferimenti per l'apprendimento WCF oltre a continuare a cercare su Google il bejebus per scoprire le cose?

È stato utile?

Soluzione

Ok, eccoci qui.Innanzitutto, il libro di Michele Leroux Bustamante è stato aggiornato per VS2008.Il sito web del libro non è scomparso.È disponibile proprio adesso e contiene tantissime fantastiche informazioni sulla WCF.Su quel sito fornisce il codice aggiornato compatibile con VS2008 per tutti gli esempi nel suo libro.Se ordini da Amazon, riceverai la ristampa aggiornata.

La WCF no soltanto un sostituto per ASMX.Sicuramente può (e lo fa abbastanza bene) sostituire ASMX, ma il vero vantaggio è che consente ai tuoi servizi di essere ospitati autonomamente.La maggior parte delle funzionalità di WSE sono state integrate fin dall'inizio.Il quadro è altamente configurabile e la capacità di servire più endpoint su più protocolli è sorprendente, IMO.

Anche se puoi comunque generare classi proxy dall'opzione "Aggiungi riferimento al servizio", non è necessario.Tutto quello che devi fare è copiare la tua interfaccia ServiceContract e indicare al tuo codice dove trovare l'endpoint per il servizio, e il gioco è fatto.Puoi chiamare metodi dal servizio con pochissimo codice.Utilizzando questo metodo, hai il controllo completo sull'implementazione.Indipendentemente dal metodo scelto per generare una classe proxy, Michele mostra entrambi e li utilizza entrambi in lei eccellente serie di webcast sull'argomento.

Michele ha un sacco di ottimo materiale là fuori e ti consiglio di dare un'occhiata ai suoi siti web.Ecco alcuni collegamenti che mi sono stati incredibilmente utili mentre stavo imparando WCF.Spero che capirai quanto sia forte la WCF e quanto sia facile da implementare.La curva di apprendimento è un po’ ripida, ma ne vale la pena:

Ti consiglio di guardare almeno 1 dei webcast di Michele.È una presentatrice molto efficace ed è ovviamente incredibilmente ben informata quando si tratta di WCF.Fa un ottimo lavoro nel demistificare il funzionamento interno della WCF da zero.

Altri suggerimenti

Ho difficoltà a capire quando dovrei o vorrei utilizzare WCF.Perché?Perché metto la produttività e la semplicità in cima alla mia lista.Perché il modello ASMX ha avuto così tanto successo? Perché ha funzionato e puoi farlo funzionare velocemente.E con VS 2005 e .NET 2.0 wsdl.exe offriva servizi piuttosto carini e conformi.

Nella vita reale dovresti avere pochissimi protocolli di comunicazione nella tua architettura.Ciò lo mantiene semplice e mantenibile.Se hai bisogno di accedere a sistemi legacy, scrivi adattatori specifici per loro in modo che possano giocare nel mondo SOA bello, brillante e bello.

WCF è molto più potente di ASMX e lo estende in diversi modi.ASMX è limitato al solo HTTP, mentre WCF può utilizzare diversi protocolli per la comunicazione (garantito, HTTP è ancora il modo in cui la maggior parte delle persone lo utilizzerà, almeno per i servizi che devono essere interoperabili).WCF è anche più semplice da estendere.Almeno è possibile estenderlo in modi in cui ASMX non può essere esteso."Facile" potrebbe essere esagerato.=)

A mio avviso, le funzionalità aggiuntive offerte da WCF superano di gran lunga la complessità che aggiunge.Sento anche che il modello di programmazione è più semplice.I DataContract sono molto più utili che dover serializzare utilizzando la serializzazione XML con proprietà pubbliche per tutto, ad esempio.È anche molto più dichiarativo in natura, il che è anche carino.

Aspettare....hai mai usato .NET Remoting, perché è la cosa vera che sta sostituendo..NET Remoting è di per sé piuttosto complicato.Trovo che WCF sia più semplice e meglio strutturato.

Non lo vedo menzionato abbastanza spesso, ma tu Potere implementa ancora servizi abbastanza semplici con WCF, molto simili ai servizi ASMX.Per esempio:

[ServiceContract]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class SimpleService
{
    [OperationContract]
    public string HelloWorld()
    {
        return "Hello World";
    }

}

Devi ancora registrare il punto finale nel tuo web.config, ma non è poi così male.

L'eliminazione della verbosità dei contratti separati per dati, servizi e operazioni contribuisce notevolmente a rendere WCF più gestibile per me.

VS2008 include la voce del menu contestuale "Aggiungi riferimento al servizio" che creerà il proxy per te dietro le quinte.

Come accennato in precedenza, WCF non è inteso esclusivamente come sostituto dei tipi di servizi Web ASMX, ma per fornire una metodologia coerente, sicura e scalabile per tutti i servizi interoperabili, sia che si tratti di HTTP, tcp, pipe denominate o trasporti MSMQ.

Confesserò che ho altri problemi con WCF (ad es.riscrivere le firme dei metodi quando si espone un servizio su basicHTTP - vedere Qui, ma nel complesso penso che sia un netto miglioramento

Se stai utilizzando VS2008 e crei un progetto WCF, ottieni automaticamente un test cablaggio quando premi Esegui/debug e puoi aggiungere un riferimento senza dover utilizzare svcutil.

I miei pensieri iniziali sulla WCF erano esattamente gli stessi!Ecco alcune soluzioni:

  1. Programma il tuo livello proxy/client utilizzando i generici (vedi classi Base di clienti, Legame).L'ho trovato facile da far funzionare, ma difficile da perfezionare.
  2. Utilizzare un'implementazione di terze parti di 1 (Il software è un duro lavoro è il mio preferito al momento)

WCF è un sostituto per tutti i precedenti servizio web tecnologie di Microsoft.Fa anche molto di più di quelli che tradizionalmente vengono considerati "servizi web".

I "servizi Web" WCF fanno parte di uno spettro molto più ampio di comunicazioni remote abilitate tramite WCF.Otterrai un livello molto più elevato di flessibilità e portabilità facendo le cose in WCF rispetto al tradizionale ASMX perché WCF è progettato, da zero, per riassumere tutte le diverse infrastrutture di programmazione distribuita offerte da Microsoft.È possibile comunicare con un endpoint in WCF con la stessa facilità tramite SOAP/XML così come tramite TCP/binario e per modificare questo mezzo è semplicemente un file di configurazione mod.In teoria, ciò riduce la quantità di nuovo codice necessario durante il trasferimento o la modifica delle esigenze aziendali, degli obiettivi, ecc.

ASMX is older than WCF, and anything ASMX can do so can WCF (and more).Fondamentalmente puoi vedere WCF come un tentativo di raggruppare logicamente tutti i diversi modi per far comunicare due app nel mondo di Microsoft;ASMX era solo uno di questi tanti modi e quindi è ora raggruppato sotto l'ombrello delle funzionalità WCF.

È possibile accedere ai servizi Web solo tramite HTTP e funziona in un ambiente senza stato, dove WCF è flessibile perché i suoi servizi possono essere ospitati in diversi tipi di applicazioni.Gli scenari comuni per l'hosting dei servizi WCF sono IIS, WAS, self-hosting e servizio Windows gestito.

La differenza principale è che i servizi Web utilizzano XmlSerializer.Ma WCF utilizza DataContractSerializer che è migliore in termini di prestazioni rispetto a XmlSerializer.

In quali scenari è necessario utilizzare WCF

  • Un servizio sicuro per elaborare le transazioni commerciali.Un servizio che
  • fornisce dati attuali ad altri, come un bollettino sul traffico o altro
  • servizio di monitoraggio.Un servizio di chat che consente a due persone di farlo
  • comunicare o scambiare dati in tempo reale.Un'applicazione dashboard
  • che interroga uno o più servizi per i dati e li presenta in modo logico
  • presentazione.Esposizione di un flusso di lavoro implementato utilizzando Windows Workflow
  • Fondazione come servizio della WCF.Un'applicazione Silverlight per eseguire il polling a
  • servizio per i feed di dati più recenti.

Caratteristiche del WCF

  • Orientamento al servizio
  • Interoperabilità
  • Modelli di messaggi multipli
  • Metadati del servizio
  • Contratti dati
  • Sicurezza
  • Trasporti multipli e codifiche
  • Messaggi affidabili e in coda
  • Messaggi durevoli
  • Transazioni
  • Supporto AJAX e REST
  • Estensibilità

fonte: principale fonte di testo

MSDN?Di solito me la cavo piuttosto bene con il riferimento alla Biblioteca stessa e di solito mi aspetto di trovare lì articoli preziosi.

In termini di ciò che offre, penso che la risposta sia la compatibilità.I servizi ASMX erano piuttosto Microsofty.Per non dire che non hanno cercato di essere compatibili con altri consumatori;ma il modello non è stato creato per adattarsi molto oltre alle pagine Web ASP.NET e ad altri consumatori Microsoft personalizzati.Considerando che WCF, grazie alla sua architettura, consente al tuo servizio di avere endpoint basati su standard molto aperti, ad es.RESTO, JSON, ecc.oltre al solito SAPONE.Altre persone probabilmente si divertiranno molto più facilmente a consumare il tuo servizio WCF rispetto a quello ASMX.

(Tutto questo è sostanzialmente dedotto dalla lettura comparativa di MSDN, quindi qualcuno che ne sa di più dovrebbe sentirsi libero di correggermi.)

WCF non dovrebbe essere considerato un sostituto di ASMX.A giudicare da come è posizionato e da come viene utilizzato internamente da Microsoft, è davvero un pezzo di architettura fondamentale che viene utilizzato per qualsiasi tipo di comunicazione transfrontaliera.

Credo che WCF faccia davvero avanzare l'implementazione dei servizi Web ASMX in molti modi.Innanzitutto fornisce un modello a oggetti a livelli molto gradevole che aiuta a nascondere la complessità intrinseca delle applicazioni distribuite.In secondo luogo è possibile avere più che modelli di messaggistica di richiesta-riproduzione, incluse notifiche asincrone da server a client (impossibili con HTTP puro) e in terzo luogo astraendo il protocollo di trasporto sottostante dalla messaggistica XML e supportando così elegantemente HTTP, HTTPS, TCP e altro.Anche la retrocompatibilità con i servizi Web di "1a generazione" è un vantaggio.WCF utilizza lo standard XML come formato di rappresentazione interna.Ciò potrebbe essere percepito come un vantaggio o uno svantaggio, soprattutto con la crescente popolarità delle "alternative senza grassi a XML" come JSON.

Le cose difficili che trovo con WCF sono la gestione delle configurazioni per client e server e la risoluzione dei problemi delle eccezioni di stato errate non così piacevoli.

Sarebbe fantastico se qualcuno avesse qualche scorciatoia o suggerimento per questi.

Trovo che sia una seccatura;in quanto ho .NET su entrambe le estremità, ho le stesse DLL "contratto" caricate su entrambe le estremità, ecc.Ma poi devo scherzare con molti dettagli come gli attributi "KnownType".

Per impostazione predefinita, WCF consente inoltre solo a 1 o 2 client di connettersi a un servizio finché non si modificano molte configurazioni.Cambiare la configurazione dal codice non è facile, spedire molti file comfig non è un'opzione, poiché è troppo difficile unire le nostre modifiche a qualsiasi modifica che un cliente potrebbe aver apportato al momento di un aggiornamento (inoltre non vogliamo che i clienti giocando con le impostazioni WCF!)

La comunicazione remota .NET tendeva a funzionare per la maggior parte del tempo.

Penso di provarci fare finta che le comunicazioni basate su oggetti da .NET a .NET equivalessero a inviare bit di testo (xml) a un sistema sconosciuto, era un passo troppo lontano.

(Le poche volte che abbiamo utilizzato WCF per comunicare con un sistema Java, abbiamo scoperto che l'XSD fornito dal sistema Java non corrispondeva comunque all'XML desiderato, quindi abbiamo dovuto codificare manualmente molti dei mapping XML.)

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top