Frans on ORM

Frans has finally pulled the discussion out of SOA land back to DB land. With his post "Why change-tracking has to be part of an entity object."

I'm looking at the original post that started this debate, and I must say that it sounds like everyone is blowing everything out of proportion. In fact, the reason Daniel Simmons posted the description of the entity framework was precisely because someone at MSFT was concerned about performance issues if the entity framework did have implicit change tracking forced upon every object:

"Recently a fellow Microsoftie posted a question on an internal discussion list asking about building an n-tiered, stateless application.  In particular, they were wondering about how the Entity Framework computes update statements.  They assumed that it keeps a copy of the original values and were concerned that such a mechanism would be incompatible with their target architecture."

Daniel goes on to explain that the default mechanism is that the entity framework has property change notifications that handle everything for you. However, there is another approach where you can explicitly manage the changed values yourself and pass directly to the framework which values have changed on an entity so that you can have complete control over the memory usage and concurrency issues. Now, I might have missed something, but I don't see what all the fuss is about. As far as I can tell, Daniel never said you have to roll your own change tracking solution, just that you have the option to do so.