Come scegliere tra i servizi WCF, REST, POX e RIA per una nuova applicazione Silverlight

Question

C'è un lotto di diversi modi in cui un'applicazione Silverlight può collegarsi ad esso 'server. Compreso

• WCF - Windows Communication Foundation
• REST (vedi also)
• ADO.NET Data Services (o si tratta semplicemente riposare?)
• POX - Plain Old XML (per esempio, XML di base)
• RIA services

Per ognuno di questi, per favore, dì a cosa serve e quando vorresti o non vorresti si. Non sto cercando un grande livello di dettagli solo una serie di "regole pratiche" per scegliere tra di loro.

(il problema è quando si progetta la vostra prima applicazione Silverlight sapere cosa utilizzare quando non si ha tempo per imparare tutti loro.)

Se mi è stato di sostituire Silverlight con WPF in questa domanda che effetto avrebbe sulle tue risposte? (Io parto dal presupposto con WPF che a causa di firewall e le politiche di amministrazione un Direct Connect al database non è un'opzione.)

Answer 1

I miei due (euro) centesimi:

WCF sembra più adatto quando il servizio può essere visualizzato come il livello aziendale dell'applicazione, ovvero quando il servizio ha operazioni "intelligenti" come "CalculateDiscountForClient".

Servizi dati ADO.NET (in effetti, solo un'implementazione REST) ​​sembra appropriato quando l'applicazione è fondamentalmente incentrata sui dati e il servizio è semplicemente un front-end per il database. Cioè, tutti i metodi di servizio sono di tipo GetCustomers, CreateInvoice, ecc

servizi RIA è una nuova tecnologia che non ho sperimentato ancora, ma sembra essere utile per creare applicazioni in che la parte Silverlight e il servizio sono strettamente accoppiati: si definiscono le classi e i metodi del servizio nel progetto di servizio e vengono automaticamente replicati nel progetto Silverlight in fase di progettazione. Inoltre, è possibile definire entrambi i metodi "azione" in stile WCF e i metodi "dati" in stile Data Services di ADO.NET. Sembra promettente.

Utilizzare POX se è possibile cambiare la parte client da Silverlight a qualsiasi altra tecnologia (ad esempio HTML + AJAX) in futuro, poiché è l'opzione più interoperabile.

Le differenze per WPF, l'unica a cui riesco a pensare, è che per l'accesso ai dati, quando possibile, utilizzerei connessioni dati ADO.NET dirette (correttamente incorporate in un livello di accesso ai dati, da LINQ a SQL o simili) invece di ADO.NET Data Services, poiché è molto più flessibile. Devo dire comunque che non ho mai sviluppato nulla in WPF.

Answer 2

Penso che non andrei mai più al POX. Se si scrive WCF in modo che il servizio stesso sia indipendente dall'associazione e il binding venga eseguito nei file di configurazione, WCF è praticamente indipendente dal trasporto e dal protocollo.Può eseguire SOAP, JSON, REST o una propria forma di serializzazione binaria. Tutto ciò è nel legame. Internamente, WCF specifica solo ciò che viene esposto in termini di contratti operativi e di dati (tutti definiti per classe, metodo e attributi di proprietà). WCF offre un'enorme flessibilità in questo senso, con ulteriori novità nel 2010.

Dal lato Silverlight, WCF richiede che si scriva un codice idraulico. .NET frameowrk dispone degli strumenti per creare il proxy nel progetto Silverlight, ma è necessario essere pronti a gestire tutte le risposte WCF in modo asincrono e il proxy non può rilevare le eccezioni generate dal servizio.

.NET RIA Services nasconde tutto questo. Usa WCF sotto le coperte, ma è completamente nascosto. Non è necessario scrivere codice asincrono. Si definisce la convalida una volta, per lo più in modo dichiarativo, e funziona sia sul lato server che sul lato client. La versione 1 verrà scelta come target per Silverlight, quindi non avrai la versatilità per utilizzare il servizio altrove. Tale ambito dovrebbe essere ampliato nelle versioni successive.

Non so abbastanza su ADO.NET Data Services da confrontare. Sospetto che la risposta dipenda dal fatto che tu voglia esporre i tuoi dati a qualcosa di più del semplice utilizzo di Silverlight.

Servizi RIA di .NET sembra la direzione che vorrei andare (osservando questi problemi io stesso, con una grande domanda in mente). I grandi problemi per me saranno l'implementazione di una vasta gamma di funzionalità nel livello di servizio, e non la possibilità di codificare direttamente al livello di accesso ai dati (dobbiamo essere in grado di eseguire su SQL Server o Oracle).

L'utilizzo di WPF invece di Silverlight cambia tutto, a seconda di dove risiedono i dati. È come la vecchia domanda di Winforms contro ASP.NET. Con WPF, stai creando un'app client Windows e non è necessario utilizzare alcuna forma di interfaccia dati basata sui servizi, a meno che l'accesso ai dati non ti costringa a farlo. Continuerete comunque a separare dati e attività dal codice di presentazione, utilizzando MVVM, MVC o MVP. Oltre a questo, hai la possibilità di trattare l'accesso ai dati come un livello, piuttosto che un wholy indipendente.

Answer 3

Utilizziamo RIA, e questa è l'unica opzione che conosco, ma io lo so, quindi ecco alcuni dei miei pensieri.

RIA non è ancora finito. Si sta lavorando. Se hai intenzione di finire presto, e sei preoccupato di dover supportare qualcosa che ha un potenziale per cambiare un bel po ', allora potresti prendere in considerazione altre opzioni. Se questo è un nuovo progetto, e lo sosterrai per un lungo periodo, RIA sarà probabilmente più facile da usare.

Detto questo, penso che non ci saranno molti cambiamenti nel modo in cui funziona l'Anteprima di luglio di RIA e il modo in cui funzionerà una versione finale. Anche il livello di supporto sembra suggerire che questo diventerà "The Way" per parlare con un server in Silverlight.

giusta causa vale la pena ricordare, hanno alcuni link:

http://blogs.msdn.com/brada/ Brad Abrams ha un esempio che sta continuamente aggiornando.

http://forums.silverlight.net/forums/53.aspx questo è dove si va a fare domande.

http://www.riaservicesblog.com/Blog/ Colin Blair conosce le sue cose e lui è molto utile.

Answer 4

WCF è lo standard Microsoft per la comunicazione di servizio. Consiglio vivamente chiunque di creare un livello di servizio utilizzando le API Web WCF (utilizza WCF, ma adattato specificamente per REST), che uscirà in aprile 2012. Le API Web WCF sono attualmente in modalità di anteprima.

Ricordate queste regole pratiche: - l'interfaccia utente cambia più velocemente del tuo livello di servizio. I servizi RESTful saranno in giro in diversi anni, Silverlight probabilmente non sarà - i tuoi servizi saranno mai API? Bene ... WCF REST è la strada da percorrere - mescolerai codice JavaScript e Silverlight? WCF REST ti renderà la vita più facile - Avrai un componente mobile (dal momento che Silverlight non funziona su iOS o Android) ... REST è preferito.

Non adattarsi alla tecnologia, ma all'app nel suo complesso.

Answer 5

Se si desidera creare un'applicazione Silverlight e non si cura di altri clienti, quindi vorrei scegliere RIA Services. È abbastanza semplice da usare e non è necessario preoccuparsi di come viene effettuata la connessione dal client (cioè nessuna configurazione lato client necessaria). RIA genera anche classi per tutte le tue entità sul client e puoi anche condividere il tuo codice "server" con il client se necessario (utile per enumerazioni o metodi di estensione).

Osservazione:

• ho mai provato questo, ma se si ha realmente bisogno è possibile accedere al Servizio RIA anche con altri client, dopo tutto RIA servizi sono costruiti sulla cima di servizi WCF.
• Non capisco i problemi di sicurezza di Akash Kava. Puoi (e devi) controllare la sicurezza sul lato server come faresti con qualsiasi altro servizio.