Mi dite un po' le differenze su WCF RIA Services e WCF Data Services?

Ciao. WFC RIA Services ti permette di "creare un ponte" con un client web SilverLight e di traghettare lì una copia delle classi e della logica business che ne regolano il funzionamento. Questo serve a renderti più produttivo perchè in un'applicazione web tradizionale, per esempio, dovresti replicare una stessa logica di validazione sia in C# (VB.NET) che in javascript. Inoltre ti semplifica molto l'accesso ai dati perché vai ad interagire direttamente con le tue classi, quasi dimenticandoti che stai richiedendo dati ad un webservice.


WCF Data Services invece è eccellente per esporre una base di dati sul web. Si tratta di un servizio REST, quindi accessibile tramite banali richieste http GET, POST, ecc..., e funzionante secondo il protocollo ODATA. Qualunque client può consumarlo, anche non .NET, e questo mi sembra che accolga maggiormente la tua necessità di poter consumare i dati anche da Android ed iPhone.

La differenza tra i due è profonda: con RIA Services devi aver già sviluppato una base di dati e tutta la logica business. La parte server dell'applicazione ha l'ultima parola sui dati inviati dal client e può decidere se "lavorarli" o meno.

Un progetto WCF Data Services è agnostico della logica business, si limita semplicemente ad esporre dati e a persisterli quando li riceve dal client. Il client può, potenzialmente, inserire dati non validi come Citta: Roma, in provincia di: Milano. In realtà potresti mettere in piedi un minimo di validazione ma non è questo lo scopo principale di WCF Data Services. Sarebbe più indicato un servizio WCF tradizionale, a quel punto.
Proprio per la mancanza di logica business, io vedo WCF DataServices più indicato per la consultazione, che non per la scrittura dei dati. E' come un feed RSS su cui però puoi fare delle query.

Non mi è molto chiaro quali sono i requisiti della tua applicazione. Ad esempio, perché vuoi realizzare dei client Silverlight, WPF e mobile quando potresti realizzare una unica applicazione web accessibile da tutti i dispositivi (con opportuni accorgimenti, ovviamente)?

Su WP7, Android e iPhone, per esempio, devi poter accedere al gestionale anche in assenza di connettività? Se è così, anziché scaricarsi gli SDK per sviluppare su tutti e tre i telefoni io preferirei comunque sviluppare un'applicazione web e deployarla con PhoneGap. "Write once, run everywhere" è scritto sul loro sito.

ciao,

Quindi mi consigli di scrivere una solta sola il codice e creare un prodotto universale.

Io sì, ma questa è una mia opinione. Dato che esistono molti tipi di dispositivi mobile, sia nel formato che nel sistema operativo, tendo a prediligere la versatilità alle prestazioni.

Un'applicazione web non sarà mai fluida negli "effetti" come un'app in code nativo, ma è un difetto con cui posso convivere se penso che altrimenti dovrei mettermi a scrivere codice in objective c per iphone, in java per android e in c# per windows phone 7. Non ho sufficiente tempo (né l'intenzione) per diventare proficiente in tutti e 3 i linguaggi e quindi decido di aggrapparmi agli standard (html5 + css3) e sviluppare per il web.

Fortunatamente ci sono framework spettacolari, come Sencha Touch e jQuery mobile (ancora in beta) che ti consentono di avere una user experience molto ricca e certamente idonea all'utilizzo dell'interfaccia con le dita.
Nulla ti vieta di utilizzare questi framework anche per la versione desktop. Anzi, la "versione desktop" trattandosi di un gestionale potrebbe benissimo non esserci. Windows 7 supporta gli schermi touch quindi l'utilizzatore è libero di scegliere se usare le dita o il mouse.

Tutto questo vale fintanto che il dispositivo mobile è collegato alla rete. Trattandosi di un'applicazione web, è necessario che ci sia connettività perenne, altrimenti l'utente non potrà aprire le pagine.
Con un'app nativa, invece, questo problema non sussiste perché tutto il codice dell'applicazione è già installato sul dispositivo e il salvataggio dei dati può avvenire in locale per poi sincronizzarsi con il server quando c'è connettività.

Per colmare questo divario tra applicazione web e app nativa, si sono inventati PhoneGap che ti permette di impacchettare le pagine html della parte client e installarle sul dispositivo, in modo che siano disponibili anche offline. Il salvataggio locale dei dati lo puoi fare sfruttando le funzionalità di HTML5, come Local storage, oppure con la API File di PhoneGap.

E' richiesta una certa dimestichezza col javascript, non te lo nascondo, ma se il tuo intento è quello di portare il gestionale sul maggior numero di dispositivi possibili, allora sviluppare un'applicazione web è la soluzione che riduce il time-to-market in maniera importante. Per non parlare della manutenzione, che è estremamente più semplice se devi gestire una sola applicazione.

Sarà un problema che voglio restare con il .NET Framework e C#?

No, assolutamente, la parte lato server la puoi sviluppare in C#, magari sottoforma di servizio WCF "tradizionale" che le pagine html del client potranno consumare con delle chiamate Ajax.

Prima di prendere una decisione finale guardati intorno e chiedi altri pareri. Esamina la documentazione dei framework che andrai ad utilizzare e gli esempi per iniziare. Insomma, devi ritagliarti un po' di tempo per fare ricerca prima di iniziare a scrivere codice, altrimenti rischi di impantanarti più in là nello sviluppo se il progetto non viene accuratamente pianificato sin da subito.

Buon lavoro!
ciao,