I'm sorry, but this is probably not the answer you would wish for, but to be honest, the best practice of MS Entity Framework is to not use it at all...
First of all, you should REALLY consider the actual need for using such technology on a project by project basis, don't just use it because it's an easy way to stay away from writing SELECT statements and Plain SQL.
EF solutions adds A LOT of complexity to a project behind the scenes. It doesn't just map one table to a class and gets done with it, but it seriously does some crazy s*** behind the curtains that you don't want to see. (probably why you don't see it in the first place).
Why do I say this? Consider the following:
For each first-time call to a EF mapped database the machinery has to go through (among other things) these steps:
1. Mapping of the views:
Mapping Views are executable representations of the transformations specified in the mapping for each entity set and association. Internally, these mapping views take the shape of "canonical query trees".
There are two types of mapping views:
These represent the transformation necessary to go from the database schema to the conceptual schema.
These represent the transformation necessary to go from the conceptual model to the database schema.
The process of computing these views based on the specification of the mapping is what's called "view generation".
View generation can either take place dynamically when a model is loaded, or at build time, by using "pre-generated views".
The latter are serialized in the form of Entity SQL statements to a C# file.
2. Validation of the Schema:
When views are generated, they are also validated. From a performance standpoint, the vast majority of the cost of view generation is actually the validation of the views which ensures that the connections between the entities make sense and have the correct cardinality for all the supported operations.
When a query is executed, the query is combined with the corresponding query view, and the result is run through the compiler to create a representation of the query that the backing store can understand.
For MS SQL Server it will be T-SQL SELECT statements.
The first time an update over an entity set is performed, the update view is run through a similar process to transform it into DML statements for the target DB.
If two Entities are connected via an inheritance chain or an Association, they are said to be connected. Similarly if two tables are connected via a foreign key, they are connected, and if this is not the case in your project, drop EF all together as it is overkill.
As the number of connected Entities and tables in your schemas increase, the view generation cost increases.
So, is all hope lost?
Well, you can speed things up by pre-configuring the views needed. This gives a formidable boost in performance in most cases.
If your model is in EDMX format, you should read up on T4 Template creation and use that.
Using pre-generated views moves the cost of view generation from model loading (run time) to compile time. So basically your users will rejoice and you will bang your head in the desk waiting for compiling to get done with it.
Some tips and tricks to consider:
1. EDMX models are validated at compile time, even if the model is unchanged. If your model has already been validated, you can suppress validation at compile time by setting the "Validate on Build" property to false in the properties window.
If your model isn't an edmx but is created using EDMGen, one of the outputs will be a "Views" file. This is a code file containing Entity SQL snippets for each entity set. To enable pre-generated views, you simply include the file in your project.
If you manually make edits to the schema files for the model, you will need to re-generate the views file. You can do this by running EDMGen with the /mode:ViewGeneration flag.
For further reference, see "Pre-Generate Views to Improve Query Performance"http://msdn.microsoft.com/en-us/library/bb896240.aspx.
2. If your application is only used for query scenarios, you can mark the model as read-only by adding a GenerateUpdateViews attribute on the EntityContainerMapping element in your XML mapping and setting it to false.
3. Using statically compiled query instances (CompiledQuery)
The Customer Advisory Team discusses this in their "Potential Performance Issues with Compiled LINQ Query Re-Compiles" blog post: http://blogs.msdn.com/b/appfabriccat/archive/2010/08/06/potential-performance-issues-with-compiled-linq-query-re-compiles.aspx.
4. Entity Framework 5 introduces automatic caching for LINQ to Entities. In past editions of Entity Framework creating a CompiledQuery to speed your performance was a common practice, as this would make your LINQ to Entities query cacheable. Since caching is now done automatically without the use of a CompiledQuery, we call this feature “autocompiled queries”. For more information, see: