Entità di tracciamento automatico vs Entità POCO

Question

Stiamo avviando un nuovo prodotto basato sul Web in cui intendiamo esporre la nostra logica aziendale tramite i servizi WCF. Useremo ASP.NET 4.0, C#, EF 4.0. In futuro vogliamo costruire applicazioni iphone e applicazioni WPF basate sui servizi. Ho letto molto sull'utilizzo di POCO vs Self Tracking Entities (STE) e da quanto ho capito gli STE non funzionano bene con lo scenario web. Qualcuno può fare più luce su questo problema?

Answer 1

Per me STE è un concetto assolutamente sbagliato. È solo un'altra implementazione di DataSet.

• Nell'applicazione ASP.NET è necessario memorizzare STE tra le richieste. Nella prima richiesta interrogerai la tua origine dati per ottenere STE e fornire dati nella pagina. Nella prossima richiesta (postback) si vorrà modificare STE con i dati restituiti dal browser. Per supportare il tracciamento dovrai utilizzare lo stesso STE della prima richiesta = > dovrai memorizzare STE in viewstate (se vuoi utilizzare i WebForms ASP.NET) o sessione.
• STE è inutile per SOA o interoperabilità. La logica di tracciamento è parte di STE = è in esecuzione sul client. Se esponi STE nel servizio, ti aspetti immediatamente che quella parte del cliente utilizzerà le stesse funzionalità di tracciamento incluse nella logica STE. Ma queste funzionalità non sono fornite automaticamente dall'altra parte. In .NET li hai perché condividi l'assembly con STE. Ma su un'altra piattaforma devi spiegare agli sviluppatori come implementare la logica di STE per farlo funzionare dalla tua parte. Questo sarà probabilmente il caso più limitante per te a causa dell'applicazione iPhone.

Answer 2

Le entità di tracciamento automatico funzionano perfettamente in un MVC Web con scenario WCF. Sono stato coinvolto in 2 progetti che li utilizzano (uno in produzione, uno quasi).

Con POCO si perderebbe il rilevamento delle modifiche sul filo che crea molto dolore extra perché EF ora deve richiedere nuovamente informazioni sullo stato. Se stai usando EF e WCF STE risolvi un sacco di problemi e rendi la tua intera pipeline di persistenza davvero fluida.

---

Potete fornire la citazione per questo reclamo? "STE non funzionano bene con lo scenario web"

Answer 3

Se questo servizio sta per essere consumato da qualsiasi applicazione non si ha il controllo diretto sulle, probabilmente si dovrebbe prendere in seria considerazione il divorzio a che fare con EF (o NHibernate o Linq2Sql o qualsiasi altra soluzione di gestione dei dati di persistenza) dai tuoi servizi e dai tuoi oggetti per il trasferimento dei dati. Ciò isolerà i cambiamenti interni dai clienti in avaria. Rompere i clienti è in genere una brutta cosa.

Answer 4

Vedere http://msdn.microsoft.com/en-us/data/jj613924.aspx, poiché STE non è più consigliato! Microsoft consiglia l'utilizzo di API Web ASP.NET, WCF Data Services o Entity Framework API (operazioni complesse)