VENDITE: 1-800-867-1389

Applicazioni Web di Azure e serializzazione

Aggiornamento: giugno 2014

Quando si scrivono applicazioni per , la serializzazione dei dati diventa un aspetto sempre più importante se confrontato con la scrittura di applicazioni locali. Le applicazioni Azzurre vengono addebitate in base all'utilizzo del database, all'archiviazione generale, ai trasferimenti di dati e alla memorizzazione nella cache. Per ulteriori informazioni sui prezzi, vedere Panoramica dei prezzi di Azure. Le applicazioni Azure, inoltre, possono essere utilizzate da dispositivi mobili come telefoni, tablet e così via e questo tipo di connessione parziale può, per sua natura, provocare latenza. Tutti questi fattori assumono un significato molto importante relativamente alla modalità di invio e ricezione dei dati dall'applicazione in uso. Payload più piccoli consentiranno di ridurre i costi per la larghezza di banda e l'archiviazione, oltre alla possibilità di ridurre la latenza.

In WCF sono disponibili quattro diversi serializzatori: DataContractSerializer, XmlSerializer, NetDataContractSerializer e DataContractJsonSerializer. Tramite il serializzatore viene determinata la modalità in base alla quale gli oggetti .NET vengono convertiti in XML. Una volta serializzati, i dati XML vengono trasmessi come serie di byte. Il processo di acquisizione del codice XML e della relativa conversione in un flusso di byte viene chiamato codifica. WCF supporta le codifiche seguenti: testo, binaria e MTOM. La serializzazione è controllata dagli attributi nel contratto di servizio. Per impostazione predefinita, viene utilizzato DataContractSerializer, specificato da ServiceContractAttribute. Per utilizzare XmlSerializer, applicare XmlSerializerFormatAttribute al contratto di servizio. DataContractJsonSerializer viene utilizzato quando a un'operazione di servizio viene applicato WebGetAttribute o WebInvokeAttribute. Entrambi gli attributi consentono di specificare RequestFormat e ResponseFormat. Per utilizzare JSON per le richieste e le risposte, impostare entrambi gli attributi su WebMessageFormat.Json. Per JSON è necessario utilizzare WebHttpBinding mediante il quale viene configurato automaticamente WebHttpBehavior. Per ulteriori informazioni sulla serializzazione WCF, vedere Serializzazione e deserializzazione e l'articolo relativo alla serializzazione in Windows Communication Foundation. Per ulteriori informazioni su JSON e WCF, vedere l'articolo relativo all'introduzione dei servizi RESTfull con WCF, il post sulla creazione di servizi WCF abilitati per JSON in .NET 3.5 e la panoramica di REST in WCF.

ImportantImportante
Per l'utilizzo di JSON sono necessari WebHttpBinding e WebHttpBehavior che non supportano la comunicazione SOAP. I servizi mediante i quali è possibile comunicare con WebHttpBinding non supportano l'esposizione dei metadati del servizio, pertanto non sarà possibile utilizzare la funzionalità Aggiungi riferimento al servizio di Visual Studio o lo strumento da riga di comando svcutil per generare un proxy lato client. Per ulteriori informazioni su come poter effettuare una chiamata a livello di codice dei servizi in cui viene utilizzato WebHttpBinding, vedere il post sull'utilizzo dei servizi REST con WCF.

Il protocollo Open Data supporta attualmente i due formati di serializzazione seguenti:

  • Atom Syndication Format (Atom): formato di scambio basato su XML utilizzato per feed Web.

  • JavaScript Object Notation (JSON): formato leggero di scambio di dati leggibili.

In OData, tramite i client è possibile richiedere il formato di serializzazione desiderato per la risposta impostando l'intestazione del messaggio per l'accettazione. OData offre inoltre l'opzione query di sistema $format utilizzabile dai client che non sono in grado di impostare intestazioni delle richieste. WCF Data Services supporta entrambi i formati di serializzazione Atom e JSON, ma non supporta l'opzione query $format. Per supportare la serializzazione JSON per tutti i client possibili, è consigliabile abilitare il supporto per l'opzione query $format nell'implementazione di WCF Data Services. Per ulteriori dettagli, vedere le informazioni aggiuntive su OData in Azure.

Di solito è utile dimostrare le differenze rilevanti delle dimensioni di serializzazione mostrando le serializzazioni dello stesso tipo che vengono serializzate in modo diverso. Di seguito è riportata la definizione di un tipo Person di esempio:

[DataContract(Namespace="http://example.org/person")]
    public class Person
    {
        public Person() { }
        public Person(string last, string first, string email)
        {
            lastName = last;
            firstName = first;
            emailAddress = email;
        }

        [DataMember]
        public string firstName { get; set; }

        [DataMember]
        public string lastName { get; set; }

        [DataMember]
        public string emailAddress { get; set; }
    }
}           

Istanza di Person serializzata tramite DataContractSerializer come segue:

<?xml version="1.0"?>
    <Person xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://example.org/person">
    <emailAddress>kim.abercrombie@contoso</emailAddress>
    <firstName>Kim</firstName>
    <lastName>Abercrombie</lastName>
</Person>

Istanza di Person serializzata tramite XmlSerializer come segue:

<?xml version="1.0"?>
<Person xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <firstName>Kim</firstName>
    <lastName>Abercrombie</lastName>
    <emailAddress>kim.abercrombie@contoso</emailAddress>
</Person>

Istanza di Person serializzata tramite DataContractJsonSerializer come segue:

{"emailAddress":"kim.abercrombie@contoso","firstName":"Kim","lastName":"Abercrombie"}

Un altro elemento da considerare è il codificatore di messaggi. Il codice XML viene acquisito e convertito dai codificatori in una serie di byte che può essere inviata nella rete. In questo modo è possibile ridurre considerevolmente le dimensioni del payload. I codificatori sono configurati per il binding. Per ulteriori informazioni sui codificatori, vedere Scelta di un codificatore di messaggi. La più piccola rappresentazione dei dati viene fornita dai codificatori binari Microsoft, tuttavia, il relativo utilizzo è possibile solo in scenari in cui sia il client sia il servizio vengono eseguiti in .NET Framework. Se per l'applicazione è necessaria l'interoperabilità con altre piattaforme, utilizzare il codificatore di testo. Inoltre, è possibile implementare il proprio codificatore personalizzato ed eseguire un tipo di compressione. Per ulteriori informazioni, vedere Codificatore di messaggi personalizzato

I migliori serializzatori e codificatori da utilizzare dipenderanno dall'applicazione e dalle esigenze di interoperabilità. Per scenari in cui il servizio e il client sono entrambi in esecuzione in .NET Framework, è consigliabile utilizzare il codificatore binario e DataContractSerializer. Per scenari in cui è necessaria l'interoperabilità, utilizzare il codificatore di testo. In questi tipi di scenari, la rappresentazione più piccola verrà offerta da DataContractJsonSerializer, ma è necessario l'utilizzo di un servizio non SOAP. Se è necessario utilizzare SOAP, si prenda in considerazione l'utilizzo di DataContractSerializer.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2014 Microsoft