Esporta (0) Stampa
Espandi tutto

Generazione del codice client

WCF RIA Services

Quando si collega un progetto Silverlight e un progetto di livello intermedio mediante WCF RIA Services, in RIA Services vengono generate le classi proxy client per l'applicazione client in base alle entità e alle operazioni esposte nel livello intermedio. Poiché in RIA Services vengono generate tali classi, non è necessario duplicare la logica dell'applicazione dal livello intermedio al livello di presentazione. Tutte le modifiche apportate al codice di livello intermedio vengono sincronizzate con il codice del livello di presentazione durante la ricompilazione del progetto client. Quando si aggiunge un collegamento di RIA Services a una soluzione, a quest'ultima viene aggiunta anche una dipendenza di compilazione esplicita forzando la compilazione del progetto server prima della generazione del codice per il progetto client.

Il codice generato si trova in una cartella denominata Generated_Code nel progetto client. Per visualizzare questa cartella, è necessario selezionare Mostra tutti i file nella finestra Esplora soluzioni per il progetto client. Non è consigliabile modificare direttamente le classi nella cartella Generated_Code perché verranno sovrascritte durante la ricompilazione del progetto client. Tuttavia, è possibile aprire il file generato per visualizzare il codice disponibile per il progetto client.

RIA_GeneratedCode

L'algoritmo che genera il codice client segue queste regole di base:

  1. Analizzare tutti gli assembly compilati o a cui fa riferimento il progetto di livello intermedio per le classi del servizio del dominio, le classi di entità o il codice condiviso.

  2. Per ogni servizio del dominio annotato con l'attributo EnableClientAccessAttribute generare una classe che deriva dalla classe DomainContext.

  3. Per ogni metodo di query, metodo di aggiornamento denominato, ovvero un metodo di aggiornamento con la proprietà UsingCustomMethod impostata su true, o un'operazione invoke nella classe del servizio del dominio, generare un metodo nella classe del contesto del dominio.

  4. Per ogni classe di entità esposta da un servizio del dominio, generare una classe proxy dell'entità. Una classe di entità viene esposta quando viene restituita da un metodo di query.

  5. Copiare il codice contrassegnato per la condivisione nel progetto client.

Nell'immagine seguente viene illustrato il codice client generato per un progetto di livello intermedio.

Generazione del codice client

DomainService e DomainContext

Per ogni classe del servizio del dominio viene generata un'unica classe che deriva da DomainContext in base alle regole seguenti:

  1. La classe del contesto del dominio viene generata con lo stesso spazio dei nomi del servizio del dominio.

  2. La classe del contesto del dominio contiene tre costruttori:

    1. Un costruttore predefinito che incorpora l'URI necessario per comunicare con il servizio del dominio su http utilizzando una classe WebDomainClient.

    2. Un costruttore che consente al client di specificare un URI alternativo.

    3. Un costruttore che consente al client di fornire un'implementazione personalizzata di DomainClient, utilizzata in genere per gli unit test o per il reindirizzamento a un livello di trasporto personalizzato.

  3. Per ogni metodo di query nella classe del servizio del dominio, generare un metodo EntityQuery che può essere utilizzato nel progetto client per caricare le entità.

  4. Per ogni operazione invoke, generare un metodo InvokeOperation corrispondente che può essere utilizzato per richiamare l'operazione in modo asincrono.

  5. Per ogni metodo contrassegnato con l'attributo Update(UsingCustomMethod=true), generare i metodi per richiamarlo e per determinare se è stato richiamato.

  6. I metodi pubblici nel servizio del dominio che eseguono operazioni di inserimento, aggiornamento o eliminazione comportano la costruzione dell'oggetto EntityContainer generato nel contesto del dominio con un flag EntitySetOperations che indica le operazioni consentite sul client.

Classe di entità e classe proxy dell'entità

Le regole seguenti vengono applicate durante la generazione della classe proxy dell'entità:

  1. La classe proxy viene generata con lo stesso nome e lo stesso spazio dei nomi della classe di entità nel livello intermedio.

  2. Il tipo di entità radice deriva dalla classe di entità. I tipi di entità derivati derivano dai tipi di base corrispondenti esposti dal livello intermedio.

  3. Ogni proprietà pubblica che contiene un tipo supportato e che non è contrassegnata con l'attributo ExcludeAttribute nella classe di entità viene generata nella classe proxy, a meno che la proprietà non sia già presente nel progetto client. Per ulteriori informazioni, vedere la sezione "Come evitare membri duplicati" più avanti in questo argomento. Object non è un tipo supportato.

  4. Ogni metodo per l'impostazione della proprietà conterrà il codice che esegue la convalida e notifica i client che è in corso la modifica della proprietà o che la proprietà è stata modificata.

  5. Gli attributi di metadati vengono combinati con la classe di entità nel codice generato. Nel client non sarà presente alcuna classe di metadati.

  6. Se possibile, gli attributi personalizzati vengono propagati nella classe proxy. Per una descrizione delle condizioni che devono sussistere affinché l'attributo personalizzato possa essere incluso nel progetto client, vedere la sezione seguente "Attributi personalizzati".

Se per il membro vengono specificati lo stesso tipo e lo stesso metodo di convalida in più istanze dell'oggetto CustomValidationAttribute, al membro verrà propagato un solo oggetto CustomValidationAttribute.

Attributi personalizzati

Gli attributi personalizzati vengono propagati alla classe proxy se l'aggiunta dell'attributo personalizzato non genera un errore di compilazione nel progetto client. Affinché l'attributo personalizzato venga propagato, devono sussistere le condizioni seguenti:

  1. Il tipo di attributo personalizzato deve essere disponibile nel progetto client.

  2. Tutti i tipi specificati nella dichiarazione dell'attributo personalizzato devono essere disponibili nel progetto client.

  3. Il tipo di attributo personalizzato deve esporre un metodo per l'impostazione pubblico per tutte le relative proprietà o esporre un costruttore che consenta l'impostazione delle proprietà che non dispongono di un metodo per l'impostazione pubblico.

Se un attributo personalizzato necessario non viene propagato al client, potrebbe essere necessario aggiungere un riferimento all'assembly nel progetto client. Aggiungere un riferimento a qualsiasi assembly necessario per la compilazione dell'attributo personalizzato nel progetto client. È inoltre possibile condividere un attributo personalizzato tra i livelli definendolo in un file condiviso.

Codice condiviso

Quando si condividono file di codice tra il livello intermedio e il livello di presentazione, il codice viene copiato senza alcuna modifica nel progetto client. Per specificare un file per la condivisione, denominarlo in base ai criteri *.shared.cs o *.shared.vb. La struttura di directory del progetto di livello intermedio che contiene i file condivisi viene replicata nella cartella Generated_Code.

Quando si aggiunge un tipo personalizzato in un file di codice condiviso e si specifica di restituire tale tipo da un'operazione invoke, il metodo generato nel contesto del dominio non restituirà il tipo personalizzato, ma restituirà invece un tipo che fa parte del framework. Se ad esempio si crea un tipo personalizzato denominato MyCustomDictionary che implementa IDictionary e si specifica tale tipo come valore restituito per un'operazione di dominio, il metodo generato nel contesto del dominio non restituirà MyCustomDictionary, ma restituirà invece un oggetto Dictionary.

Per ulteriori informazioni, vedere Codice condiviso.

Come evitare membri duplicati

Quando si genera una classe proxy dell'entità, è possibile che lo stesso tipo e lo stesso membro siano già stati definiti nel progetto client tramite i tipi parziali. È possibile che il membro sia stato definito nel codice condiviso o nel codice presente solo nel progetto client. In RIA Services viene eseguita una verifica dei membri esistenti prima della generazione della classe proxy. Tutti i membri già definiti non verranno generati nella classe proxy.

Vedere anche

Mostra:
© 2015 Microsoft