EF Detached objects and CSLA

EF Detached objects and CSLA

Old forum URL: forums.lhotka.net/forums/t/9856.aspx

bastidas posted on Friday, December 10, 2010

I noticed that, when working with EF, people are handling the detached
objects from the EF context in 3 ways (may be more, I just seen these)

- Re-query the db for the object before Updates
- Re-Construct only the EntityKey with the info at hand
- Only carry the EntityKey in the CSLA object on a binary property

I can see that the first one will 'raise eyebrows' among developers (and
dba's). What do you think are the trade offs or problems of using the any of
the other two. And are there any benefits of having the original
object/state when re-attaching to the context?

If so what are the options to re-create those objects? Can any of the Levels
in the CSLA n-level undo be used to do this. How about storing the EF
original objects on a Distributed Cache?

Thank you

sergeyb replied on Friday, December 10, 2010

I personally always use option 2.  You need PK data anyway usually, so it gives you ability to reconstrunct EF object when you need it. 

Copyright (c) Marimer LLC