Entity Framework FAQ
Version 0.6 – 6/5/2008
New in this version of the FAQ…
· Updated: 1.2 Where else should I go to learn more about the EF?
· New: 7.7 Why does deleting an entity from my context not delete all related entities when I have cascade delete defined in the model?
· New: 18.5 Why doesn’t relationship span happen with MergeOption.NoTracking?
· New: 20.6 Does ApplyPropertyChanges affect EntityReference properties? How do I merge a modified graph of entities back with my ObjectContext?
Contents
1................................. Introduction
2................................. Architecture and Patterns
3................................. Business Logic
4................................. Code Generation
5................................. Data Classes
6. ............................... Databinding
7................................. EDM
8................................. EntityClient
9................................. Entity SQL and ObjectQuery Builder Methods
10................................ EntityKey
11................................ Lazy Load and Eager Load
12................................ LINQ to Entities
13................................ Mapping
14................................ Metadata
15................................ Multi-threading
16................................ Object Services
17................................ Performance
18................................ Query
19................................ Resource Management
20................................ Serialization and Web Services
1. Introduction
1.1. About this FAQ…
You can find the latest version of the EF FAQ at http://blogs.msdn.com/dsimmons/pages/entity-framework-faq.aspx. This FAQ which was culled from a number of existing blog and forum posts. There’s no question that there is lots more data which belongs here. If you have further questions (or even better yet contributions), please don’t hesitate to add a comment here so that we can evolve this doc to be an increasingly valuable resource. I don’t have as much time as I’d like to update and add to this document myself, but I’m more than happy to coordinate the process if folks have contributions.
1.2. Where else should I go to learn more about the EF?
There are a number of good resources on the web, but here are a few good starting points:
· The MSDN Getting Started with the EF page: http://msdn.microsoft.com/en-us/data/aa937723.aspx
· The MSDN docs: http://vs2008sp1docs.msdn.microsoft.com/en-us/ms439009.aspx
· The EF forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=533&SiteID=1
· Samples: http://code.msdn.microsoft.com/EFQuerySamples/
· DataDeveloper.net: http://www.datadeveloper.net/
· Blogs from the EF team:
o ADO.Net: http://blogs.msdn.com/adonet/
o Alex: http://blogs.msdn.com/alexj/
o Colin: http://blogs.msdn.com/meek/
o Danny: http://blogs.msdn.com/dsimmons/
o Diego: http://blogs.msdn.com/diego/
o Jarek: http://blogs.msdn.com/jkowalski/
o Ju-Yi: http://blogs.msdn.com/juyik/
o Zlatko: http://blogs.msdn.com/esql/
· Blogs from outside Microsoft with EF topics:
o John Papa: http://johnpapa.net/
o Julie Lerman: http://www.thedatafarm.com/blog/
o Oakleaf Systems: http://oakleafblog.blogspot.com/
1.3. Why use EDM? How does the EDM help?
The Entity Framework enables developers to reason about and write queries in terms of the EDM model rather than the logical schema of tables, joins, foreign keys, and so on. Many enterprise systems have multiple applications/databases with varying degrees of normalization, different schema styles depending on the group that developed it, and different naming conventions for tables and columns. Furthermore, in complex systems the entities of interest may be scattered across multiple rows in multiple tables, and changes to the logical schema can be painful to track within applications. By adding an additional level of abstraction, the EDM insulates the developer from the low level details of the logical model, and frees them to focus on the essential aspects of the application/problem at hand.
Pasted from < http://blogs.msdn.com/adonet/archive/2007/05/30/entitysql.aspx >
1.4. How can I get the bits?
Step 1: Install .Net 3.5 RTM / VS 2008 RTM.
Step 2: Download and install the SP1 Beta: http://msdn.microsoft.com/en-us/vstudio/cc533448.aspx
1.5. When will the Entity Framework be released?
The EF is available now as a public beta. The final release of v1 will happen sometime this summer.
2. Architecture and Patterns
2.1. Does Entity Framework have support for entity objects being responsible to save changes themselves (rather than a central Save method on object context)?
This is something we considered but in the end rejected in favor of the broader "unit of work" pattern where you can make changes to a series of related objects and then save them all at once. This is particularly useful when you are modifying relationships between entities or making changes to multiple entities that you want in a single transaction. You could do manually transaction management either way, but the default transactions that the entity framework supplies cover a large number of scenarios. You could, of course, with some work maintain a reference from your entities back to the objectcontext they go with and add a Save method to the entities, but it would still save all the outstanding changes on the context so that would probably be confusing/error prone. So this is an area were we don't directly support, but arguments can be made for either approach.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
2.2. Does Entity Framework have support for "Persistence Ignorance"? What is Persistence Ignorance? What is POCO? IPOCO?
Definitions:
· Persistence ignorance is the general term for how much knowledge the objects must have of the persistence layer. In this case we talk primarily about “complete persistence ignorance” which is a step further than POCO in the sense that you’d like to be able to say that you can create an assembly of domain objects where that assembly doesn’t have any reference to a persistence stack at all, and then just by adding a small amount of code/configuration on the outside you can persist those objects.
· POCO is basically the idea of having plain CLR objects which do not have special requirements in order to work with a persistence stack like the EF. In practice this primarily talks about not requiring that the objects inherit from a particular base class and that they not be required to implement a particular interface. In many systems, though, you might say that they support POCO but still require something like attributes on the classes or other things in order to help convey some information to the persistence stack. The point, though, is that the domain objects don’t have to change substantively to support persistence so they are cleaner for remoting to other tiers, it’s easier to switch to another persistence stack at a later date, etc.
· IPOCO is a subset of POCO which says that the objects don’t have to inherit from a particular base class but they either gain some benefit from implementing certain interfaces or may even be required to implement those interfaces.
· Prescriptive classes or generated classes represent the other end of the spectrum. In these scenarios, the classes typically inherit from a particular base class which works directly with the persistence layer. In many cases the classes are auto-generated from a model of some kind and users can then extend them using partial classes or the like. Prescriptive classes have the disadvantage of being more tied to the persistence layer, but they tend to have advantages when it comes to performance as well as providing a broader set of services to the app developer that they would otherwise have to write themselves.
The EF started out as a framework which only supported prescriptive classes. Based on customer feedback we decided that it would be very important to support a greater degree of persistence ignorance for some scenarios, but we also believe that the prescriptive classes are great for other scenarios. So, we expect that overtime we’ll need to support this whole spectrum.
For the first release of the EF, we will support prescriptive classes and IPOCO. That is, you can have classes that do not inherit from our base class, but they must implement certain interfaces and they must have specific attributes in order to work with the EF. Right now there is a set of three interfaces, of which one is required (IEntityWithChangeTracker which is used for the object to communicate to the EF when the values of its properties are changed), one is required for any object which participates in persisted relationships (IEntityWithRelationships -- of course almost every object in a real system will participate in relationships so this one is pretty much also required), and one which is optional (IEntityWithKey – if you implement this then your object must have a property for storing the EntityKey, but in return parts of the system become faster/easier).
In future releases, we will work to make the remaining interfaces optional as well as to make it possible not to have any specific attributes on the classes but instead to specify all of that metadata in some other form outside the assembly containing the classes that will be persisted, but we were just unable to get all the way there in the first release.
2.3. Is it recommended to share one global ObjectContext instance across my application?
It depends on the scenario. For single-threaded rich-client applications sharing a global ObjectContext may make sense--it may even provide advantages since identity resolution will reduce the number of in-memory objects as they are re-used across queries. You do have to be careful, though, to carefully manage the memory consumption of your application, because the ObjectContext will maintain a reference to every entity retrieved through it unless you use a NoTracking query or explicitly detach it.
For asp.net and web service applications, we generally don't recommend sharing a single global ObjectContext for a number of reasons, including threading issues (ObjectContext is not thread-safe), working set (since the context keeps references to objects retrieved through it as mentioned above), and data consistency (as the data in the database evolves over time it can get out of sync with the data in your local objects unless you explicitly query with an OverwriteChanges MergeOption).
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2371610&SiteID=1>
3. Business Logic
3.1. How to write a custom logic behind a "getter" or "setter"?
A lot has been done in Entity Framework to support adding business logic to the setters of the generated classes. With the introduction of partial methods for property changing and property changed users can write their custom business logic. Currently we don't have a plan for partial methods for the getters, but again you can write your own classes rather than just using the generated classes. One simple way to write your own classes is to let the system generate the classes for you once and then modify those and don't generate after that. Or you can completely write your own classes (IPOCO is the information you want to look for in the documentation). If you don't want to write your own classes, you can customize the code generation process to add additional statements to either the getters or setters.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
3.2. Is it possible to write logic which distinguishes between user code calls to the data class and framework materialization of the class?
Unfortunately there isn't a system in place to allow you to easily distinguish between cases where the system is materializing an entity and user code is calling a constructor or setter. That's something we've talked about adding but currently is unlikely to make v1.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2301046&SiteID=1>
3.3. How to execute custom code on SaveChanges call?
ObjectContext has a SavingChanges event which is fired whenever SaveChanges is called on the context before any changes are persisted to the database. There is also an OnContextCreated partial method which is called from the context constructor and can be used to subscribe a handler to that event. This event handler can be used to enforce business logic which involves multiple entities.
3.4. How do I write business logic which validates interactions between multiple properties on an entity?
Entity Framework allows creating a Validate method that can be overridden for every concrete type in the system. Here is how to do it:
1. Create an abstract type in your model from which all of your concrete types inherit or an interface which all of your entities will implement on their partial class. Add to the abstract class or interface a Validate method which can be overridden in the various concrete classes as appropriate.
2. Create an event handler for the SavingChanges event on the object context which goes through all of the inserted or updated entities (found by examining the ObjectStateManager) and calls the Validate method.
In future releases we'll look into ways to make this even easier for generated classes using partial methods and other mechanisms.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
4. Code Generation
4.1. How can I add custom attributes to my generated classes? What is the extensibility story in Entity Framework for more advanced code generation scenarios?
The code generation system in the entity framework is built on top of a public API which you may call yourself in order to have finer grained control over the code generation process. See <http://blogs.msdn.com/dsimmons/archive/2007/09/01/ef-codegen-events-for-fun-and-profit-aka-how-to-add-custom-attributes-to-my-generated-classes.aspx>for more details. You can also fit these customizations into visual studios extension mechanisms. For more information see < http://blogs.msdn.com/adonet/archive/2008/01/24/sampleedmxcodegenerator-sources.aspx >.
5. Data Classes
5.1. Is it required to use code generation tool? Can we hand author entity classes?
The entity framework most certainly does not require code generation. There are facilities for code generation and some of the UI/designer surface is geared toward those scenarios because they work well in a number of situations, but it is also possible to author your own classes by hand, implement a few key interfaces and use the entity framework that way. Your classes can but do not have to inherit from a common base class which is used in our generated classes. That said, this is something which we intend to make much easier in future releases. The long term goal is to support full persistence ignorance with the ability to opt-in to persistence awareness when/as needed.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
5.2. Is it recommended to modify tool generated classes?
No, because if you do, then you won't be able to regenerate them without losing your changes. The recommended approach is to add functionality to the generated classes in partial classes in separate files. For the case of things which cannot be added in a partial class, like adding attributes to the generated classes or methods, the code generation process can be customized by calling the public code generation API instead of using the commandline or vs wizard tools for that purpose.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
5.3. Does Entity Framework require objects with public empty constructors?
While the default generated classes have an automatically supplied public parameterless constructor, there's nothing in the framework that requires this to be so. There must be a parameterless constructor, but it can be private. You can try a simple example by taking the generated classes and just adding in a private parameterless constructor. At that point the generated factory method will work to create instances for users, but the system will just use the private parameterless constructor to materialize objects that are the results of queries. Another request which we have gotten is to support mapping directions so that even materialization of queries will go through factory methods, and that's something we will likely support in a future release but won't be supported in v1.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
5.4. Does Entity Framework require objects with public accessors for properties that are to be stored in the database? Does EntityFramework support Read-Only properties?
The system does not require public settable properties for all fields that are persisted to the database. While the default generated classes have public properties for each persisted field, you can either write your own classes or set the access for the getter and setter in the designer (public, internal, protected or private).
5.5. Does EntityFramework support a private field to be mapped to the database?
The system doesn't currently allow you to attribute a field directly, and the designer doesn't support configuring this visually, but it is definitely possible to do. As noted above, however, you can just make the generated property private.
5.6. Does EntityFramework support inheritance for methods or properties that do not map to the database?
Certainly. You can add these methods or properties to the partial classes for your data objects. They will not be persisted, but derived types will inherit them.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
5.7. Where has DoFinalConstruction() method gone?
Entity Framework no longer defines the method DoFinalConstruction or requires any of the mechanisms required in earlier CTPs of Entity Framework. For more information related to this topic refer to:
<http://blogs.msdn.com/dsimmons/archive/2007/05/03/celebrating-the-death-of-dofinalconstruction.aspx>
6. Databinding
6.1. Does ObjectQuery<T> and EntityCollection<T> support DataBinding for WinForms / WPF? Where has the "ToBindingList" method gone?
Both ObjectQuery<T> and EntityCollection<T> implement IListSource which makes databinding more automatic rather than requiring explicit calls to methods like ToBindingList(). In fact, since the automatic mechanism is so much better, ToBindingList was removed.
6.2. What about ASP.NET?
As of SP1 beta the EF includes a new EntityDataSource control and corresponding designer experience in VS which greatly simplifies the creation of asp.net sites with EF databinding. In addition, ASP.NET Dynamic Data further automates the process.
7. EDM
7.1. Does Entity Framework support Abstract types in EDM models?
In Entity Framework it is possible to declare Abstract types in EDM model (csdl file) — i.e. no entity instances can be created for these types, but types can be derived from them. In fact, types can be marked as abstract in the designer. The runtime even allows abstract types to be the base type for multiple different entitysets (imagine a scenario where you want a single base type for all your entities even though they live in multiple sets), but this is not supported in the designer (at least for v1).
7.2. Does Entity Framework have support for Complex types? What are Complex types? How are they different from Entity Types in the EDM?
Complex type is the Entity Framework name for value properties which have more intricate structure than scalars. The canonical example is an Address type which contains several parts (street, city, state, etc.) Complex types are somewhat like entities except that they do not have any identity of their own (they are value types). This means that a complex type instance is always a part of some other enclosing entity—it can’t stand on its own, it doesn’t have relationships, etc. Entity Framework support Complex types but in first release, the mapping scenarios for complex types are significantly limited: inheritance is not supported (inheritance definitely is supported for entities—just not complex types), complex type properties cannot be null and they can only occur in single instances, not collections. Also, complex types are not supported in the designer.
7.3. Does Entity Framework support multiple entity sets per type? Why is "multiple entity sets per type" support required?
Entity Framework supports multiple entity sets per type -- this means you can define a model which has more than one entity set with the same base type. This is important because it enables models which work more naturally with various database models. If you have two tables with the same schema (say "accounts" and "expired_accounts" or something), then you can define entitysets for each of them which use the same entity type rather than needing to create a different entity type which just happens to have all the same properties. This resulted in a change to a number of the object context APIs -- strongly typed contexts, for instance, now have AddToEntitySetName methods (where EntitySetName is the actual name of each entity set).
7.4. Are associations between sub-types supported?
Entity Framework supports associations between sub-types. The association between sub types allows you to define relationships between any types in the type hierarchy even if they aren't the base types. So, for instance, if I have a hierarchy that has Customer and BigAccountCustomer, then I could create an entity type DiscountPolicy and a relationship that only relates BigAccountCustomers to DiscountPolicies not just regular customers.
7.5. Does the EDM support guids?
Yes. The EDM supports guid as one of its primitive types. You can use guids as regular columns or as primary keys in your conceptual model. See question 10.3 for more information on using guids in EntityKeys.
7.6. Does the EDM/EF support enums?
No. In v1 of the EF, you cannot create a conceptual model which has a property of type enum and map it to a column in your database. There have been a number of requests for this feature, and it is certainly something which will be worked on in future releases.
7.7. Why does deleting an entity from my context not delete all related entities when I have cascade delete defined in the model?
Object Services will enforce model directives like cascade delete *for the subset of the model that has been loaded into memory*. This doesn’t mean, though, that you have to load everything in memory. What it means is that you need to setup your database so that it will enforce the same constraints for that portion of the model that hasn’t been loaded.
Cascade delete in the conceptual model helps your object graphs stay consistent. Cascade delete in the database helps your database stay consistent. You should implement both or neither.
8. EntityClient
8.1. How are connection strings managed in the Entity Framework? How can I create a connection string at runtime?
When you use the designer or EdmGen.exe to generate classes from your model, part of what gets generated is a strongly-typed ObjectContext which provides a convenient façade for working with your model. Part of the standard pattern is that the connection string which was originally used to access the database in order to generate the model is embedded in an EntityClient connection string which is placed into the app.config file under the same name as your entity container (specified in the CSDL and used as the name of the strongly-typed ObjectContext type in the generated code). If the app.config file exists and has a connection string whose name matches the container, then the generated classes have a nice, parameterless constructor which will automatically pick up that connection string and use it.
This mechanism is great for many scenarios--it makes for nice clean code, and it follows a great best-practice of putting the connection string out into the config file where it's easier to swap out in situations like where you might use one connection string for development, another for testing/staging and a third for final deployment. That said, there are cases where you might want to more dynamically generate the connection string--for example have multiple database servers for different environments and wanted to provide the user with the opportunity to specify the server as well as credential information at runtime. So, it's important to understand what the parts of the connection string are and how they go together.
If you create a connection string at runtime, then it's still quite straightforward to use. Instead of using the parameterless constructor for the strongly-typed context, you can just use the constructor overload which takes a connection string. This connection string is the exact same connection string that you use either with an ObjectContext (the base type or one of the strongly typed classes that inherit from it) or directly with EntityClient. It follows the same model as all other connection strings which is a set of name value pairs separated by semi-colons, and it has three parts:
1. A specification for where to find the metadata (csdl, msl & ssdl) which EntityClient will use for mapping between the conceptual model and the database. The keyword for this section is “metadata=”, and there are several different kinds of values you can give it. I mentioned the one I use most often above which is just to specify that the metadata lives in resources within the assembly and that the system should look through all the resources looking for appropriate ones. You can do this with “metadata=res://*/;”, or you can specify a pipe delimited list of directories or files (either absolute or relative to your app directory) which contain the metadata.
2. The name of the database provider which EntityClient should use to actually talk to the database. For example, “Provider=System.Data.SqlClient;”.
3. The connection string that you would use with the database provider to access your database. Since this value itself has a series of keywords separated by semi-colons, the string is just enclosed in double quotes. In my sample model it looks like this, “provider connection string="MultipleActiveResultSets=true;database=dpmr;server=.;Integrated Security=true;".
If you are going to build up these parts dynamically, then naturally the recommended way to do so is using a connection string builder, and EntityConnectionBuilder makes this easy. For the provider connection string, you can of course do a similar thing using something like SqlConnectionBuilder. So, the whole thing together would look like this:
SqlConnectionStringBuilder sqlBuilder = new SqlConnectionStringBuilder();
sqlBuilder.MultipleActiveResultSets = true;
sqlBuilder.DataSource = ".";
sqlBuilder.InitialCatalog = "dpmr";
sqlBuilder.IntegratedSecurity = true;
EntityConnectionStringBuilder entityBuilder = new EntityConnectionStringBuilder();
entityBuilder.ProviderConnectionString = sqlBuilder.ToString();
entityBuilder.Metadata = "res://*/";
entityBuilder.Provider = "System.Data.SqlClient";
8.2. Can I access the underlying store connection given an EntityConnection?
Given an EntityConnection you can easily access the store connection, which makes it much easier to go around the covers if you need to. However in reality you don't need to as Entity Framework is designed to cover most of the scenarios required for app building through its public API.
9. Entity SQL and ObjectQuery Builder Methods
9.1. What is Entity SQL? Why introduce a new query language (eSQL); why not use SQL?
SQL is the time proven query language for data access. However, since EDM introduces an enhanced data model which builds on entities, rich types and relationships, we need a query language that enables programmers to reason, express and write queries in terms of EDM abstractions. EntitySQL was designed to address this need. Among the many requirements, it is worth to call out some driving aspects of the language design:
Types: Support EDM types in a clean and expressive way;
SQL based: Provide a natural transition for SQL developers. While EntitySQL was heavily influenced by SQL, EntitySQL is not pure SQL. It is worth mentioning that EntitySQL does not prevent one from writing classic SQL queries, users can navigate relationships using classic joins/foreign-keys. EntitySQL also supports relationships to simplify this common task.
Composable and orthogonal: In some SQL implementations, certain expressions can only be placed in specific constructs. In contrast, EntitySQL expressions can be placed virtually anywhere. For instance, sub-queries are treated uniformly regardless where they are placed. A sub-query in the SELECT clause is treated in the same way as in a FROM clause, as opposed to SQL in which sub-queries in the SELECT clause must evaluate to scalars and as collection in a FROM clause. LIKE is another example. It can be used anywhere a Boolean condition is expected, even as a top level query. @myString LIKE @myPattern is a valid EntitySQL query that will be evaluated at the database and returns True, False or Null.
First class collections: EntitySets are treated as collections of a given entity type, therefore NorthwindContainer.Products is a valid query that returns the collection of all Products. {1,2,3} is a collection of integers constructed “inline”. Tables in the SQL sense are just collections of a given entity type. Collections can be created, nested and projected as any other EDM type.
Provider neutral: An interesting implication of writing queries against a conceptual model is that queries and applications can be virtually provider agnostic. When other provider writers make their database of choice available through the ADO.Net Entity Framework, queries written in EntitySQL may be reused across different store providers. The EntitySQL language exposes the same set of constructs regardless of the specific provider implementation.
Pasted from <http://blogs.msdn.com/adonet/default.aspx?p=2>
9.2. Why have Entity SQL when you support LINQ?
There are at least three main reasons why the Entity Framework supports Entity SQL as well as LINQ:
1. A text-based, late-bound query language makes some scenarios much easier to develop such as cases where you cannot fully determine the query until runtime. (In fairness these scenarios can also be accomplished with LINQ but they are often much more difficult.) The EntityDataSourceControl for databinding with ASP.NET is a great example of these scenarios.
2. EntityClient needs a text-based query language in order to support the standard ado.net provider API and access patterns where you create a connection, from that create a command where you specify a text string, and then execute the command in order to get back a DataReader.
3. It's a matter of taste. Entity SQL will be very familiar to developers who have spent a lot of time working with SQL, and the transition to Entity SQL may be easier/more natural than the transition to LINQ.
9.3. What does the SelectValue builder method do? What is “select value” in Entity SQL?
The Select and SelectValue builder methods on ObjectQuery both do a very similar thing in that they allow you to project particular values from an overall entity or other query result. The difference is that with Select you ALWAYS get back an enumeration of DbDataRecords. If you select two properties, then you will get back DbDataRecords with two columns. If you select only one property, you will get back DbDataRecords with one column.
In the case of SelectValue, though, you can only specify one property and instead of getting back an enumeraiton of DbDataRecords with one column, you will just get back an enumeration with the value out of that column. So if you had advWorksContext.Product.SelectValue<Int32>(“Length(it.Name)”), the return type would be an enumeration of Int32s. If you did the same thing except with Select, first off you would not supply a generic type parameter to the method (it would just be advWorksContext.Product.Select("Length(it.Name)"), and secondly you would get back an enumeration of DbDataRecords that had one column which was an Int32 type.
These builder methods map directly onto the entitySQL "select" and "select value" commands. Select value just says, "I'm only returning one thing, and so I want the value of that thing rather than a record containing it.". You can use it with properties and scalars or even with whole entities.
10. EntityKey
10.1.Does the Entity Framework support server-generated key values?
Yes! The flow of a typical new entity with a server-generated key value looks something like this:
1. Construct the entity instance. At this point the key properties all have default values (null or 0).
2. Add the instance to your context. A temporary key is created and used to store the entity in the ObjectStateManager.
3.