Hi there. 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: Query views: These represent the transformation necessary to go from the database schema to the conceptual schema. Update views: 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. Sim

My eyes just played a trick on me. I've corrected the reply to the right person now... Certainty of death, small chance of success... What are we waiting for?

Hi there. 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: Query views: These represent the transformation necessary to go from the database schema to the conceptual schema. Update views: 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. Sim

Hi there. 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: Query views: These represent the transformation necessary to go from the database schema to the conceptual schema. Update views: 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. Sim

I'm not sure if you mean the book or Design Patterns in general, so to answer both: The book has its share of goodness, and yes I think it is absolutely still relevant today, if not more, (now that was the short answer if you meant the book :-)) which leads me to the concept of Design Patterns in practice. I don't agree with the first reply to this question saying that you already use DP even if you don't know about it. Well, every framework out there is hopefully built with DP in mind, but you don't use that code directly, you design pieces of software from higher level bits, sure, but you still have to create your own OOP structures, and the basics of a modern application and here I believe that Design Patterns are equally important today, and probably will be for as long as there is Object Oriented Programming involved. How do you best create the application structure with interfaces, classes, inheritance, the works? This is what Design Patterns is all about! So, still important, for sure... ;) Certainty of death, small chance of success... What are we waiting for?