Code First is a bad name. Our understanding of Code First has been wrong over the years! Are you shocked ?, Codebad

Code First is a bad name. Our understanding of Code First has been wrong over the years! Are you shocked ?, Codebad

I was shocked when I saw this. It is estimated that the vast majority of people, like me, have never known the true meaning of Code Fisrt over the years. The following is a description of this situation. You are welcome to watch it out. please correct me if there is any improper translation. Thank you. If you are surprised, please like it !, If you are not satisfied, just make a brick. E is good. You can directly read the original text below.

Address: http://blogs.msdn.com/ B /adonet/archive/2014/10/21/ef7-what-does-code-first-only-really-mean.aspx

Reprinted please indicate the source: http://www.cnblogs.com/VolcanoCloud/p/4483708.html

Before entering the topic, let me talk about it. It is said that Microsoft initially wanted to use Code Only. Later, because their marketing team did not know whether it was intended to correspond to Database First and Model First, the current Code First emerged.

What does EF7-"Code First only" actually mean?

Not long ago, we wrote in our blog that we plan to build EF7 into a lightweight and scalable version. It will be a brand new platform and data storage (data stores ). We also mentioned the EF7 plan at the TechEd North America Conference on EF.

Before EF7, there are two ways to store the model: XML-based EDMX file format and code-based. Starting from EF7, we will no longer support the EDMX format, but only support a single code-based storage.The removal of XML-based EDMX has aroused many concerns. Many of them are due to misunderstanding that "EF7 will only support the true meaning of" Code First.

Code First is a bad name

Before EF4.1, we only supported the Database First and Model First methods. They both use the boxes and straight lines provided by the EF designer to indicate that they are stored in xml-based format. the model in the edmx file. Database First generates a Model from an existing Database. Model First generates a Database from the Model created in the EF designer.

Code First is introduced in EF4.1. unfortunately, many people think based on its name that it is in the Code to define the model, and then from the model born in the database, in fact, code First can also be used for an existing database or to generate a new database. A tool can reverse an existing database to generate the Code First model. This tool was originally included in the EF toolset and was later integrated into the wizard for generating the EDMX model in EF6.1.

In other words,Code First is not the third method relative to Database First and Dodel First, but a solution that can replace the EDMX file format.. Technically, Code First supports both Database First and Model First.

This is indeed confusing. We have taken the wrong name.It may be called "code-base modeling" to be clearer.

 

Is it better to use the code-base modeling name?

Obviously, we have to maintain two different modeling methods. In addition, I chose to support code-base modeling only in EF7 for other reasons.

 

1. source code control merging, conflict, and code review become difficult.When we store the entire model in an xml file, we receive a lot of feedback from developers. A simple change to the model will lead to a big difference in xml. On the other hand, the opening staff must merge and review the source code.

 

2. Developers know how to write and debug code.In some simple projects, it is undeniable that the designer brings convenience. However, the requirements of many projects exceed the capabilities of the designer. In this case, you need to modify something in the xml file, but this is much harder for most developers than modifying code.

 

3. Ability to customize models based on the environment.We hear from customers that this is a common requirement. For example, when running a program, you need to specify the architecture or Multi-tenant database with the table prefix ). You may also slightly adjust your model at runtime based on different database providers. To meet these requirements, it is difficult to use an xml file-based model. On the other hand, it is easy to define the model by using conditional logic in the code.

 

4. Code-based models are not repeated.The CLR type can also be used to build models, as well as take care of common configration conventions. Assume that a Blog entity has a primary key BlogId. In an EDMX-based model, the CLR class has a BlogId attribute, an xml BlogId attribute (plus columns and ing), and other xml content to identify BlogId as an entity key. However, in a code-based model, it is enough to have the BlogId attribute of a CLR type.

 

5. It is easier to provide useful error information in the code.We have all seen the Error "Error 3002: Problem in mapping fragmets starting at line 46... (3002: ing segment Problem, starting at line 46 of the file. This report from the EDMX model should be improved. However, it is easy to throw a configuration error exception in the code-based model.

We may have noticed that in EF6.x, useful error messages are often not obtained from Code-First pipeline, this is because it is built on the infrastructure designed for the EDMX model. In EF7, this will not happen.

 

There is also a very important feature that may be implemented by EDMX, but it can only be implemented in code-based models.

　　Database migration (Migrations)It allows you to create a database from a code-based model and evolve as the model changes. For the EDMX model, you can generate an SQL script that matches the model to create a database, but there is no way to generate a script that contains model changes and apply model changes to existing databases.

 

So what will EF7 bring?

In EF7, all models are represented by code. Some tools can reverse generate a model from an existing database (as in EF6.x). You can also create a model on behalf of the database and then use the database migration (migrations) technology generates a database (updated when the model changes ).

It may have been noted that we have improved the database migration (migrations) technology in EF7 to solve problems many people encounter when using it in the team environment.

 

How to solve this problem...

We have discussed all the things we can think of. Selecting code-based modeling only is a reason for positive solution selection. However, the problem arises.

 

How to visualize the model?

The EF designer is all about model visualization. In EF6.x, we have the ability to generate a read-only visual model for code-based models (using the EF toolset ). in EF7, we also think this is a good method. Visualization is absolutely valuable, especially when you have a large number of associated classes.

With the advent of Roslyn (a compiler launched by Microsoft), we can also see a readable and writable Design Based on the code model. Obviously, this is not achieved immediately (probably forever), because it is a huge job. But he is our goal.

 

How can we solve the "update model from database" scenario?

"Update a model from a database" is a process that allows you to immediately pull an additional database object (or modify an existing database object) to your EDMX model. Unfortunately, this implementation is not a good feature. Because you usually lose the ability to customize the model, You have to manually modify the xml file to adjust the model.

For Code First, you can re-run the reverse engineering process to regenerate your model. In some basic scenarios, this method works well. But what you care about is that the newly generated code will overwrite the custom part of your model. Many user-defined functions are difficult to apply without modifying the build code.

The first step in EF7 is to provide a tool that is the same as the reverse tool released for the first time in EF6.x. We have a lot of ideas on how to implement Incremental Model updates without having to rewrite the previously defined code. It supports simple addition scenarios to use the Roslyn compiler to modify existing code. We are thinking about these ideas and there is no definite plan yet.

 

How to solve an existing model?

We will not conceal the huge changes that EF7 has made to EF6.x. Although we maintain the original concept and top-level API, the underlying implementation has undergone great changes. For this reason, we do not recommend that you immediately transfer an existing model to EF7. We will continue to develop EF6.x for a while.

　　

Do all people need to change?

We don't deceive people, we can't make everyone change. We know that some people prefer the EF designer and EDMX more than code-based modeling.

At the same time, we must balance time and resources. We will share with you the best features and features we know to help developers compile a successful application. This is not our rashness, because it is the best choice for the long-term development and users of the Entity Framework. The ultimate goal is to provide a faster and simpler stack to use, and reduce the cost of supporting high demands. We have been striving in this direction.

 

In translation, there must be a lot of improper things. please correct me. At the same time, please click on the recommendation below to support it. Thank you! I hope you will gain some benefits.

 

Next is another MSDN blog, which is Chinese. You can also go to the original article: https://msdn.microsoft.com/zh-cn/magazine/dn890367.aspx. I will extract a piece of content that I think is helpful to you as follows:

Abandon EDMX, but continue to give priority to database

The Entity Framework currently uses two methods to describe the model. One uses EDMX In the designer, and the other involves classes, that is, DbContext and ing used by the code-first API. If you are using EDMX and the designer, EF will create a memory model from XML after EDMX at runtime. If you select the code priority path, EF will create the same memory model by reading the class (that is, the DbContext and ing you provide. Since then, EF has worked in the same way, no matter how you describe the model. Note that through the EDMX/designer workflow, you can also obtain the POCO class and DbContext for your use in the code. However, because EDMX exists, it is not used to create models in the memory. It is important to understand the following: EF7 will not support the designer-based EDMX model. It cannot read edmx xml at runtime to create an in-memory model. It only uses the code-first workflow.

When the team published a blog post on this issue, it caused a lot of developers to panic. This is partly because many developers are not aware of the possibility of reverse engineering databases to POCO classes, DbContext, and ing. In other words, you can get the code priority model from the database. This goal can be achieved through the first release of EF Power Tools Beta in early 2011. This tool is supported by the EF6.1 designer and is certainly supported by EF7. I have mentioned many times that the "code first" name is confusing and misleading. It was initially called "code-only", and later changed the name to "code-First" to perfectly match "database-first" and "model-first ".

Therefore, you do not need a designer or EDMX to start with an existing database.

However, what if you have an existing EDMX model and do not want to lose the ability to use the designer? Some third-party designers support Entity frameworks, such as LLBLGen Pro Designer (bit. ly/11OLlN2) that has already supported EF code priority and Devart Entity Developer (bit. ly/1yHWbB2 ). Find tools that may provide designers supporting EF7 and other possible software.

Remember another way: Stick to EF6!