Introduzione a .NET RIA Services

Domain Operation di modifica e personalizzate

Quanto visto fino adesso comprende la definizione di un DomainService, l'interrogazione e la modifica dei dati lato client e come si inoltrano le modifiche al server. Una volte che queste giungono al servizio parte un processo di smistamento delle operazioni da eseguire in funzione che le entità siano state aggiornate, cancellate o inserite.

Per farlo il motore individua queste operazioni in base ad una convenzione nel nome dei metodi e nei parametri che questi accettano. Il metodo per l'inserimento di nuove entità deve infatti iniziare con "Insert" o "Add" o "Create" seguito solitamente dal nome dell'entità, ma non è obbligatorio. L'importante che questo metodo accetti l'entità di un certo tipo, perciò per l'entità Message si può definire un metodo così:

public void InsertMessage(Message message) 
{ 
    // TODO: chiamo il DAL 
}

Per le entità aggiornate occorre definire un metodo che inizi con "Update" o "Change" o "Modify" ed i parametri siano due della medesima entità: quella aggiornata e quella originale.

public void UpdateMessage(Message changedMessage, Message originalMessage) 
{ 
    // TODO: chiamo il DAL 
}

Per le entità cancellate occorre invece un metodo con prefisso "Delete" o "Remove" che accetti l'entità da cancellare ed eventualmente l'entità originale:

public void DeleteMessage(Message message) 
{ 
    // TODO: chiamo il DAL 
}

Non fa eccezione il metodo di lista delle entità che deve avere prefisso "Get", "Fetch", "Find", "Query", "Retrieve", "Select" e deve restituire o un IEnumerable<T> oppure un IQueryable<T>.

In tutti i casi, qualora la convenzione dei nomi dei metodi CRUD non piaccia, si può marcare ogni metodo con i rispettivi attributi Insert, Query, Update, Delete.

[Delete()] 
public void CancellaMessaggio(Message message) 
{ 
}

Di questi metodi, solo per quello di lista viene creato un metodo nel DomainContext sul client che solitamente ha nome "Load" + resto del nome del metodo. Se si intende mantenere lo stesso nome del server si può impostare PreserveName a true sull'attributo Query. Per le restanti tipologie dei metodi non è invece necessario nessuna controparte client, poiché è il metodo SubmitChanges che si fa carico di distribuire le chiamate. Qualora una tipologia di questi metodi manchi, sulla contro parte client e nello specifico sull'EntityContainer di competenza, viene indicata che quell'operazione non è supportata generando di conseguenza un'eccezione qualora si tenti di inserire, cancellare o aggiornare un'entità.

Nei casi in cui si voglia aggiungere un metodo personalizzato che lavori su una determinata entità, è possibile marcarlo con l'attributo Custom. Per esempio, un metodo MarkAsRead può segnare un messaggio come letto e lo si può definire in questo modo (è obbligatorio che accetti l'entità):

[Custom()] 
public void MarkAsRead(Message message) 
{ 
    // TODO: marca il messaggio 
}

La caratteristica molto interessante è che nel DomainContext generato sul client Silverlight, vi è il metodo MarkAsRead, ma quando questo viene invocato dallo sviluppatore, non avviene nessuna chiamata al servizio, ma viene solamente accodata la richiesta. Il change set che ogni entità mantiene contiene infatti anche le action su di essa invocate. Solo invocando il metodo SubmitChanges vengono poi inoltrate le modifiche e le azioni nella "coda".

Se invece si vuole dichiarare un'operazione che venga invocata subito, è possibile definire un metodo sul Domain Service, con il nome e i parametri che si desiderano, marcandolo con l'attributo ServiceOperation.

[ServiceOperation()] 
public void LogError(string message) 
{ 
    Trace.WriteLine(message); 
}

In questo metodo modo il codice generato sul client è composto dal metodo LogError che chiama subito in asincrono il servizio, e da un evento LogErrorCompleted per notificare quando la chiamata è terminata.