Yocker
  1. Yocker
  3. Entità di monitoraggio automatico rispetto alle entity framework POCO
Intereting Posts
Come posso specificare la piattaforma per MSBuild? jquery salva json data object nel cookie Raschiare i dati dal sito web usando vba Dove posso trovare un elenco di codici di uscita “mysqldump”? Come confrontare gli oggetti in base a più campi come cambiare il colore dell’intestazione DataGridview winform? server ha inviato eventi (fonte di eventi) con asp.net mvc standard che ha causato l’errore Spostare i dati SQL da una tabella a un’altra Dichiarare le variabili a 64 bit in C Tipi di versione Unix Programmazione Riddle: come potresti tradurre un nome di colonna di Excel in un numero? Come risolvere java.lang.NoClassDefFoundError? html5 video non funziona su ipad Java passa per riferimento? Disabilitazione dei collegamenti per bloccare i clic doppi in JQuery

Entità di monitoraggio automatico rispetto alle entity framework POCO

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 build 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?

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

  • Nell’applicazione ASP.NET dovrai 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.

Le quadro 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 perderai qualsiasi tracciamento delle modifiche sul filo che crea un sacco di dolore in più 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 una citazione per questo reclamo? “STE non funzionano bene con lo scenario web”

Fare riferimento a 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)

Se questo servizio verrà utilizzato da qualsiasi app su cui non hai il controllo diretto, dovresti probabilmente considerare seriamente il divorzio da qualsiasi cosa con EF (o nibernate o Linq2Sql o qualsiasi altra soluzione di gestione della persistenza dei dati) dai tuoi servizi e dai tuoi dati trasferire oggetti. Ciò isolerà i cambiamenti interni dai clienti in avaria. Rompere i clienti è in genere una brutta cosa.