Domanda

Sono un po' confuso riguardo ADO.Net Data Services.

È pensato solo per la creazione di servizi Web RESTful?So che WCF è iniziato nel mondo SOAP ma ora ho sentito che ha un buon supporto per REST.Lo stesso vale per i servizi dati ADO.Net dove puoi farlo funzionare in un modello RPC se non puoi guardare tutto da una vista orientata alle risorse.

Almeno dalle demo che ho visto di recente, sembra che ADO.Net Data Services sia basato sullo stack WCF sul server.Perfavore, correggimi se sbaglio.

Non ho intenzione di avviare un dibattito REST vs SOAP, ma immagino che le cose non siano più così chiare.

Qualche suggerimento o linea guida su cosa usare e dove?

È stato utile?

Soluzione

A mio avviso, i servizi dati ADO.Net servono per creare servizi riposanti che sono strettamente allineati con il modello di dominio, ovvero i modelli stessi vengono pubblicati anziché dire una qualche forma di DTO ecc.

Usarlo per servizi in stile RPC sembra una cattiva soluzione, anche se sfortunatamente anche alcune funzionalità di base come la possibilità di eseguire conteggi filtrati, ecc.non sono disponibili, il che spesso significa che finirai per utilizzare alcuni RPC solo per soddisfare le esigenze dei tuoi clienti, ad es.in modo da poter visualizzare una griglia paginata, ecc.

WCF 3.5 pre-SP1 era una piattaforma RESTful abbastanza debole, con SP1 le cose sono migliorate in entrambi i modelli Uri e con la disponibilità del supporto ATOMPub, in modo tale che sta diventando più capace, ma in realtà non forniscono alcuna soluzione elegante per supportare, ad esempio, JSON , XML, ATOM o anche qualcosa di più esoterico come payload come CSV contemporaneamente, a meno di dover utilizzare la riscrittura dell'URL e estensioni diverse, munging del nome del metodo ecc.- piuttosto che selezionare semplicemente un serializzatore/deserializzatore in base alle intestazioni della richiesta.

Con WCF è ancora difficile creare servizi che funzionino in modo più naturale e riposante, ad es.dove le risorse includono URL e puoi passare allo stato navigando attraverso di esse - è un po' goffo - i servizi dati ADO.Net lo fanno abbastanza bene con il suo supporto AtomPub.

Il mio consiglio sarebbe di utilizzare i servizi Web laddove sono naturalmente servizi e vengono applicati forti limiti di servizio, utilizzare i servizi dati ADO.Net per rich client in stile Web (siti Web, ajax, silverlight) in cui la componibilità delle query URL può salvare un molti impianti idraulici e il tuo modello di dominio è piuttosto semplice...e implementa il tuo livello REST (magari utilizzando un framework MVC come punto di partenza) se hai bisogno del controllo completo sulle informazioni, ad es.se stai pubblicando un'API affinché altri sviluppatori possano utilizzarla su una piattaforma social, ecc.

Il mio valore di 2ø!

Altri suggerimenti

L'uso dell'associazione rest di WCF è molto valido quando si lavora con codice che non interagisce affatto con un database.I verbi HTTP non devono sempre andare contro un fornitore di dati.

In realtà, ci sono opzioni per filtrare e saltare per ottenere, tra le altre, la funzionalità simile alla pagina.

Vedere qui:

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