WCF DataServices - L'add di una entity ritorna l'entity
-
domenica 5 febbraio 2012 18:10
Ciao a tutti,
continuo a piccoli passi con l'uso di un dataservice con EF 4.1 CodeFirst.
Oggi sto guardando con Fiddler cosa succede "sotto" e c'è una cosa che non capisco.
Ho una Entity di test Table(Tavolo) e ne faccio un add semplice
var DB = new Helper().CreateContext(); var T = new DS.Table(); T.ID = Guid.NewGuid(); T.Giudizio = "Bello"; T.NumeroPiedi = 12; DB.AddToTables(T); DB.SaveChanges();
tutto funziona regolarmente, però se guardo su Fiddler, nella richiesta c'è una Post con l'entity da salvare, ma nella risposta, oltre ad altri dettagli, c'è tuta l'entity che ho passato per il salvataggio. Praticamente mi è tornata indietro tutta l'entity.E' normale questo comportamento oppure si può evitare?
In questo modo, non si genera tantto traffico inutile?
Ciao e grazie
Tutte le risposte
-
domenica 5 febbraio 2012 19:07
ciao
è normale perchè l'entità va aggiornata di possibili calcoli avuti sul server
-
domenica 5 febbraio 2012 19:41
ciao
è normale perchè l'entità va aggiornata di possibili calcoli avuti sul server
Ciao, grazie per la tua continua disponibilità.Per capire il senso di questo comportamento, potresti farmi un esempio su cosa intendi con "possibili calcoli avuti sul server"?, quello che passo per l'Add, lo vedo come un "DTO" (che rispecchia l'entity che sta sul server)
Ciao
-
domenica 5 febbraio 2012 19:42
ciao
di niente :)
un esempio tipico è l'ID autogenerato che appunto è generato dal DB e non da EF
-
domenica 5 febbraio 2012 19:52
ciao
di niente :)
un esempio tipico è l'ID autogenerato che appunto è generato dal DB e non da EF
Bhe, pero per recuperare un ID autoincrementale, viene fatta viaggiare l'intera entity sulla rete?
Adesso non ho modo di verificare(sul mio PC ho solo sql Express), ma EF in questa circostanza, per recuperare l'ID autogenerato fa una query con su tutta l'entity?
ciao
-
domenica 5 febbraio 2012 19:54
bè, avere un aggiornamento dell'entità non significa leggere l'ID
come farebbe EF a sapere se hai trigger sul DB per modificare i dati? etc, etc, etc?!?!?
EF si limita giustamente a darti un entità correttamente materializzata dal DB
-
domenica 5 febbraio 2012 19:58
bè, avere un aggiornamento dell'entità non significa leggere l'ID
come farebbe EF a sapere se hai trigger sul DB per modificare i dati? etc, etc, etc?!?!?
EF si limita giustamente a darti un entità correttamente materializzata dal DB
Si certo, non ci avevo pensato, però EF qando fai l'Add di una entity, non rilegge l'entity dal DB per controllare se ci sono state modifiche no? Il comportamento è diverso- Modificato G Luca domenica 5 febbraio 2012 19:59
-
domenica 5 febbraio 2012 20:03
per l'AddNew non essitono problemi di concorrenza
per gli update si!
nel caso si voglia, EF può gestirli impostando nell'entità che vogliamo una proprietà con la sottoproprietà ConcorrencyMode = Fixed
a quel punto EF solleverà 1 eccezione in caso di modifiche multiple impedendo i casini
-
domenica 5 febbraio 2012 20:08
per l'AddNew non essitono problemi di concorrenza
per gli update si!
nel caso si voglia, EF può gestirli impostando nell'entità che vogliamo una proprietà con la sottoproprietà ConcorrencyMode = Fixed
a quel punto EF solleverà 1 eccezione in caso di modifiche multiple impedendo i casini
ciao,non stavo parlando di concorrenza e di aggiornamenti, ma di un Add, mi sembra "pesante" che l'entity ritorni indietro intera, cosa che EF non fa non rileggendo l'entity dal DB dopo un Add.
-
domenica 5 febbraio 2012 20:10
ciao
compreso male :)
il pattern del DTO non prevede il non chiamare per ridurre la banda, ma tornarti tutto il necessario così da evitare un numero maggiore di chiamate
riassumendo: spesso costa di più fare 2 chiamate (l'add, e poi il refresh quando ti servirà, perchè ti servirà x forza visto che c'è sempre qualche proprietà da aggiornare) che farne una sola con un po di xml in più
-
domenica 5 febbraio 2012 20:26
E' difficile prevedere con certezza che C'è sempre qualche proprietà da aggiornare, e imporlo come vincolo, a me verrebbe facile immaginare che è spesso il contrario, a maggior ragione usando i GUID al posto degli auto incrementali. Inoltre al crescere della dimensione della entity ha sempre più incidenza. WCF di suo ha il concetto di oneway per risparmiarsi anche una semplice risposta senza corpo mentre i Dataservices restituiscono tutta l'entity perchè potrebbe servire, mi sembra poco efficienteciao
compreso male :)
il pattern del DTO non prevede il non chiamare per ridurre la banda, ma tornarti tutto il necessario così da evitare un numero maggiore di chiamate
riassumendo: spesso costa di più fare 2 chiamate (l'add, e poi il refresh quando ti servirà, perchè ti servirà x forza visto che c'è sempre qualche proprietà da aggiornare) che farne una sola con un po di xml in più
-
domenica 5 febbraio 2012 20:28
il DTO è un pattern più che consolidato
i datasevices sono basati sul protocollo OData
se l'insieme non ti piace, usa pure WCF standard
ma comunque lavorare senza response è pericoloso... vale solo per scenari asincroni in cui comunque un ack su un altro canale è sempre bene avere, fosse pure per sapere che non c'è stata 1 eccezione
-
domenica 5 febbraio 2012 20:37
il DTO è un pattern più che consolidato
i datasevices sono basati sul protocollo OData
se l'insieme non ti piace, usa pure WCF standard
ma comunque lavorare senza response è pericoloso... vale solo per scenari asincroni in cui comunque un ack su un altro canale è sempre bene avere, fosse pure per sapere che non c'è stata 1 eccezione
Forse mi sono spiegato male, non vole dire che il oneway è il modo migliore di pensare le cose, assolutamente no. Volevo solo dire che WCF si è posto il problema e ha dato degli strumenti allo sviluppatore per decidere la strategia migliore. Sarebbe bello se anche i Dataservices offrissero questi strumenti.Si, potrei usare direttamente WCF, ma con i dataservices si risparmiano kg e kg di codice e si evitano continue versioni del server. Come strumento un DS è meraviglioso, solo che in certecose un po ci rimani male di non avere modo di intervenire(IMHO) .
Ciao
-
lunedì 6 febbraio 2012 00:25
ciao
credo tu stia facendo 1 assunto sbagliato :)
mi spiego: WCF è un framework, DataServices è un Servizio già funzionante secondo lo standard OData
è ovvio che WCF ti da ogni possibilità, ma non scrive niente per te
DataServices invece sono un servizio già funzionante, e dovendo coprire ogni necessità di un servizio DaaS (data-as-a-service) si sono posti tutti i problemi del caso nel farlo (o dei vari casi) che sia o non perfetto per te questo è parte del motivo da parte tua di scegliere di usarlo oppure no
ma non è una mancanza della tecnologia
spero di essermi spiegato, altrimenti chiedi pure ulteriori spiegazioni
a presto
-
lunedì 6 febbraio 2012 07:44
Ciao G Luca,
You wrote on 05/02/2012 :
E' difficile prevedere con certezza che C'è sempre qualche proprietà da aggiornare, e imporlo come vincolo, a me verrebbe facile immaginare che è spesso il contrario, a maggior ragione usando i GUID al posto degli auto incrementali. Inoltre al crescere della dimensione della entity ha sempre più incidenza. WCF di suo ha il concetto di oneway per risparmiarsi anche una semplice risposta senza corpo mentre i Dataservices restituiscono tutta l'entity perchè potrebbe servire, mi sembra poco efficiente
sono complessivamente d'accordo con te, il problema è inquadrare perché esistono i WCF DataService (come il perché esistono i Ria Services).
Sono tutte tecnologie che ricadono sotto il cappello di RAD e come tali hanno lo scopo di semplificarti al massimo la vita imponendoti però il loro modo di vedere le cose, che giustamente in certi scenari può anche essere profondamente sbagliato.
Il problema vero è che queste tecnologie cercano di fare una cosa sbagliatissima in termini SOA: "nascondere" WCF al fine di eliminare un ordine di complessità; il problema è che questo è evidentemente contrario ad un dei tenet di SOA: "service boundaries are explicit".
.m
--
blog @ //milestone.topics.it -
lunedì 6 febbraio 2012 13:14
Ciao G Luca,
You wrote on 05/02/2012 :
E' difficile prevedere con certezza che C'è sempre qualche proprietà da aggiornare, e imporlo come vincolo, a me verrebbe facile immaginare che è spesso il contrario, a maggior ragione usando i GUID al posto degli auto incrementali. Inoltre al crescere della dimensione della entity ha sempre più incidenza. WCF di suo ha il concetto di oneway per risparmiarsi anche una semplice risposta senza corpo mentre i Dataservices restituiscono tutta l'entity perchè potrebbe servire, mi sembra poco efficiente
sono complessivamente d'accordo con te, il problema è inquadrare perché esistono i WCF DataService (come il perché esistono i Ria Services).
Sono tutte tecnologie che ricadono sotto il cappello di RAD e come tali hanno lo scopo di semplificarti al massimo la vita imponendoti però il loro modo di vedere le cose, che giustamente in certi scenari può anche essere profondamente sbagliato.
Il problema vero è che queste tecnologie cercano di fare una cosa sbagliatissima in termini SOA: "nascondere" WCF al fine di eliminare un ordine di complessità; il problema è che questo è evidentemente contrario ad un dei tenet di SOA: "service boundaries are explicit".
.m
--
blog @ //milestone.topics.it
ciao Maurodaccordissimo con te
-
lunedì 6 febbraio 2012 14:05
ciao
credo tu stia facendo 1 assunto sbagliato :)
mi spiego: WCF è un framework, DataServices è un Servizio già funzionante secondo lo standard OData
è ovvio che WCF ti da ogni possibilità, ma non scrive niente per te
DataServices invece sono un servizio già funzionante, e dovendo coprire ogni necessità di un servizio DaaS (data-as-a-service) si sono posti tutti i problemi del caso nel farlo (o dei vari casi) che sia o non perfetto per te questo è parte del motivo da parte tua di scegliere di usarlo oppure no
ma non è una mancanza della tecnologia
Non li sto mettendo sullo stesso piano, stavo solo rispondendo al tuo
"se l'insieme non ti piace, usa pure WCF standard"
Non dico che DS non sia un buon prodotto, è solo che secondo me sono tutti punti migliorabili. Anche EF all'inizio andava abbastanza stretto, ma con le versioni successive ha sempre dato più possibilità di intervenire. Spero solo che i DS seguano lo stesso tipo di percorso, e il discuterlo sui forum mi sembra comunque un piccolo contributo.
non mancherò di certo :)spero di essermi spiegato, altrimenti chiedi pure ulteriori spiegazioni
a presto
-
lunedì 6 febbraio 2012 14:10
Ciao G Luca,
You wrote on 05/02/2012 :
E' difficile prevedere con certezza che C'è sempre qualche proprietà da aggiornare, e imporlo come vincolo, a me verrebbe facile immaginare che è spesso il contrario, a maggior ragione usando i GUID al posto degli auto incrementali. Inoltre al crescere della dimensione della entity ha sempre più incidenza. WCF di suo ha il concetto di oneway per risparmiarsi anche una semplice risposta senza corpo mentre i Dataservices restituiscono tutta l'entity perchè potrebbe servire, mi sembra poco efficiente
sono complessivamente d'accordo con te, il problema è inquadrare perché esistono i WCF DataService (come il perché esistono i Ria Services).
Sono tutte tecnologie che ricadono sotto il cappello di RAD e come tali hanno lo scopo di semplificarti al massimo la vita imponendoti però il loro modo di vedere le cose, che giustamente in certi scenari può anche essere profondamente sbagliato.
Si, mi sto facendo un po le ossa. Sono daccordo con te, solo che le tecnologie RAD danno spesso comportamenti di default con la possibilità di intervenire per modificarli. Spero che DS dia sempre più possibilità di questo tipo, perchè come prodotto è davvero bello.
Il problema vero è che queste tecnologie cercano di fare una cosa sbagliatissima in termini SOA: "nascondere" WCF al fine di eliminare un ordine di complessità; il problema è che questo è evidentemente contrario ad un dei tenet di SOA: "service boundaries are explicit".
.m
Daccordissimo -
lunedì 6 febbraio 2012 15:00
ciao
credo tu stia facendo 1 assunto sbagliato :)
mi spiego: WCF è un framework, DataServices è un Servizio già funzionante secondo lo standard OData
è ovvio che WCF ti da ogni possibilità, ma non scrive niente per te
DataServices invece sono un servizio già funzionante, e dovendo coprire ogni necessità di un servizio DaaS (data-as-a-service) si sono posti tutti i problemi del caso nel farlo (o dei vari casi) che sia o non perfetto per te questo è parte del motivo da parte tua di scegliere di usarlo oppure no
ma non è una mancanza della tecnologia
Non li sto mettendo sullo stesso piano, stavo solo rispondendo al tuo
"se l'insieme non ti piace, usa pure WCF standard"
Non dico che DS non sia un buon prodotto, è solo che secondo me sono tutti punti migliorabili. Anche EF all'inizio andava abbastanza stretto, ma con le versioni successive ha sempre dato più possibilità di intervenire. Spero solo che i DS seguano lo stesso tipo di percorso, e il discuterlo sui forum mi sembra comunque un piccolo contributo.
non mancherò di certo :)spero di essermi spiegato, altrimenti chiedi pure ulteriori spiegazioni
a presto
ciaose vuoi puoi dare 1 occhio al blog del team di WCFDS
http://blogs.msdn.com/b/astoriateam/default.aspx?wa=wsignin1.0
se non erro, da qualche parte c'è 1 link ad una pagina dove raccolgono le richieste degli utenti :)
a presto
