Quando utilizziamo Entity Framework per persistere lo stato degli oggetti sul database ci possiamo trovare di fronte a due scenari diversi. Il primo scenario è quello cosidetto connesso che è tipico di applicazioni WindowsForm/WPF. Il secondo scenario è quello disconnesso che invece è tipico delle applicazioni web e dei web services (ASP.NET/WCF/ASMX). In questo articolo parleremo in dettaglio della seconda modalità, ma, per intuire al meglio quali siano le differenze tra le due, è bene fare un piccolo riassunto.

Modello connesso e modello disconnesso

Nel modello connesso, il contesto (rappresentato dalla classe ObjectContext) viene istanziato per leggere i dati e per modificare gli stessi. Questo scenario è tipico delle applicazioni Windows dove il contesto viene creato all'apertura di una form e distrutto alla fine. Durante il ciclo di vita della form, lo stesso contesto viene utilizzato sia per leggere i dati da mostrare all'utente che per modificarli qualora l'utente cambi qualcosa. Questo flow è mostrato nella seguente figura.

Questo modo di lavorare è estremamente semplice. Come sappiamo, il contesto mantiene un riferimento agli oggetti letti conservandone lo stato originale. Quando un oggetto viene modificato il contesto viene notificato (questo non avviene sempre in real time, ma comunque avviene prima di persistere i dati) e memorizza i nuovi dati. Se aggiungiamo un oggetto al contesto e lo marchiamo per l'inserimento nel database o se marchiamo un oggetto per la cancellazione, il contesto salva queste azioni.

Quando arriva il momento di persistere lo stato degli oggetti, il contesto recupera tutte le modifiche effettuate ad oggetti letti, lo stato degli oggetti da inserire e da cancellare e lancia il processo di salvataggio sul database. In questo scenario il nostro modo di lavorare è semplice: leggiamo, modifichiamo, inseriamo e cancelliamo oggetti e non facciamo altro.

Nel modello disconnesso, il contesto con cui vengono letti i dati, è diverso da quello con cui vengono modificati sul database. Questo scenario è tipico nelle applicazioni disconnesse come i web services. In questo caso il client effettua una chiamata al servizio per recuperare i dati da visualizzare. Il servizio istanzia il contesto, effettua la query, distrugge il contesto e restituisce i dati al client. Il client modifica i dati localmente ed invoca un nuovo metodo sul servizio per salvarli. Il servizio istanzia un nuovo contesto, attacca i dati dell'utente li marca per la modifica e li persiste. Questo processo è mostrato nella prossima figura.

Anche se a prima vista questo modello di sviluppo sembra semplice, la fase in cui gli oggeti da persistere vengono attaccati al contesto può essere piuttosto complessa poiché il metodo del servizio non ha conoscenza di cosa è stato modificato sul client. Nel corso dell'articolo vedremo perché questa fase può essere difficile, ma ora analizziamo la nostra applicazione di esempio.

Applicazione di esempio

L'applicazione che andiamo ad utilizzare per il nostro esempio è piuttosto semplice. Infatti creeremo un servizio con i cinque metodi mostrati nel seuente codice.

public interface ISimpleService
{
  [OperationContract]
  Order ReadOrder(int id);

  [OperationContract]
  void UpdateOrder(Order order);

  [OperationContract]
  void InsertOrder(Order order);

  [OperationContract]
  void DeleteOrder(int id);

  [OperationContract]
  void UpdateShippingDate(int orderId, DateTime shippingDate);
}

ReadOrder legge un ordine dal database e lo ritorna al client; UpdateOrder aggiorna un ordine sul database con i dati del client; InsertOrder persiste un ordine come nuovo; DeleteOrder cancella dal database il record relativo all'ordine; UpdateShippingDate aggiorna la data di invio dell'ordine.

L'EDM che rappresenta il modello dell'applicazione è il seguente:

Vediamo ora come implementare l'applicazione.