Share via

Entity Framework FAQ: Serialization and Web Services

  • Article

    [[articles:Entity Framework FAQ|Back to EF FAQs Table of Contents]] 

Is Entity Key serializable?

Yes, Entity Key is serializable. In addition, if you serialize one of the generated entity classes, its key will be serialized with it, and if you serialize an EntityReference that has associated relationship information, the EntityKey of the related entity will be serialized along with it.

 

The Entity Framework will, by default, generate classes that are binary serializable, and if you are using binary serialization, an entire graph of related entities will serialize at once. This is the default behavior, for instance, if you add an entity to the ASP.NET view state. Similarly, DataContract serialization will by default include entire graphs of entities. If you want to use XML serialization, though, the EF will only "shallowly" serialize, meaning that you will get a single entity and not the graph of related entities. For more information, see Serializing Objects (Entity Framework).

 

Is it possible to serialize the ObjectContext?

No. Starting with EF 4, self-tracking entities can help you track changes in any tier. For information see Building N-Tier Applications.

 

What about WCF Data Services?

WCF Data Services can facilitate automatic creation of a REST-oriented web service that easily exposes data from your EF model in a form suitable for use in a variety of client scenarios. Check out http://blogs.msdn.com/astoriateam/ and ADO.NET Data Services Framework Overview for more information.

 

Does ApplyCurrentValues/ApplyOriginalValues (ApplyPropertyChanges in EF 3.5 SP1) affect EntityReference properties? How do I merge a modified graph of entities back with my ObjectContext

There are many scenarios where it is interesting to load an ObjectContext with the original state of some entities and then update that context to match a set of changes to those entities, where those changes were made elsewhere so that the context was not able to track the changes as they happened. Web services and ASP.NET web pages are particularly common examples of these scenarios because the client often has access to the data sent from a mid-tier machine but does not have direct access to the database, and so probably doesn't have an ObjectContext and likely isn't even running the Entity Framework.

Starting with EF 4, self-tracking entities can help you track changes in any tier. In EF 3.5 SP1, the only option for merging entities attached to the context with entities modified outside of the context was to use the ApplyPropertyChanges method (starting with EF 4 you should use ApplyCurrentValues or ApplyOriginalValues instead). For more information, see Building N-Tier Applications.

The ApplyCurrentValues or ApplyOriginalValues method on ObjectContext can be used to efficiently compare an entity already attached to the context with an entity that is not attached, and to update the attached entity to match while tracking those updates as if the property setters had been called on each property. ApplyCurrentValues/ ApplyOriginalValues only operates on a single entity at a time, though, and it only applies changes to "regular" properties of the entity. By regular we mean that it doesn't apply to navigation properties, and it doesn't apply to non-persisted properties added in a partial class. For more information, see How to: Apply Changes Made to a Detached Object (Entity Framework).

If you need to apply changes to an entire graph of objects, then you need to walk the graph yourself and call ApplyCurrentValues or ApplyOriginalValues on each modified entity. If there are entities that are new or should be deleted, then you need to track that information in a form other than a modified graph, because only having the new graph doesn't include enough information to determine the state of all the entities. When a graph is attached, the ObjectContext will maintain that information, but when the graph is detached you need some other mechanism to track that information. One solution that works for some applications is to use a single key property and interpret certain values that are not valid keys as meaning something about the state (maybe an ID of 0 means an entity is new and -1 means it should be deleted). Another possibility is to add an entity state property to the entities and maintain that property yourself when the entity is detached. In either case, you can then walk a graph, look at that extra information and use it to call ApplyCurrentValues/ApplyOriginalValues, AddObject, or DeleteObject on the context.

 

What are some considerations for choosing between self-tracking entities and WCF vs. WCF Data Services?

Here are some things to consider:

  • WCF Data Services is dependent on the HTTP protocol. Self-tracking entities and Data Transfer Objects (DTOs) are based on WCF, which means they can be used with any underlying protocol.
  • WCF Data Services, as a REST-based technology, is oriented toward resources versus operations. It is a great technology if you care about creating ad-hoc queries using a LINQ provider that translates a LINQ query into a URI that is passed to a data service. If on the other hand, you would rather not expose your model to ad-hoc queries against tables, self-tracking entities or DTOs are a better choice for you.
  • For scenarios where you want to have a single service with many different clients, WCF Data Services is a more suitable choice, because it is designed exactly for situations where you want to create an ecosystem of clients for a service. With WCF Data Services you get the [[OData]] protocol, which can be used with JavaScript, PHP, iPhone clients, and so on. The flip side, though, is that you get less flexibility / control in your operations because you fit your system into the constraints of the REST-oriented protocol, which gives you interoperability at the expense of flexibility. However, if you know that all the consumers of your service are .NET Framework-based, then WCF with STEs is a suitable alternative. This option gives you more flexibility but doesn't work so well for other platforms.

 

[[articles:Entity Framework FAQ|Back to EF FAQs Table of Contents]]