) Entity Framework 4.1 3 (transition from 4.0 to 4.1/4.3)

Original article address:

Http://www.cnblogs.com/mbailing/archive/2012/07/16/2593368.html

 

 

Hello everyone, I was busy on the first two Mondays. In the new project, I used Entity Framework 4.3, but it actually transitioned from 4.0. You know, once you get used to a method and want to change it, it's really not easy. I had the courage to make a transition to Entity Framework4.3 after I had spent the entire day playing the game. Because many of the problems encountered in 4.0 have their own solutions, the unknown 4.3 is full of yearning, but it is also accompanied by resistance. After the project is over (for small projects), I have been thinking about how to write and how to write this article. Now, let me enter the topic of this article.

TIPS: EF4.0 mentioned in this Article refers to the version released along with. net Framework 3.5. Because I have never known the version number, I called her EF4.0 (this is also a anthropomorphic name, because the name "she" is used ").

I. Why transition?

(1) There are too many objects in EF4.0: Why?

I believe that EF4.0 will be used by students, and the Edmx file will expose a class. This class and the table in the database have the same name. It is actually a ing Class. For example, the table name is "BJ_Student ". The BJ_Student class is exposed in Edmx for data addition, deletion, modification, and query.

However, because BJ_Student is mapped to many things in edmx (you can change the suffix of the edmx file to xml, and then open the file to see all mappings ), therefore, it is not easy to add some extension attributes. So in 4.0, I used to create a Student object, and put the number read from BJ_Student into my new Student object.

The last small example (4.0 ),

　　　　　　　　　　　　var query = (from m in context.BJ_Student             　　　　　　　　　　　　where id=12             　　　　　　　　　　　　select  new student　　　　　　　　　　　　　　　　　　　　{                  　　　　　　　　　　　　name=m.name　　　　　　　　　　　　　　　　　　　　}).FirstOrDefault();   

This is a way of writing in 4.0. The returned result is student.

If we are adding some DTO classes, wow, there are too many classes. Tired!

But in 4.1/4.3, it is also mapped to BJ_Student, but this class can be expanded to add extended fields.

(4.1/4.3) var query = (from m in context. BJ_Student where id = 12). FirstOrDefault (); The returned result is BJ_Student.

We can see that in (4.1/4.3/), we only need to use a BJ_Student class, because she can freely and flexibly expand.

Reducing the number of classes is undoubtedly very meaningful. It may be a bit similar to the previous article. Here it is all a warm story and I know new things.

(2) flexible handling of relationships

(4.0 ),

　　　　　　　　　　　　var query = from s in test.BS_Roster            　　　　　　　　　　　　join c in test.BS_CLASS            　　　　　　　　　　　　on  s.rid = c.rid            　　　　　　　　　　　　select s ;

In 4.0, this association query is actually .... it is easy to write with only six words omitted, but I always feel that I am still writing SQL statements, and when there are more than one table, I am crazy. I keep reading Fuck, Fuck ....

It can be seen that 4.0 of the table Association queries are not flexible enough.

(4.1/4.3 ),

　　　　　　　　　　　　var query = from m in context.Dic_PropertyTypeDef.Include("Dic_PropertyClassDef")     　　　　　　　　　　　　　　　　 where m.State == 0     　　　　　　　　　　　　　　　　 select m);

In 4.1/4.3, It Is. Include ("Dic_PropertyClassDef "). Because we have added this attribute to the Dic_PropertyTypeDef object

Public virtual Dic_PropertyClassDef {get; set;} can be seen as virtual, which is a single object attribute.

Dic_PropertyTypeDef has a one-to-one relationship with Dic_PropertyClassDef. Of course, Dic_PropertyClassDef has a one-to-many relationship with Dic_PropertyTypeDef.

For one to multiple objects, the attribute object should be defined as follows:

Public virtual ICollection <Dic_PropertyValueDef> Dic_PropertyValueDef {get; set;} is also a virtual type, but an ICollection.

In 4.1/4.3, as long as we have established this correspondence, the associated query becomes much simpler. Is it true. However, if you get used to 4.0, you will suddenly accept this write.

Method, it must be uncomfortable, so it is recommended to slowly transition, and learn to control the mood. Impulse is the devil.

(3) The code is clear and the corresponding code volume is reduced. The edmx file is also missing. In fact, he still exists.

(4) Since (4.1/4.3) has been greatly optimized in terms of SQL statement generation and performance, the speed is faster than 4.0, making it easier to use and expand.

The above are some of the advantages I have summed up in development. The terms are not rigorous and may not be easy to understand. I would like to ask you a lot of questions.

Ii. EF4.1/4.3

Is it a transition? Of course, it is a good transition. After talking about some of the advantages of 4.1/4.3, we will do it. What about the ship? This first order is only used to draw the following information. For better and more efficient use of EF4.1/4.3, you need

Good tools. before crossing the river, we may introduce these tools first.

(1) NuGet plug-in. This tool can help us find some stable class libraries provided by Microsoft and some templates for ORM programming. However, some class libraries I use are not flattering templates.

But not.

(2) EF Power Tool. In EF4.0, we create emdx to map object tables. In addition, 4.1/4.3/provides a high level of flexibility, so you can perform table ing operations and class definitions on your own. However, for a large number of tables, it is necessary to establish a ing one by one. Therefore, the EF Power Tool provides us with great help.

: Http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d/

Instruction: http://www.cnblogs.com/LingzhiSun/archive/2011/06/13/EFPowerTool_2.html

With this convenient tool, classes, ing, and DbContext are generated. We can directly write the business.

Sometimes tools help us get twice the result with half the effort.

Iii. Tips for using EF4.1/4.3

(1) Multi-table join query statement:

Var query = (from m in context. Dic_PropertyClassDef.Include ("Dic_PropertyTypeDef ")
. Include ("Dic_PropertyTypeDef.Dic_PropertyValueDef ")
. Include ("Dic_PropertyTypeDef.Dic_PropertyOptValueDef ")

This is a multi-table join query statement. You can keep InCude. However, it is recommended that you use SQL or stored procedures for complicated services.

(2) The in statement in EF4.1/4.3:

Var query = Entities. Where (p => ids. Contains (p. ID ));
Ids is the id column you passed in this sentence. It can be an array or a wildcard (List <int>)

(3) paging in EF

Query. OrderByDescending (r => r. PropID). Skip (startRowIndex). Take (maximumRows). ToList ();

StartRowIndex is the starting index and the number of maximumRows to query. For example, startRowIndex = 0 and maximumRows = 10 are 10 records starting from 0.

EF distribution must be used with OrderByDescending.

(4), add, delete, and modify are the same as ef4.0. My blog has such articles. You can check it out.

Now, the transition is written here. It is a small summary of the project's end. I am bailing. I hope you will give me some advice on anything wrong in this article. Haha, it's a mess in the hot summer.