Entity Framework 4 in action Reading Notes

Entity Framework 4 in action is my first English book I have read for so many years. At first I went to learn English in order to read this book. Later I simply read and read several chapters, the English reading capability has been greatly improved. Unfortunately, at the end, I did not learn anything substantive, but I learned English. Of course, I did not learn anything substantive, because most of my knowledge is scattered on the Forum and I have read it on blogs. The book itself is very informative, this is a feature of books written by foreign authors. There is no nonsense and there is no huge pileCode. As a beginner of EF, It is very suitable for reading. Next, let's talk about some of my thoughts and record them.

Lifecycle

This book introduces in detail in Chapter 6Entity object)Here, the lifecycle refers to five States of the object in EF.

When you are executingInsert, modify, and deleteThe operation is when they play light and heat,Query dataIt does not work. EF provides a wide range of interfaces that allow you to switch the status of an object or even an attribute of an object at will, in order to reduce the number of times you deal with the database. For example, the following code:

 1 Ibactername name = Bacternamerep. getbyid (applyinfo. bacternameid );  2 Isupplier supplier = Null ;  3                   If  (Applyinfo. supplierid. hasvalue)  4   {  5 Supplier = Supplierrep. getbyid (applyinfo. supplierid. value );  6   }  7 Ibacterbuyapply bacterbuyapply = _ Factory. createbacterbuyapply (name, applyinfo. amount, rangeid, rangetype, userid, supplier, (e_unittype) name. injectuint ); 8 _ Bbar. Add (bacterbuyapply );

To insert an ibacterbuyapply object, I took two objects from the database in the first line and the fifth line of code. That is to say, in order to perform an insert operation, I query the database twice more than the original ADO. net.
When I was just using EF, this made me very unacceptable. What should I do? Use the attach method. It can help us avoid the two meaningless queries, and the code will not be pasted. Everyone knows...

But is this really suitable?I don't think so, because our code is always well divided, and I don't know the layer where the above Code is put, but it is definitely not called "Ef layer ". What I want to say is that when we use methods like attach, it destroys our code structure and makes our code unpure. Because the original code is not associated with your database access architecture, it is tied to the EF component. Of course, the above Code was cut down in the 08 project. In ef4.0, this problem does not exist because foreign keys are allowed, but this does not affect what I want to express. I don't know what you think about this problem.

Some performance optimizations mentioned in the book

When I was about to finish the third part of this book, I jumped to the performance optimization section of the last chapter. Let me talk about some optimization suggestions mentioned in the book.

• first, Entity SQL is faster than LINQ to entities. So we need to use Entity SQL? Since all of them are Entity SQL, why not ado.net? It is always a runtime error. The biggest advantage of using EF is compile-time errors. Without this, I think there is no need to use it.
• cached compiled LINQ to entity -- the cached Expression Tree is not an SQL statement. It takes a considerable amount of time to translate from LINQ to entity to SQL. After caching, the next execution will reduce the number of translation expressions, improving the speed. However, this method is flawed. When you extract the compiled Expression Tree and connect to other LINQ to entity statements, the cache effect becomes invalid, which means that, on our query page, if the user continuously changes the combination of query parameters, the cache is invalid. It is only after the query, the page is turned over, and the results are still effective.
• disable status tracing . EF maintains the state of the object retrieved from the database, which requires a considerable amount of resource consumption. disabling it will greatly improve the performance. however, this seems meaningless , because we only need to retrieve a large amount of data on the data browsing page, on the data browsing page, we usually need to retrieve data from multiple tables-join queries. How do we use the fields in other tables? Loadwith? I often need to associate more than four tables in a query. I think loadwith is the performance killer. Obviously, it is only appropriate for fields in each table to be transferred to a new data transmission object. When you do this, status tracing has expired ....

Hey hey, about optimization I used to make a small exploration, post a link http://www.cnblogs.com/xxfss2/archive/2012/06/15/2550826.html

Finally, let's talk about Entity SQL

Entity SQL can be written when you cannot write a query statement by using LINQ to entity. However, I think it is more suitable to use stored procedures. In addition, it can dynamically concatenate statements in an extended way. For example, if you have a large number of sorting fields, this is not necessary, you can find an extension method to dynamically construct the expression tree on the Internet to solve this problem. In short, I think entitysql is a weakness. I also mentioned in the book that it was invented at the beginning because of the poor alternatives that haven't come out of LINQ.