Hi,

I'm asking this here because Frans loves flaming EF so I figure he knows what EF can and can't do.

One feature I always took for granted in LLBL was the way it managed dirty fields and would only update dirty fields. EF, to my complete shock/awe/amazement/confusion appears to completely suck at this. The particular "flavour" I am using is code first ef (no base class). I created my entity using the DbSet.Create which apparently gives me a proxy class. (As this is a web app I do not want to first load it from the db, update then save) Now the "only" way I have found to "update" a record is something like this:

context.Entity(myDomainInstance).State = EntityState.Modified

This has the completely stupid effect of marking the entire entity dirty and when trying to save it EF will try and update every column in the underlying table.

Poco.... there's a reason why we don't use poco's

When you require your persistent classes to be true poco classes, they don't have any change tracking mechanism on board. To be able to do change tracking, this logic has to be added to the poco class, either through subclassing, proxies or through post-compile IL weaving.

in the situation where this isn't possible (i.e. you get a poco class instance from somewhere, e.g. a service), there's no change tracking logic and the o/r mapper framework will assume it's 'new' or that all values have been changed, there's no other way: original values are not known.

This causes problems indeed, all values have to be updated, as they're all seen as 'changed'. Unless an entity object has change tracking on-board and that change info is serialized over the wire (like our framework does in WCF or remoting scenarios), the o/r mapper at hand will have no other choice but to flag all fields as 'changed'.

Persisting entity objects has a price: either you accept that all updates are always full row updates, or you accept your entities are not poco.

Personally I fail to see what's so cool about code first. Sure, you can get started quickly with dumb dto-like classes, but everyone knows that's not what you'll end up with when you release, and how maintainable will that pile of code be at that moment?