WCF alza il livello o solo il livello di complessità? [chiuso]

Comprendo il valore del modello servizio / host / client in tre parti offerto da WCF. Ma sono solo io o sembra che WCF abbia preso qualcosa di abbastanza 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 è stato fornito automaticamente un test harness; esiste una buona alternativa oggi con WCF?

Apprezzo che la roba di WS * sia più strettamente integrata con WCF e spero di trovare qualche ricompensa per WCF lì, ma geeze, altrimenti sono perplesso.

Inoltre, lo stato dei libri disponibili per WCF è al massimo terribile. Juval Lowy, un autore eccezionale, ha scritto un buon libro di riferimento O'Reilly "Programming WCF Services" ma non fa molto (per me comunque) per imparare a usare WCF ora. Il precursore di quel libro (e un po 'meglio organizzato, ma non molto, come tutorial) è Learning WCF di Michele Leroux Bustamante. Ha buoni punti ma è obsoleto e il suo sito Web corrispondente è scomparso.

Hai buoni riferimenti per l'apprendimento WCF oltre a continuare a Google il bejebus fuori dalle cose?

Va bene, eccoci qui. Innanzitutto, il libro di Michele Leroux Bustamante è stato aggiornato per VS2008. Il sito web del libro non è andato. Al momento è disponibile e contiene tantissime informazioni su WCF. Su quel sito web fornisce un codice aggiornato compatibile con VS2008 per tutti gli esempi nel suo libro. Se ordini da Amazon, riceverai la ristampa che viene aggiornata.

WCF non è solo un sostituto per ASMX. Sicuramente può (e 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 è stata integrata dall'inizio. Il framework è altamente configurabile e la capacità di servire più endpoint su più protocolli è sorprendente, IMO.

Sebbene sia ancora possibile generare classi proxy dall'opzione "Aggiungi riferimento al servizio", non è necessario. Tutto quello che devi fare è copiare la tua interfaccia ServiceContract e dire al tuo codice dove trovare l'endpoint per il servizio, e il gioco è fatto. È possibile 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 utilizza entrambi nella sua eccellente serie di webcast sull'argomento.

Michele ha un sacco di ottimo materiale là fuori e ti consiglio di controllare i suoi siti web. Ecco alcuni collegamenti che sono stati incredibilmente utili per me mentre stavo imparando WCF. Spero che ti renderai conto di quanto sia davvero forte WCF e quanto sia facile da implementare. La curva di apprendimento è un po 'ripida, ma i premi per il tuo investimento di tempo ne valgono la pena:

• I webcast di Michele: http://www.dasblonde.net/2007/06/24/WCFWebcastSeries.aspx
• Sito web del libro di Michele (vivo e aggiornato per VS2008): http://www.thatindigogirl.com/

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

Di solito utilizzo Google per trovare le mie risposte WCF e di solito mi trovo sui seguenti blog:

Blog con preziosi articoli WCF

• http://blogs.msdn.com/drnick/default.aspx
• http://blogs.msdn.com/wenlong/default.aspx
• http://blogs.thinktecture.com/buddhike/
• http://www.dasblonde.net/default.aspx

Altri articoli preziosi che ho trovato

• http://blogs.conchango.com/pauloreichert/archive/2007/02/22/WCF-Reliable-Sessions-Puzzle.aspx
• http://blogs.msdn.com/salvapatuel/archive/2007/04/25/why-using-is-bad-for-your-wcf-service-host.aspx

Ho difficoltà a vedere quando dovrei o vorrei usare WCF. Perché? Perché metto produttività e semplicità in cima alla mia lista. Perché il modello ASMX ha avuto così tanto successo, perché ha funzionato e lo fai funzionare velocemente. E con VS 2005 e .NET 2.0 wsdl.exe emetteva servizi piuttosto carini e conformi.

Nella vita reale dovresti avere pochissimi protocolli di comunicazione nella tua architettura. Ciò lo rende semplice e mantenibile. Se hai bisogno di accedere a sistemi legacy, scrivi adattatori specifici per loro in modo che possano giocare insieme nel bel mondo SOA 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 sua comunicazione (concesso, HTTP è ancora il modo in cui la maggior parte delle persone lo utilizzerà, almeno per i servizi che devono essere interoperabili). WCF è anche più facile da estendere. Almeno, è possibile estenderlo in modi che ASMX non può essere esteso. "Facile" potrebbe allungarlo. =)

La funzionalità aggiunta offerta da WCF supera di gran lunga la complessità che aggiunge, a mio parere. Penso anche che il modello di programmazione sia più semplice. I DataContracts sono molto più belli che dover serializzare utilizzando la serializzazione XML con proprietà pubbliche per tutto, ad esempio. È anche di natura molto più dichiarativa, il che è anche bello.

Aspetta .... hai mai usato .NET Remoting, perché è quello che sta realmente sostituendo. .NET Remoting è piuttosto complicato in sé. Trovo WCF più facile e meglio strutturato.

Non lo vedo menzionato abbastanza spesso, ma puoi comunque implementare 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 è così male.

L'eliminazione della verbosità dei contratti separati di 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, named pipe o trasporti MSMQ.

Confesso che ho altri problemi con WCF (es. Riscrittura delle firme del metodo quando espongo un servizio su basicHTTP - vedi qui , ma nel complesso penso che sia un netto miglioramento

Se stai usando VS2008 e crei un progetto WCF, ottieni automaticamente un test harness quando premi run / debug e puoi aggiungere un riferimento senza dover usare svcutil.

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

1. Programma il tuo livello proxy / client utilizzando generici (vedi classi ClientBase , Binding). L'ho trovato facile da lavorare, ma difficile da perfezionare.
2. Utilizza un'implementazione di terze parti di 1 ( SoftwareIsHardwork è il mio preferito attualmente)

WCF sostituisce tutte le tecnologie di servizi Web precedenti di Microsoft. Fa anche molto di più di ciò che viene tradizionalmente considerato come "servizi web".

I "servizi web" WCF fanno parte di uno spettro molto più ampio di comunicazioni remote abilitate tramite WCF. Otterrai un grado 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 distribuite offerte da Microsoft. Un endpoint in WCF può essere comunicato con la stessa facilità su SOAP / XML come può su TCP / binario e per cambiare questo mezzo è semplicemente un file di configurazione mod. In teoria, questo riduce la quantità di nuovo codice necessario durante il porting 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 molti modi e quindi è ora raggruppato sotto l'ombrello delle capacità WCF.

È possibile accedere ai servizi Web solo tramite HTTP e funziona in ambienti 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, Managed Windows Service.

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

In quali scenari deve essere utilizzato WCF

• Un servizio sicuro per elaborare le transazioni commerciali. Un servizio che
• fornisce dati correnti ad altri, come un bollettino sul traffico o altro
• servizio di monitoraggio. Un servizio di chat che consente a due persone di
• comunicare o scambiare dati in tempo reale. Un'applicazione dashboard
• che esegue il polling di uno o più servizi per i dati e li presenta in una logica
• presentazione. Esporre un flusso di lavoro implementato utilizzando il flusso di lavoro di Windows
• Foundation come servizio WCF. Un'applicazione Silverlight per eseguire il polling di un file
• servizio per gli ultimi feed di dati.

Caratteristiche di WCF

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

fonte: principale fonte di testo

MSDN? Di solito mi trovo abbastanza bene con il riferimento alla Libreria stessa e di solito mi aspetto di trovare articoli preziosi lì.

In termini di ciò che offre, penso che la risposta sia la compatibilità. I servizi ASMX erano piuttosto Microsofty. Per non dire che non cercavano di essere compatibili con altri consumatori; ma il modello non è stato fatto per adattarsi molto oltre alle pagine Web ASP.NET e ad altri utenti Microsoft personalizzati. Mentre WCF, a causa della sua architettura, consente al servizio di avere endpoint basati su standard molto aperti, ad esempio REST, JSON, ecc. Oltre al solito SOAP. Altre persone avranno probabilmente un tempo molto più semplice consumare il tuo servizio WCF rispetto a quello ASMX.

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

WCF non dovrebbe essere considerato come 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 promuova davvero l'implementazione dei servizi Web ASMX in molti modi. Prima di tutto fornisce un modello a oggetti stratificato molto carino che aiuta a nascondere la complessità intrinseca delle applicazioni distribuite. In secondo luogo puoi avere più di modelli di messaggistica richiesta-replay, incluse notifiche asincrone da server a client (impossibile con HTTP puro), e in terzo luogo astrarre il protocollo di trasporto sottostante dalla messaggistica XML e quindi supportare elegantemente HTTP, HTTPS, TCP e altri. Anche la retrocompatibilità con i servizi web di "prima generazione" è un vantaggio. WCF utilizza lo standard XML come formato di rappresentazione interna. Questo potrebbe essere percepito come un vantaggio o uno svantaggio, soprattutto con la crescente popolarità di "alternative senza grassi all'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 di errore non così belle.

Sarebbe bello se qualcuno avesse scorciatoie o suggerimenti per quelli.

Trovo che sia un dolore; in quanto ho .NET a entrambe le estremità, ho le stesse DLL "contratto" caricate su entrambe le estremità, ecc. Ma poi devo fare casino con molti dettagli come gli attributi "KnownType".

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

.NET remoting tendeva a funzionare la maggior parte del tempo.

Penso che cercare di fingere che le comunicazioni basate su oggetti da .NET a .NET equivalgano a inviare bit di testo (xml) a un sistema sconosciuto, sia stato un passo troppo lontano.

(Le poche volte che abbiamo usato WCF per parlare con un sistema Java, abbiamo scoperto che l'XSD fornito dal sistema Java non corrispondeva comunque all'XML che voleva, quindi abbiamo dovuto codificare a mano molte delle mappature XML.)