Posts Tagged ‘change-tracking’

Interesting distinction.

It boils down to this, an object graph is just “State”. It has no associated “Statement of Intent”.

via Meta-Me : State vs Statement of Intent.

Read Full Post »

Interesting if somewhat scathing discussion of using the Entity Framework for n-tier applications from the developers/designers of the next version of the Entity Framework. The feedback has inspired me to look at nHibernate again, and makes me wonder if the Entity Framework is really as safe a bet as one would assume Microsoft’s implementation of a technology would be.

The first version of Entity Framework provides convenient ways to load, manipulate and persist objects and relationships. As with many other O/RMs, Entity Framework has a state manager that tracks every change made. Existing objects are typically loaded first from the database, later modified, and finally the changes are saved back to the store.

Another feature, full graph serialization, makes it very easy for developers to ship around object graphs representing snapshots of the current state of the world, across execution boundaries.

The next version of Entity Framework will also support Persistence Ignorance. Therefore object graphs can now be made of POCO instances, which WCF now also supports.

Nonetheless, there is a task that belongs in any N-Tier application that still requires a great amount of work for developers using EF: decoding messages that represent state changes performed by the client, meant to be processed or persisted by the service.

via Entity Framework Design : N-Tier Improvements for Entity Framework.

Read Full Post »