Self-Tracking Entities in the Entity Framework

Self-Tracking Entities

Meta-Me — Tue, 24 Mar 2009 05:09:52 GMT

Lots of the feedback we got on the EF design blog about our early N-Tier plans , highlighted that lots

New posts on EF Design Blog

Jaroslaw Kowalski — Tue, 24 Mar 2009 05:42:17 GMT

I’d like to turn your attention to two blog posts on EF Design Blog about exciting new features planned

re: Self-Tracking Entities in the Entity Framework

Johan — Tue, 24 Mar 2009 12:26:30 GMT

Sounds great! Any plans for a beta/ctp?

re: Self-Tracking Entities in the Entity Framework

onemenny — Tue, 24 Mar 2009 14:06:57 GMT

Sounds great to me too. This is the most important feature to me since working with the entityBag or any other solution led to a big BIG mess...

although i didnt understand how the "self-track-entities" will integrate with poco :(

re: Self-Tracking Entities in the Entity Framework

KristoferA — Tue, 24 Mar 2009 14:24:56 GMT

@onemenny , @jaroslaw how about making "self-tracking" an inheritable base class (for poco).

e.g.:

[Entity]

public class MyEntity : ChangeTrackedEntity

{

[Member("ID")]

public int id { get;set;}

}

Entity Framework Design : Self-Tracking Entities in the Entity Framework

DotNetShoutout — Tue, 24 Mar 2009 15:45:39 GMT

Thank you for submitting this cool story - Trackback from DotNetShoutout

re: Self-Tracking Entities in the Entity Framework

onemenny — Tue, 24 Mar 2009 15:48:14 GMT

Kristofer - i think it better be an interface of some kind or a wrapper class (injection), since it can mess with your domain model...

re: Self-Tracking Entities in the Entity Framework

JasonBSteele — Tue, 24 Mar 2009 17:26:46 GMT

Fantastic news!

It seems to me that this would be best implemented in an interface. In that way it could be used more generally and even by other ORMs.

It could be really handy for generic change logging?

re: Self-Tracking Entities in the Entity Framework

Marco Wolff — Tue, 24 Mar 2009 17:53:39 GMT

This DTO's with self tracking are not inherited by a special base class? This DTO's for the client should know nothing about the framework they will persisted with.

What is about a kind of client side-tracking collection? Kind of EntityBag? This collection knows all entities and tracks all changes client side. For updating the entities, this collection calls serveral service-functions for updating, saving and deleting.

Also see http://msdn.microsoft.com/en-us/magazine/dd263098.aspx.

Thank you,

Marco

re: Self-Tracking Entities in the Entity Framework

lynn eriksen — Tue, 24 Mar 2009 18:43:53 GMT

Jeff, the scenario-based overview sounds great but I think a bit of elaboration is needed on how this would work with POCO.

Based on what I have seen for the vNext release I would like to

1) poco entities that are self-tracking

2) shared library of these poco objects across tiers

3) use the new "agile" method of creating an object context using attributes instead of .edmx

How would self-tracking entities work in this scenario?

re: Self-Tracking Entities in the Entity Framework

dsoltesz — Tue, 24 Mar 2009 20:40:06 GMT

This is exactly what we need. Looking forward to seeing this.

re: Self-Tracking Entities in the Entity Framework

James Hancock — Tue, 24 Mar 2009 21:46:59 GMT

Excellent!

However we also need Validation capabilities

And the ability to chain specific commands to Save.

I.e. I have an invoice

I need to validate the invoice, the invoice line items.

This should not fail with an exception, but report the error and allow all data-bound objects to automatically report the errors.

Further, once the invoice is saved, I need to check the state of the invoice. If it's set to post, I then need to post the G/L entries for the invoice to the database. This has to be done only on successful save, no where else.

There should be events for all of these things in this model:

Saving (CancelableEventArgs)

Saved(EventArgs)

If I had this, along with the ability to easily inherit from my own base class, I would be set (mostly)

re: Self-Tracking Entities in the Entity Framework

lynn eriksen — Wed, 25 Mar 2009 00:43:42 GMT

@James Hancock

James, I think a "ChangeInterceptor" similar to what is in ado.net data services would work for this.

Client side change-tracking data structures in .NET

Andres Aguiar's Weblog — Wed, 25 Mar 2009 05:10:24 GMT

A couple of years ago I was involved in a couple of threads about doing change-tracking in client-side

re: Self-Tracking Entities in the Entity Framework

Jeff — Thu, 26 Mar 2009 02:53:52 GMT

@onemenny, @kristofera

We want self-tracking entities to be POCO entities in that they have no special dependency on the Entity Framework or any of its base classes. In .NET 3.5SP1 the only options you had were to derive your entities from our EntityObject class or to implement interfaces that are specific to the Entity Framework (IEntityWithRelationships, for example). That is decided not POCO because you are forced to have a dependency between your domain classes and the EF, which depending on your scenario may not be desirable. So having self-tracking entities require a base class or an interface that is part of the Entity Framework assembly would fall into the “not very POCO” category, and we want to avoid that.

It is likely that we will have an interface for self-tracking entities, but the interface would exist as part of your code-generated template for self-tracking entities so the interface would be specific to the assembly containing your domain classes, not the EF assembly. However, that may not be POCO enough so we are exploring other options as well, including using some dynamic way of “discovering” certain properties on your entity that contain change tracking information. We could also look at different dependency injection techniques (such as dynamically generated proxies), but those can be very hard to deal with in serialization scenarios. I will follow-up with a post on what we can expect the entities to look like, but for now the important point is that we will not require an interface or base class that is part of the Entity Framework to use self-tracking entities.

re: Self-Tracking Entities in the Entity Framework

Jeff — Thu, 26 Mar 2009 02:57:36 GMT

@lynn

Our hope is that you’ll be able to accomplish those three things. Self-tracking entities do not have a dependency on the Entity Framework, so they are POCO in that way. However, there still needs to be logic in that class that can do the self-tracking bit. Our goal would be that this is simple enough to write and could be used with agile approaches, even ones where you may not have a model (or database) yet. If you already have a model, then you can use the T4 template that will generate self-tracking entities to get started.

re: Self-Tracking Entities in the Entity Framework

Jeff — Thu, 26 Mar 2009 02:59:45 GMT

@James

In the next release, the ObjectContext's SaveChanges method will be virtual so you'll be able to do this kind of validation in your ObjectContext class.

re: Self-Tracking Entities in the Entity Framework

lynn eriksen — Thu, 26 Mar 2009 09:05:35 GMT

@Jeff

Jeff, looking forward to your follow on.

For my two cents, anything you can make happen with the use of attributes is a plus.

re: Self-Tracking Entities in the Entity Framework

dsimmons@microsoft.com — Thu, 26 Mar 2009 16:51:03 GMT

@lynn,

One dilemma with using attributes is that the attribute classes need to be defined somewhere which causes a dependency issue...

- Danny

re: Self-Tracking Entities in the Entity Framework

shawn — Fri, 27 Mar 2009 05:14:16 GMT

I'd like to second James' request for entity-specific partial methods or events when saving an entity. Having "OnSaving" and "OnSaved" hooks to tie in logic when a single specific type of entity is saved and you want to take some additional action (like saving an audit record or recalculating a cached value) would be really useful. Having the ability to hook in to this type of event for each entity class could be preferable to overriding the ObjectContext's catch-all SaveChanges method to implement this type of entity-specific logic.

We've used the OnValidate method in Linq2Sql quite a bit and wish we had something similar for OnSaving and OnSaved to help complete the validation picture.

Speaking of which, it could also be handy to be able to somehow get access to the current ObjectContext from within an entity. So for example:

OnValidate(EventArgs e) {

// validate that the email isn't already in use

var existingCustomer = this.CurrentObjectContext.Customers.SingleOrDefault(o => o.Email == this.Email);

if (existingCustomer != null) throw new ValidationException("A customer with that email already exists!");

}

OnSaving(EventArgs e) {

// add a log of this transaction

e.ObjectContext.AuditLogs.Add(new blah);

}

Perhaps if it isn't possible from anywhere within an entity, it could at least be made accessible from the event/method arguments for certain things like validation.

This would allow you full access to the database when an entity is validated or saved, which would be extremely useful in certain architectures.

re: Self-Tracking Entities in the Entity Framework

Vijay Santhanam — Fri, 27 Mar 2009 06:22:17 GMT

I need to do more reading to understand the new EF.

Thanks MS for making the process more transparent.

But as a LINQ 2 SQL guy, things like this scare me

Include("Orders.OrderDetails")

Why are there strings in Data Tier like this? this seems like a C#3 fail to me. Surely you can use lambda expressions to capture these includes and memoize them for speed.

re: Self-Tracking Entities in the Entity Framework

lynn eriksen — Fri, 27 Mar 2009 07:30:44 GMT

@ Danny

Understood about attributes.

Since this is a major release release might it be possible to get a set of generic enough attributes for your purposes somewhere in the system dll, perhaps under System.ComponentModel or sub namespace?

re: Self-Tracking Entities in the Entity Framework

Diego Vega — Fri, 27 Mar 2009 08:00:17 GMT

Vijay, we agree that lambda expressions could provide a nicer syntax for Include (although for multi-level paths, the lambda-based syntax becomes more complicated than the string version). In any case, at this point it doesn’t look like this improvement will make it in.NET 4.0. We appreciate your feedback.

re: Self-Tracking Entities in the Entity Framework

shawn — Fri, 27 Mar 2009 10:26:56 GMT

@Diego

That's too bad, it would be really nice to have lambda-based syntax for Include. I thought getting rid of "magic strings" and having compile-time checking of queries was one of the main purposes behind LINQ. :(

I'm definitely another person who would love to see strongly typed Include statements make it in sooner rather than later. It has always seemed out of place using strings there.

re: Self-Tracking Entities in the Entity Framework

Roger Rudin — Fri, 27 Mar 2009 11:43:11 GMT

A change tracking mechanism would be very nice in Entity Framework but I venture to doubt that the solution of self tracking entities can solve the problem.

Tracking properties on entities would be a good start, but who is responsible to set this properties?

Self tracking entities must have behavior to track its change state.

Can you tell me how this can work without shared library of these poco/self tracking entity objects across tiers when using a modern technology like webservices or wcf over metadata contracts.

And whats about interoperability? How can a java client consuming a webservice and track the change state of the entities?

re: Self-Tracking Entities in the Entity Framework

Omari — Sat, 28 Mar 2009 20:11:58 GMT

I think you should change name of the Delete method to MarkAsDeleted.

re: Self-Tracking Entities in the Entity Framework

Merle — Sun, 29 Mar 2009 21:54:33 GMT

Based on my experience with EF on a real project it's very good approach. One of the problems we were working hard to accomplish is dealing with long-living entities that has to leave for a few http requests. It's not a good solution to keep EF context so long so we found workarounds here. Now it's not a problem anymore.

However, there is one question. If such entity is formally "detached" from the context how will the lazy loading (implicit or explicit) work? Based on your example with Include("Orders.OrderDetails") it looks like we will need to create the whole graph we are going to work with from the database. If it's incorrect I can see 2 solutions:

1) Implicit creation of the EF context and filling the navigation properties (then what about POCO?)

2) Explicit passing the EF context to some sort of lazy loading method and using it

Which way (or probably the third one) would you use to implement this?

Thank you.

Entity Framework vNext: сущности, сами отслеживающие свои изменения

Александр Кондуфоров — Sun, 29 Mar 2009 22:14:50 GMT

Команда ADO.NET продолжает свой эксперимент по публичному проектированию следующей версии Entity Framework

re: Self-Tracking Entities in the Entity Framework

ManojR — Mon, 30 Mar 2009 01:18:37 GMT

Will there be support for filtering entities while traversing relationships? (E.g. Ability to add lambda-based filtering for the Load method).

Consider this Relationship:

Customers -> Orders -> OrderDetails -> Products

Use Case: Get all related entities for the following conditions: All customers in a particular zipcode; select their orders that were created within the last 6 months; For those orders, select only those order details with amount > $100; for these order details, select the corresponding products. (This filtering could be done in memory, but the data set size may be too prohibitive)

In EF V1.0, there are a few ways to accomplish this, but they seem to either result in multiple trips to the database or involve multiple steps (fetch more data than needed and then remove them) or involves repeating all the conditions for each of the predecessors in the children's LINQ queries (in one sense, the problem could be defined as trying to fetch related entities for objects already in the entity conext -- applying additional filters and get related entities in one trip to the database per each related entity type) .

The main explicit methods available in 1.0 for getting related entities are Include and Load. Both of them don't seem to support additional filtering. I would prefer to get this filtering support added to either the Load method or to the child's LINQ query. (the include method is less preferrable because of the use of strings).

re: Self-Tracking Entities in the Entity Framework

Eugene — Mon, 30 Mar 2009 15:42:17 GMT

Interesting -

I have a large project implemented using self tracking entities. These entities travel between tiers using web services. While its a viable solution, one pitfall that always comes up is that after doing an update, a new object comes down from server. All references now need to be updated. This becomes really challenging with data binding and events. Events have to be non serialized, and you have to have compensating code to reconfigure events.

I am intrigued by the RIA services solution to some of these problems. I am sure there are some new pitfalls in that solution, but have you guys considered looking at it for ideas? Especially since its a MSFT technology?

re: Self-Tracking Entities in the Entity Framework

Jeff — Mon, 30 Mar 2009 20:15:59 GMT

@Roger

For solutions using self-tracking entities, the entity definition itself contains information on what changes have been made. So the self-tracking entity definition must exist on both the client and the service. The entity definition does not contain any reference to a particular persistence framework; the change tracking information is something like a List<object> AddedRelationships, where “object” is an Order entity, or a Product entity, or some other entity that can be related. There is logic inside the self-tracking entity that records these changes automatically whenever properties change. The client can make changes to a property any way they want: directly, through data binding, etc., and each change triggers the self tracking entity to change state, or record a new or removed relationship.

Self-tracking entities are also interoperable because there is a very clean WSDL description of each entity containing the current entity property values plus the change tracking information which is likely to consist of a state value (Add, Modified, etc.), as well as the state of various relationships to other entities (AddedRelationships: this with reference to O1). Java clients could produce a similar payload to send to services that accept self-tracking entities as part of their data contract. As with any interoperable solution, the non-.NET client would need to actually mimic that payload. One of our goals is to make the payload as clear as possible so that this can be done easily.

re: Self-Tracking Entities in the Entity Framework

Jeff — Mon, 30 Mar 2009 20:20:54 GMT

@Eugene

The problem you describe is something that is not baked into the self-tracking entities pattern directly. The issue boils down to being able to effectively do identity resolution on your client for round tripping. This is needed for many operations and is especially important when “bulk refreshing” your data binding is not possible (or, as you said hooking p events). There are some other solutions we are thinking about, such as an evolution of EntityBag that give you this sort of capability. If you are interested I can give you more details here. We are also working with the RIA Services teams to make sure that entities work well with their client side change tracker.

re: Self-Tracking Entities in the Entity Framework

Jeff — Mon, 30 Mar 2009 20:27:06 GMT

@Merle

Lazy loading requires a way to inject knowledge of an active context into an entity. On the service tier this is possible because this is logically where you’d want to create contexts, query for entities, etc. When you define your self-tracking entities, our cue to turn on lazy loading is to make the navigation properties virtual (references and collections to related entities). You are correct that using lazy loading in a detached setting is difficult. This wouldn’t work on the client because in many cases you do not to create active contexts on this tier that provide a direct line of sight to your database. However, once you return the entity to the service tier, you can attach it to a context (context.Customers.Attach(…)) and perform lazy load. Are you asking about doing lazy load on the client?

re: Self-Tracking Entities in the Entity Framework

Merle — Mon, 30 Mar 2009 22:54:02 GMT

@Jeff

> Are you asking about doing lazy load on the client?

Not actually. It's clear that it's impossible to get the lazy loading work on the client when you don't have the ObjectContext at all (except additional query to the server). I was asking about the server-side solution. I thought when you create the self-tracking entity it is automatically detached from the ObjectContext it was created with to avoid any side-effects and be a POCO object. Is it correct assumption? If it's correct then it might be difficult to work with this entity using entity.Collection.Load() if you haven't load it's navigation collections when you get this entity from the context. That's why I asked about the possibility to inject the different ObjectContext to the entity so it can be used to retrieve this data afterwords or some other solution you came up for this situation. Could you please tell me whether my assumption is correct and what would you suggest for such scenario? Thank you and keep up a great work!

re: Self-Tracking Entities in the Entity Framework

Eugene — Tue, 31 Mar 2009 23:15:45 GMT

@Jeff -

Thanks for the reply. If you are willing to share more info on Entity Bags I would be interested in learning more.

As for you analysis of my problem, I agree, its larger than just self tracking entities. However, from the reading/playing that I have done, I think the RIA services team is delivering more than self tracking entities as well.

They are using code generation to create "client side" objects and then have some base classes that move data back and forth. This means that the actual objects no longer need to travel back and forth, which makes the event hookup / data binding / reference updating easier.

These client side objects do track their state though, and there can still be shared code between the client and the server to do validation and business rules.

I guess it just seems to me like you guys are both implementing pieces of an ntier solution. I think the 2 can plug in and play.

Eugene.

Building N-Tier applications with the EF – The Basics

system.data.objects dev guy — Thu, 09 Apr 2009 08:08:01 GMT

Today I was looking at a post in the forums where someone asked a very natural and common question about

re: Self-Tracking Entities in the Entity Framework

Remi — Tue, 21 Apr 2009 03:57:16 GMT

One quick question, while I'm wrapping my mind around this post...

What is the distinction between "ApplyChanges" and "SaveChanges"? Is it the difference between persisting to the model and persisting to the database?

re: Self-Tracking Entities in the Entity Framework

dsimmons@microsoft.com — Tue, 21 Apr 2009 09:49:51 GMT

@Remi,

Yes, the distinction between ApplyChanges and SaveChanges is something like that. The context has an ObjectStateManager which keeps track of changes that need persisted to the database and provides that information to the rest of the EF. Since the context and state manager don't serialize with the entities, we need a way to push changes from the self-tracking entities into the context so that when you call SaveChanges the database will be updated.

- Danny

re: Self-Tracking Entities in the Entity Framework

syl74 — Fri, 24 Apr 2009 12:22:18 GMT

I agree that it looks like an other approach to ntiers solution than the one of RIA services team. I hope it's not going to be like EntityFramework/LINQToSql competition !

Questions :

Is the RejectChanges() scenario will be supported by your SelfTrackableEntities ?

Is the validation messages will be also supported. TrackableEntities implementing IDataErrorInfo that read messages in the inherited tracking info datamember (filled by the server that has the business logic to apply the validation rules ) ?

By the way, we really need a IDataErrorInfoEx that includes the notion of severity of the message (error/warning/info)

re: Self-Tracking Entities in the Entity Framework

syl74 — Fri, 24 Apr 2009 12:26:46 GMT

For the include statement that should be in strongly typed Include statements instead of "string" we use the following solution :

http://blogs.msdn.com/stuartleeks/archive/2008/08/27/improving-objectquery-t-include.aspx

Entity Framework, DTOs e Self-Tracking Objects

Arquitetura em Pauta — Thu, 30 Apr 2009 19:12:55 GMT

O último post do time do Entity Framework é bem interessante no contexto dos assuntos discutidos neste

re: Self-Tracking Entities in the Entity Framework

Otavio Pecego Coelho — Thu, 30 Apr 2009 19:48:20 GMT

I'd love a mix of DTOs and tracking. It can be one more option for the next version.

DTO's can protect us against errors at the client side, like updating a field that should be not reacheable in that context. That's what OO is all about.

regards

Sneak Preview: N-Tier development with Entity Framework 4.0

ADO.NET team blog — Thu, 14 May 2009 21:28:19 GMT

Building applications that work across tiers is a core part of many application architectures. In .NET

Entity Framework in a SOA environment

David Birin's blog — Sun, 17 May 2009 09:42:23 GMT

I received a mission to explore entity framework as a DAL for a new project, this project is intended

re: Self-Tracking Entities in the Entity Framework

Paul Marshall — Thu, 21 May 2009 00:37:26 GMT

This framework sounds very similar to the CSLA.NET. Is this true?

re: Self-Tracking Entities in the Entity Framework

Jon Rista — Sun, 24 May 2009 05:45:07 GMT

While I can see the usefulness of self-tracking entities in a pure Microsoft stack, what options to we have for managing change tracking in a true SOA environment with a hybrid of different technologies, including .NET, Java, AJAX calls from web clients, etc?

Self-tracking entities are great when your always working with .NET on both sides of the wire...but more and more, the client tends to be something else...Java or Javascript/AJAX most frequently in my experience.

Is our only option to attach the entity as fully changed, and save the whole thing? Or is there a more efficient option?

re: Self-Tracking Entities in the Entity Framework

dsimmons@microsoft.com — Sun, 24 May 2009 06:24:09 GMT

@Jon,

While self-tracking entities are aimed at making especially easy scenarios where .Net is available on the client, we have also been giving some thought to interop. The intention is that the serialization XML for the entities (including the tracking information) will be very clear and easy to work with in other platforms. You will have to write client code which does tracking and supplies the tracking info ina compatible format, but that should be possible.

We have been debating about just how much change tracking information to include. Certainly we will include information about the state of each entity and about the relationships between them, but we originally thought we would avoid tracking exactly which properties of an entity were modified and instead just plan to send the whole entity to the database each time (very reasonable in many situations but not for some). This is what you are likely to see in the first CTP of self-tracking entities, but we're now leaning toward the idea that the long-term plan will be to include original values for properties in the change-tracking info so that only the modified properties would be sent to the database on a save.

- Danny

NTier with Entity Framework 4 Beta 1 - (VS2010 / .Net Framework 4.0 Beta 1)

Rowan's Tech Blog — Tue, 26 May 2009 05:28:13 GMT

This post runs through a simple demo of the new N-Tier focused APIs in the in ADO.Net Entity Framework bits (EF4) that are included in Beta 1 of Visual Studio 2010 / .Net Framework 4.0. For this d ...

NTier with Entity Framework 4 Beta 1 - (VS2010 / .Net 4.0 Beta 1)

Rowan's Tech Blog — Tue, 26 May 2009 06:08:39 GMT

re: Self-Tracking Entities in the Entity Framework

Jon Rista — Tue, 26 May 2009 07:53:02 GMT

@Dan Simmons,

Thanks for the reply Dan. Good to know your trying to keep change tracking open. While I personally prefer to work in an entirely .NET stack, other individuals at a higher pay grade often take that decision out of my hands. I've been both lucky (expanding my horizons), and unlucky (having to deal with cross-platform implementation issues and complexity), enough to be working in a hybrid .NET/Java environment these days. So an open, simple format is good news.

In response to something you mentioned in your reply, I am curious if you could expand upon it a bit more. If the intention with self-tracking is to provide a simple and open format that any client could use to transfer state-change details back to a service with...then the following statement confuses me a little:

"This is what you are likely to see in the first CTP of self-tracking entities, but we're now leaning toward the idea that the long-term plan will be to --> include original values for properties in the change-tracking info so that only the modified properties would be sent to the database on a save. <--"

When it comes to...disconnected change tracking, is the concept of "original value" really useful, or is it just a waste of space and bandwidth? We have a full entity, and it will be tracking its own changes. I don't think that knowing the original value as well as the current value matters as much as knowing that the value changed. Differentiating between the current value and a value that is being set, and not flipping that "changed" bit in the event the two values are equal, should be the responsibility of the self-tracking entity its elf (regardless of platform). Correct?

We can bloat the self-tracking entity message schema to track original values, but it seems more logical to simply track a map of which values have changed. The end goal is to overwrite whatever value is in the database anyway, so the original value has no meaning. A change conflict could be detected by a database-level version (i.e. SQL Server rowversion/timestamp), thus preventing last-in-wins, correct? Is there something I am missing that would make original values useful in the self-tracking context?

re: Self-Tracking Entities in the Entity Framework

Jon Rista — Tue, 26 May 2009 08:02:15 GMT

To expound a bit more on why I think tracking original values could be wasteful (because I'm sure some will say it wouldn't be that much space/bandwidth.) I am thinking in the context of strings mostly. For example, if I have a Blog entity, which contains an author id, date posted, a list of tags (string, but generally small), and the contents of the blog post itself. Tracking original values for the author id, date, and tags really isn't a huge deal. However, tracking the original value for the contents means I am likely doubling the size of my self-tracking entity message, when all I really need is to know that the contents did, indeed, change. A simple boolean along the lines of: <changes><property name="Body"/><changes> would do the job, and keep things compact. This goes for pretty much any large string value, which occur a lot in things like forum posts, product descriptions, email messages, blogs, digital newspapers (pretty much all text), etc.

Sorry for not clarifying in my previous post.

re: Self-Tracking Entities in the Entity Framework

Daniel Simmons — Tue, 26 May 2009 08:32:29 GMT

@Jon,

Well, you are right that sometimes keeping around the original value is not nearly so interesting as just knowing that the column has changed.

It turns out that this is a rather tricky topic. Sometimes we just want to know a column has changed (like your scenarios above where the original value isn't interesting and the values are large so keeping the original value is wasteful), while other times we really do need to know the original value, and still other times we need the original value, but it's very likely that anyone would change the value since it's a server-generated rowversion or something so keeping the original value is a waste and we can just treat the current value as the original value.

The tricky ones are the middle case (where we really need the original value), and they come up in two scenarios. The first one is when you have a concurrency value that is determined on the client rather than the server. In this case you need the original value to check for concurrency conflicts, but you also need the current value to set the property to if there isn't a conflict. This is unusual because it's hard to do this correctly, usually you want the concurrency value to be automatically generated by the server. The second case is a bit more obscure, but it is possible to create certain mappings where the value of a property can change how the entity is persisted to the database, and in these cases we need the original values so we know how to undo the old persistence and then do the new one--imagine for instance that depending on a value an entity might be persisted in part to one table or to another table. If the value changed, then we would need to remove a row from the old location and add a row to the new one.

It is possible for us to determine most if not all of this information at code generation time from the metadata, so we could generate classes that are more precise in the way that they handle original values to sometimes store them and other times just store a bit indicating that something has changed, but then we start getting into cases where interoperability becomes harder because the wire format becomes more complex. Until now we have favored either going the route of never storing original values which makes for a simple, efficient wire format and simple client classes but rules out some mapping scenarious and can produce less efficient database updates, or always toring original values which still keeps the wire format and client classes relatively simple, and allows for efficient database updates, but makes the wire format less efficient.

Neither of the options seems perfect, but it may be that one or the other is best in light of trying to keep the wire format simple. It's always possible to take our self-tracking template and modify it for more specific needs or to avoid code gen altogether and write DTO classes by hand to handle n-tier for those cases where you need the most flexibility and efficiency for a particular sceanrio.

- Danny

Sneak Preview: N-Tier development with Entity Framework 4.0

Web开发技术 — Tue, 26 May 2009 14:13:23 GMT

  Building applications that work across tiers is a core part of many application architectures

re: Self-Tracking Entities in the Entity Framework

Jon Rista — Tue, 26 May 2009 21:59:49 GMT

@Dan,

Thanks for the clarification. It definitely sounds like a more complex issue that it appears at first glance. I think message efficiency is a very critical factor, especially considering some of the scenarios I mentioned (which, if the "always use original values" route is taken, could effectively halve the overall message throughput in those scenarios.)

I think flexibility is key here...and if there is anything we have all learned from EF v1.0, its that the community needs a great breadth of flexibility to accommodate existing needs. It may make the wire format a bit more complex, but I think neither option 1 (never use original values) nor option 2 (always use original values) is going to be sufficient to meet the needs of everyone involved (including the EF team, who needs to support as many mapping scenarios as possible.)

While I love to use simple formats whenever possible, if a little added complexity will give me the ability to tune my efficiency, I'll take that complexity every time. Limiting my options and not giving me the ability to tweak and tune (i.e. go from just using simple flags to a hybrid of flags and original values where required) is a sure-fire way to make me abandon the rigid, inflexible framework in favor of a more flexible one, or build something in-house that meets my needs.

re: Self-Tracking Entities in the Entity Framework

Jon — Wed, 27 May 2009 00:41:06 GMT

Code generation has been mentioned several times. I'm wondering if it is still expected that you are generating your data model from an existing database, or, is model first supported? i.e. I want to define my database by defining classes and then generating the database from that, a la Hibernate. Is this something that can be done in a pain free way, or, will I be going against the grain and having to implement a lot of methods needed by EF manually?

re: Self-Tracking Entities in the Entity Framework

Jon Rista — Wed, 27 May 2009 05:26:51 GMT

@Jon: I think the following entry from this blog will answer your questions:

http://blogs.msdn.com/efdesign/archive/2008/09/10/model-first.aspx

NTier with Entity Framework 4 Beta 1 - (VS2010 / .Net 4.0 Beta 1)

VS2010学习 — Sat, 06 Jun 2009 05:29:57 GMT

Introduction My blog has been feeling very neglected after my move to the US and I thought with the recent

re: Self-Tracking Entities in the Entity Framework

Ben — Mon, 08 Jun 2009 19:36:57 GMT

Hi!

Is there any release date for the self tracking entities T4 template, or any preview of it?

Thanks

re: Self-Tracking Entities in the Entity Framework

Daniel Simmons — Mon, 08 Jun 2009 23:06:01 GMT

@Ben,

We don't yet have an official release date, but I can help you narrow it down a bit. It's getting close, but it won't be for a few weeks yet.

- Danny

Entity Framework 4.0 Beta新特性

VS2010学习 — Thu, 11 Jun 2009 08:32:59 GMT

  Entity Framework 4.0 Beta 1（又称EF V2）与 .NET 4.0 Beta 1 一起发布，包含了一系列的重要改进：自定义代码生成、延迟加载、N层支持、POCO支持

re: Self-Tracking Entities in the Entity Framework

Graham Hay — Tue, 07 Jul 2009 18:43:50 GMT

This looks like it should solve one of the issues that I have had to handle in my code, but there are a couple of points that I would like to clarify.

As these are self-tracking entities, am I right in thinking that the query in GetCustomer should be a MergeOption.NoTracking query or alternatively that the entity graph needs to be detached manually ?

If I recall correctly (I don't use NoTracking myself), NoTracking queries do not perform identity resolution (and hence there is a possibility of duplicate entities) and also they do not populate EntityReference EntityKey values that are not Included.

Also, am I right that Detaching an entity detaches only that entity and drops all the navigation properties ?

re: Self-Tracking Entities in the Entity Framework

divega — Tue, 07 Jul 2009 18:56:56 GMT

Graham,

Your recollection of the behavior of NoTracking queries and Detach is correct.

Self Tracking Entities, in fact, do not make use of either, at least in mainline scenarios. Instead, it is the work of serialization to create a snapshot of the full graph of tracked entities.

Hope this answers your question,

Diego

re: Self-Tracking Entities in the Entity Framework

Graham Hay — Wed, 08 Jul 2009 10:29:50 GMT

Thanks Diego,

just to confirm, are you saying that entities can be both self-tracking and attached to an object context ?

re: Self-Tracking Entities in the Entity Framework

cowgaR — Fri, 17 Jul 2009 22:28:21 GMT

awesome, I'm just in the middle of the artcile but so excited :) so I have just one question...

why woudn't I want to use self-tracking entities, when it is so coool?

no more UOW problems and referencing it via many tiers with problems where to store it (session) for entities to be reatached later and many other problems than other mappers face...

here, I can code as Conan the Barbarian style, "opening the connection", e.g. "using" Context just when I want to store final entity, and that's it.

I don't need to have it opened all the time, e.g. without "using ctx = ..." I can't do any work right now.

Unless I am missing something this sounds too easy to be real :) must be some drawbacks

re: Self-Tracking Entities in the Entity Framework

Troy Dalldorf — Wed, 22 Jul 2009 01:02:12 GMT

Storing the original values also allows you to handle concurrency issues. So if two users update the same Contact record, the last should fail with something like a RecordChangedByAnotherUser exception.

It would be nice if EF allowed you to specify the WHERE clause for the update. So for example, typically

UPDATE contact SET name=:name WHERE id=:id

what is really needed for concurrency is:

UPDATE contact SET name=:name WHERE id=:id AND lastModified=:lastModified

The Borland ClientDataSet had an option for this:

- UpdateWhereKey - only use the Pk

- UpdateWhereAll - put all the old values in the where

- UpdateWhereChanged - only put changed fields in the where. I don't particularly like this, because two simultaneous updates could occur producing a result that actually violates business rules.

- UpdateSpecify - specify the set of fields to include in the where.

re: Self-Tracking Entities in the Entity Framework

Ryan Riley — Tue, 25 Aug 2009 06:55:13 GMT

I am with cowgaR. Am I missing something? Also, what is wrong with IEditableObject as the interface?

re: Self-Tracking Entities in the Entity Framework

Fredrik Knutson — Fri, 11 Sep 2009 12:17:59 GMT

I agree with Vijay Santhanam and ManojR. Support for filtering when doing Load or Include is one of the things we really missed in EF v1.

How do you recommend one solves such filtering problems?