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: 18.5 Why doesn’t relationship span happen with MergeOption.NoTracking?
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. Call SaveChanges on the context.The EntityAdapter computes a SQL insert statement (or a stored proc invocation if so-specified in the mapping) and executes it.
4. EntityAdapter writes the server-generated value back to the ObjectStateEntry for the entity. This assumes, of course, that the insert succeeded and that the SSDL was properly configured to indicate that there is a server generated value. Fortunately, if the SSDL is generated from the database schema by a tool, this configuration is automatically done as part of that generation.
5. The ObjectStateEntry pushes the server-generated value into the entity itself. The EntityAdapter is written to operate solely at the conceptual model layer and uses the DataRecord interface on the ObjectStateEntry to read and write values from the entity. The ObjectStateEntry guarantees that the entity object and the DataRecord interface always contain the same data (for current values the DataRecord, in fact, is virtualized over the entity rather than storing its own copy of the data).
6. When AcceptChanges is called on the ObjectStateEntry, a permanent EntityKey is computed using the new, unique property key values.The ObjectStateManager then does an internal fixup replacing all instances of the temporary key with the new permanent key.
10.2.Can you create a new entity with a server generated key and a set of related new entities which have a foreign key to that entity in a single update?
In a word, yes. You can create arbitrarily complex graphs of entities with server generated values and the system can handle inserts of those entire graphs in a single call to SaveChanges.
10.3.Can you use a guid property as part of an entity key?
Yes. You can use a guid in your conceptual model as a regular property or a primary key.
There is, however, a limitation that the EF does not support primary keys whose type is binary. What this means in practice is that if your database has a column of type "uniqueidentifier", then the automatic model generation will recognize that it contains a guid and configure the corresponding property in the conceptual model to be a guid making everything happy, but if your column in the database is of type binary with a length of 16 bytes, then the automatic model generation will make the type of the property in the conceptual model a byte array of length 16, and that cannot be the primary key for your entity.
If you go into the designer, you can manually modify the type of the conceptual model property to be a guid rather than a byte array, and then the property can be the entity key for that type. At that point, you will receive errors from the mapping system saying that it can't map a guid onto a 16 byte binary. To fix that you will need to open the EDMX file in the XML editor (or edit your SSDL file if you are not using the designer) and change the metadata for the column in your database to claim that it is really a uniqueidentifier rather than a 16 byte binary. Once all of this is done, you will fool the EF into thinking that the column is a uniqueidentifier which maps nicely to a guid, and everything should be happy.
10.4.Can I use a server-generated guid as my entity key?
Unfortunately, in v1 of the EF this is not supported. While it is possible with SQL Server to have a column of type “uniqueidentifier” and to set it’s default value to be “newid()”, with SQL Server 2000 there’s no good way to extract the value that the server generated at the time you do the insert. This can be done on more recent versions of SQL Server, though, so the intent is that we should find a clean way to special case this support in future versions of the EF so it can be supported on those databases that allow it and not on others. For now, the work around is to generate the guid on the client (ideally in the constructor of your object) rather than on the server.
11. Lazy Load and Eager Load
11.1.Does Entity Framework support lazy loading and deep loading and how is the performance for these features?
EF definitely supports both lazy loading and deep loading, and we've done a LOT of work to optimize performance. When you create a query it will, by default, just use lazy loading. You can, however, opt-in on a per-query basis for eager loading of one or more relationships. The performance for these features really depends on your particular usage scenario. In some cases it's more efficient to query for everything up front. In other cases, doing all of that in one round trip either might bring down additional data that you don't need or might even be less efficient because of the large joins that are required. Like all things performance, you need to profile your individual situation and tune to get the best possible performance.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=573966&SiteID=1>
11.2.Why doesn't the EF automatically load related entities when I reference a navigation property if it hasn't already been loaded (like Linq to SQL does)?
The entity framework attempts to make everything explicit, so even with lazy loading, you must explicitly call the Load method on the relationship in order to load its related entities. That way you know exactly when round trips are made to the database. As systems grow larger and more complex, this kind of explicitness can do a lot to improve overall supportability of the system.
11.3.Is it possible to make the EF implicitly load related entities (even though 11.2 says it doesn’t do that by default)?
Yes. This is possible, but it does require some work. Check out this series of blog posts: http://blogs.msdn.com/jkowalski/archive/2008/05/12/transparent-lazy-loading-for-entity-framework-part-1.aspx
12. LINQ to Entities
12.1.How can I write a linq query which restricts based on a many to many relationship?
For a many to many relationship, let’s say between Boy and Girl, the navigation properties Boy.Girl and Girl.Boy are of a collection type. Therefore we cannot use something like "girls.Contains(b.Girl)", this will cause the exception message because b.Girl is really a collection of Girls.
The correct way to write a join linq query would be:
var query = (
from girl in context.Girl //or some filtered subset
from boy in girl.Boy
select boy
).Distinct();
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2348831&SiteID=1>
12.2.How do I write a LINQ to Entities query which has the equivalent of the SQL “in” keyword?
In SQL, you might write a query that looks something like this: SELECT * FROM Foo WHERE blah IN (1, 3, 5, 7). With LINQ to Entities you might have a similar scenario except that you are selecting from an entityset and the list of values you want to compare against is stored in a LIST<T>. Unfortunately, the Entity Framework does not currently support collection-valued parameters. To work around this restriction, you can manually construct an expression given a sequence of values using the following utility method:
staticExpression<Func<TElement, bool>> BuildContainsExpression<TElement, TValue>(
Expression<Func<TElement, TValue>> valueSelector, IEnumerable<TValue> values)
{
if (null == valueSelector) { thrownewArgumentNullException("valueSelector"); }
if (null == values) { thrownewArgumentNullException("values"); }
ParameterExpression p = valueSelector.Parameters.Single();
// p => valueSelector(p) == values[0] || valueSelector(p) == ...
if (!values.Any())
{
return e => false;
}
var equals = values.Select(value => (Expression)Expression.Equal(valueSelector.Body, Expression.Constant(value, typeof(TValue))));
var body = equals.Aggregate<Expression>((accumulate, equal) => Expression.Or(accumulate, equal));
returnExpression.Lambda<Func<TElement, bool>>(body, p);
}
Using this utility method, you can rewrite:
var query1 = from e in context.Entities
where ids.Contains(e.ID)
select e;
as
var query2 = context.Entities.Where(
BuildContainsExpression<Entity, int>(e => e.ID, ids));
13. Mapping
13.1.Can stored procedures return polymorphic results?
Yes stored procedures that retrieve entity instances can return polymorphic results rather than being restricted only to results of a single type.
13.2.How can I map a stored procedure?
The EF mapping system supports mapping stored procedures for all four CRUD (Create, Read, Update and Delete) operations. For more details and a full example of reading entities from a sproc, see:
For details and an example of creating, updating and deleting entities from a sproc, see:
13.3.How to map read-only Entities? How to use Defining QueryViews in mapping files?
One way to map read-only entities is to use a Defining Query. See <http://blogs.msdn.com/dsimmons/archive/2007/11/08/mapping-read-only-entities.aspx> for more details.
14. Metadata
14.1.Does the Entity Framework allow embedding metadata files as resources in the assembly?
Yes Entity Framework allows storing metadata files as resources in the assembly; in the connection string you can tell the Entity Framework to find them there. The way to do this is to add the CSDL, MSL and SSDL files to your project and set the "Build Action" property on each one to "Embedded Resource". Then when you specify your connection string, rather than explicitly listing the metadata files, you can just add "metadata=res://*/;" which tells the EF to look for appropriate resources in your apps statically linked assemblies any that it finds.
The only thing to be careful about is that the assembly that has the resources should be loaded in the same app domain that has the entity connection.
14.2.When is EDMX file used? What is the difference between EDMX file and the three schema files (CSDL, MSL and SSDL)?
The EDM designer uses a file called EDMX to store all of the metadata about an Entity Framework model. This one file includes the CSDL, MSL and SSDL just in separate sections within it. When it comes to runtime, the system requires the three separate files, and the designer projects automatically create them in the application out directory.
14.3.How is the "using" support in metadata files used?
<Using> support in metadata files: Models can be built from multiple separate CSDL files—somewhat like a “using” statement in a C# file which brings a namespace into the file or a #include statement in a C/C++ program except with greater validation than you get in the purely textual preprocessing of #include.
TODO: Add sample more detail
14.4.Can we add custom annotations in the CSDL file?
There is a support in CSDL files to include custom annotations which the framework ignores but can be useful for tools or other systems built around the EDM. These annotations are surfaced in the metadata APIs but not otherwise used by the EF.
15. Multi-threading
15.1.What is the recommendation for running a multithreaded application on Entity Framework? Is Entity Framework thread-safe?
Entity Framework, like most of the rest of the .Net framework, is by and large NOT thread-safe. So if you want to interact with the entity framework or your entity classes from multiple threads, then you are going to have to do your own locking. One simple model which works for some cases is for each thread to maintain its own context so that no locking is required. This means, of course, that the interactions between the threads tends to be quite limited (you can’t really pass an entity from one thread to another without being very careful), but you can do some pretty useful things even so.
Pasted from <http://blogs.msdn.com/dsimmons/>
16. Object Services
16.1.What is ObjectContext.Detach() method used for?
ObjectContext.Detach() -- will detach an object from the ObjectStateManager associated with an object context so that it can be attached to some other context or reclaimed by the garbage collector.
16.2.Can the container name and the connection string name be different?
Unfortunately if you want to use the parameterless constructor on the strongly typed context, these two things are tied. The container name and the connection string name have to be the same. Of course your context object doesn't necessarily have to have the same name as your container, but you would have to use IPOCO or maybe codegen events to modify the way things are generated, and that doesn't really address what you are asking for anyway.
What you can do, though, is pass the connection string into the constructor of your context (either the strongly typed, generated context or the base class ObjectContext) yourself and then of course you could hard code it, determine it dynamically, get it out of the config file or whatever.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2349979&SiteID=1>
17. Performance
17.1.What does query plan caching do? Do I need to keep my ObjectQuery<T> around to take advantage of query plan caching?
Query plan caching stores information which is computed as part of putting together the query itself. By caching this, a subsequent execution of the same query (even if you change parameter values) will run much faster than the first one. This information is cached per app-domain so you will generally benefit from the query cache across multiple client requests to the same web app and the like.
You do not have to keep an ObjectQuery<T> instance around to take advantage of the query plan cache--future ObjectQuery<T> instances which use the same query string will automatically take avantage of it.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2363212&SiteID=1>
17.2.Show me the numbers. How good is EF performance?
Take a look at some relevant posts on the ADO.Net team blog starting with this one: http://blogs.msdn.com/adonet/archive/2008/03/27/ado-net-entity-framework-performance-comparison.aspx
18. Query
18.1.How is Span used? What is Span? (aka. How does the EF support eager-loading?)
The span feature makes it possible to pre-fetch related entities. Span can be defined as a builder method, "Include", which makes it simpler to specify span rules in LINQ to Entities queries. Include can be called on the ObjectQuery used in the from clause of the LINQ query.
Span makes it possible to specify that a query not only return an entity but return some set of related entities in a single round trip and automatically hook-up the graph. So, for instance, you could say that your customer query should also return the orders for each customer in a single round trip. We also have an automatic query re-write feature for the object layer that enables a feature we call Relationship Span where queries that retrieve entities will under-the-covers also return relationship information if the relationship is an EntityReference (rather than a collection). This is usually a quick operation since typically this relationship information is co-located in the relational database as a foreign key property, and it has the very useful property that for many cases entity graphs will automatically be hooked up as long as the relevant entities on either side of the relationship have been loaded. So, for example, if I query for a set of customers and then I separately do a query for a bunch of orders--any of those orders that are related to those customers will automatically bring along the relationship info and connect the orders up to the customers they go with.
18.2.How can I do a filtered load of a relationship?
While the EF supports a nice eager-loading directive (Include described above), this directive and the Load method on EntityCollection and EntityReference always load the entire contents of a relationship. Sometimes, though, you might want to load only a subset of related entities. For information on how to do that, see this blog post.
18.3.How can I see the SQL which will be sent to the backend database as a result of my query?
If you are running against SQL Server, you can always use SQL Server Profiler to see what queries are sent to the database, but this only works with SQL Server, and it doesn’t work with the express edition. As an alternative, though, you can use the new method added in beta 3 of the EF, ToTraceString from either ObjectQuery or EntityCommand.
18.4.How many Includes can I have in a query?
Each include will typically cause another join to show up in your query. At some point the query will become too complex to execute. It is always wise to test the performance of various ways to retrieve related entities, because for some scenarios Include is much faster because it means fewer roundtrips to the database, but for other scenarios additional roundtrips may be faster because of the simpler queries and reduction in redundant data which the extra joins incur. See http://forums.microsoft.com/Forums/ShowPost.aspx?PostID=3368976&SiteID=1 for some more thoughts.
18.5.Why doesn’t relationship span happen with MergeOption.NoTracking?
The basic reason the EF doesn’t do relationship span with NoTracking queries is that NoTracking queries were designed to be as absolutely high performance as possible. We didn’t want to rewrite those queries to bring back additional data (which could possibly require a join to draw the data from a link table or something) unless the user explicitly asked for it. In the case of standard tracking queries, the stubs are so important that we decided to just turn it on by default, but for NoTracking queries that didn’t seem like the right answer.
While this info isn’t returned by default, you can usually rewrite the queries yourself to retrieve this information in a fairly straightforward fashion. For instance, if you were querying for orders and wanted to bring back the key of the related customer, then you could do something like this:
var query = ctx.CreateQuery<DbDataRecord>("select o, Ref(o.Customer) from Orders as o");
query.MergeOption = MergeOption.NoTracking;
19. Resource Management
19.1.What should be the lifetime of Object Context? Should I create a new Object Context for every new query?
This is a broad topic and obviously the right answer varies a lot depending on the overall architecture of the app you are building—if you are building a web service or an asp.net page then you almost certainly want the context only to stay alive during each request and then be destroyed so that your server can be as stateless as possible, but if you are building a rich client application, then your context will typically stay alive for a much longer period of time—in fact the same context probably stays alive for the life of your app. The reason for this is that the context performs identity resolution and provides the path from entities to the database for when you want to do things like deferred loading. If you destroy the context or detach the entities from it, then deferred loading won’t work.
The other thing you have to remember, though, is that the EF, like most of the rest of the .Net framework, is by and large NOT thread-safe. So if you want to interact with the EF or your entity classes from multiple threads, then you are going to have to do your own locking. One simple model which works for some cases is for each thread to maintain its own context so that no locking is required. This means, of course, that the interactions between the threads tends to be quite limited (you can’t really pass an entity from one thread to another without being very careful), but you can do some pretty useful things even so.
19.2.Does the provider connection stay open for the entire life time of Object Context? When is the provider Connection opened/closed?
The Object Context keeps the connection closed as much as possible while still appropriately dealing with transactions and avoiding promotion of those transactions from local to DTC where possible. The Object Context does NOT keep the connection open from the time ObjectContext was constructed till the life of the context; because this would create issues, for instance, with databases where licensing was based on the number of concurrently open connections since the connection might be held open for an extended period of time—even when the connection is not being used.
You can also exercise more explicit control over the connection by manually opening or closing it. If you open the connection, for instance, the context will leave it open until you explicitly close it or the context is disposed.
19.3.Do I need to explicitly call Dispose() on ObjectContext object after use?
The short answer; no, you don't have to, but you should...
ObjectContext holds state (for example, a SqlConnection and pointers to the objects you have retrieved). These will eventually get cleaned up by the GC once you release all references, but some of these objects (for example, the underlying SqlConnection) may be holding resources that you typically want to release as soon as your are finished, rather than relying on the GC to clean up.
We generally recommend constructing a ObjectContext within a using statement to make sure that resources are cleaned up when you leave the block. For example, in C# we would recommend:
using(NorthwindObjectContext db = new NorthwindObjectContext())
{
//do stuff with ObjectContext
} // Dispose is called on ObjectContext when you leave the using block
This is the same pattern we recommend for using DbConnections in ADO.NET 2.0.
Pasted from <http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2354870&SiteID=1>
20. Serialization and Web Services
20.1.Is Entity Key serializable?
Yes Entity Key is serializable. There were bugs around this in beta 2, but they have been fixed for beta 3. Not only is the key serializable, but also if you serialize one of the generated entity classes its key will be serialized with it, and if you serialize an EntityReference which has associated relationship info the EntityKey of the related entity will be serialized along with it.
20.2.Is it possible to serialize a graph of related entities? Why am I only getting one entity at a time when I do XML serialization?
The entity framework will, by default, generate classes which 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 asp.net viewstate. Similarly, as of SP1 beta, DataContract serialization will by default include entire graphs of entities (thanks to some changes in both the EF and WCF). 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.
20.3.Is it possible to serialize the ObjectContext?
In a word, no. Beyond that, I’m not sure that I recommend trying. See this blog post for some of the problems in this space in general, and this blog post for some data about strategies for web services. If you are really persistent, you might want to check out the EntityBag project at http://code.msdn.microsoft.com/entitybag/, but as of this writing it has not been updated to work with SP1 beta (it works with beta 3). Keep in mind, though, that EntityBag is a sample/experiment. The EF team is working on a better out-of-the-box solution for v2.
20.4.How do I serialize derived entity types over a WCF service with DataContract serialization?
This did not work out of the box in beta 3, but as of SP1 beta it should work automatically.
20.5.What about ADO.Net Data Services (aka Astoria)?
ADO.Net Data Services can facilitate automatic creation of a REST oriented web service which 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/ for more info.
20.6.Does ApplyPropertyChanges 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 since 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 at all. In these cases, the ApplyPropertyChanges 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. ApplyPropertyChanges 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.
If you need to apply changes to an entire graph of objects, then you need to walk the graph yourself and call ApplyPropertyChanges on each modified entity. If there are entities which are new or should be deleted, then you need to track that information in some other form than just a modified graph because just having the new graph simply 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 it is detached you need some other mechanism to track that info. One solution that works for some applications is to use a single key property and interpret certain values which 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 thing some folks do is to add an entity state property to their entities and maintain that property themselves when the entity is detached. In either case, you can then walk a graph, look at that extra information and use it to call either ApplyPropertyChanges, AddObject or DeleteObject on the context. The only other thing to remember is that AddObject will add the entire graph so new objects must be disconnected from an incoming graph before calling Add—they can then be connected to the graph already in the context.
Another approach is to use something like http://code.msdn.microsoft.com/entitybag/. Future versions of the EF will include functionality to automate more of this process.
