Un servizio WCF deve restituire una classe EntityObject o POCO/DTO?

Question

Ho esaminato molti esempi di WCF utilizzando EntityFramework e molti di essi sembrano restituire al client una sorta di classe POCO o DTO.

Mi chiedevo il motivo per cui questo era il default EntityObject include gli attributi [DataContract]INotifyPropertyChanged. Restituire una classe DTO o POCO migliore di una EntityObject (o viceversa)? Esistono casi specifici in cui è preferibile utilizzare un valore di ritorno su un altro?

Answer 1

Come best practice, è consigliabile restituire una classe DTO/POCO progettata esplicitamente come contratto dati e senza logica di persistenza.

Il motivo è che, se si passa un oggetto EntityObject, si presuppone che il consumatore del servizio avrà un riferimento allo stesso contesto di dati e questo viola il principio SOA dei limiti espliciti. Riduce la riusabilità del tuo servizio.

È probabile che Microsoft abbia implementato DataContract su EntityObject per supportare alcuni dei loro strumenti di accesso al database basati su WCF come RIA. INotifyPropertyChanged è per il supporto di binding WPF e non è correlato a WCF o contratti di dati.

Answer 2

Vale la pena restituire il POCO in alcuni casi in cui non si è a conoscenza della logica di persistenza. Intendo che lo stesso POCO può essere collegato ad altri ORM o per altri scopi. Ok questo è un vantaggio di POCO su ORM ma offre anche un incremento delle prestazioni su EntityObject che aggiunge tempo di esecuzione di proxy/notificatori.

Restituzione POCO - È necessario aggiornare manualmente lo stato dell'entità quando ricevuto da WCF.

Returning EntityObject - Si riceve l'entità con stato mantenuto.