您将“绘制”您的模型，并让工作流程生成您的数据库脚本，让 T4 模板生成您的 POCO 实体。您将失去对实体和数据库的部分控制，但对于小型简单项目，您将非常高效。
如果您想要 POCO 实体中的附加功能，您必须 T4 修改模板或使用部分类。
对数据库的手动更改很可能会丢失，因为您的模型定义了数据库。如果您安装了数据库生成电源包，则效果会更好。它将允许您更新数据库架构（而不是重新创建）或更新 VS 中的数据库项目。
我预计 EF 4.1 还会有一些与代码优先与模型/数据库优先相关的其他功能。 Code First 中使用的 Fluent API 并不提供 EDMX 的所有功能。我希望存储过程映射、查询视图、定义视图等功能在首先使用模型/数据库和 DbContext（我还没有尝试过）时起作用，但它们在代码中不起作用。
I think the differences are:
Code first
Very popular because hardcore programmers don't like any kind of designers and defining mapping in EDMX xml is too complex.
Full control over the code (no autogenerated code which is hard to modify).
General expectation is that you do not bother with DB. DB is just a storage with no logic. EF will handle creation and you don't want to know how it does the job.
Manual changes to database will be most probably lost because your code defines the database.
Database first
Very popular if you have DB designed by DBAs, developed separately or if you have existing DB.
You will let EF create entities for you and after modification of mapping you will generate POCO entities.
If you want additional features in POCO entities you must either T4 modify template or use partial classes.
Manual changes to the database are possible because the database defines your domain model. You can always update model from database (this feature works quite well).
I often use this together VS Database projects (only Premium and Ultimate version).
Model first
IMHO popular if you are designer fan (= you don't like writing code or SQL).
You will "draw" your model and let workflow generate your database script and T4 template generate your POCO entities. You will lose part of the control on both your entities and database but for small easy projects you will be very productive.
If you want additional features in POCO entities you must either T4 modify template or use partial classes.
Manual changes to database will be most probably lost because your model defines the database. This works better if you have Database generation power pack installed. It will allow you updating database schema (instead of recreating) or updating database projects in VS.
I expect that in case of EF 4.1 there are several other features related to Code First vs. Model/Database first. Fluent API used in Code first doesn't offer all features of EDMX. I expect that features like stored procedures mapping, query views, defining views etc. works when using Model/Database first and DbContext (I haven't tried it yet) but they don't in Code first.
Database first and model first has no real differences. Generated code are the same and you can combine this approaches. For example, you can create database using designer, than you can alter database using sql script and update your model.
When you using code first you can't alter model without recreation database and losing all data. IMHO, this limitation is very strict and does not allow to use code first in production. For now it is not truly usable.
Second minor disadvantage of code first is that model builder require privileges on master database. This doesn't affect you if you using SQL Server Compact database or if you control database server.
Advantage of code first is very clean and simple code. You have full control of this code and can easily modify and use it as your view model.
I can recommend to use code first approach when you creating simple standalone application without versioning and using model\database first in projects that requires modification in production.
3 reasons to use code first design with Entity Framework
1) Less cruft, less bloat
Using an existing database to generate a .edmx model file and the associated code models results in a giant pile of auto generated code. You’re implored never to touch these generated files lest you break something, or your changes get overwritten on the next generation. The context and initializer are jammed together in this mess as well. When you need to add functionality to your generated models, like a calculated read only property, you need to extend the model class. This ends up being a requirement for almost every model and you end up with an extension for everything.
With code first your hand coded models become your database. The exact files that you’re building are what generate the database design. There are no additional files and there is no need to create a class extension when you want to add properties or whatever else that the database doesn't need to know about. You can just add them into the same class as long as you follow the proper syntax. Heck, you can even generate a Model.edmx file to visualize your code if you want.
2) Greater Control
When you go DB first, you’re at the mercy of what gets generated for your models for use in your application. Occasionally the naming convention is undesirable. Sometimes the relationships and associations aren't quite what you want. Other times non transient relationships with lazy loading wreak havoc on your API responses.
While there is almost always a solution for model generation problems you might run into, going code first gives you complete and fine grained control from the get go. You can control every aspect of both your code models and your database design from the comfort of your business object. You can precisely specify relationships, constraints, and associations. You can simultaneously set property character limits and database column sizes. You can specify which related collections are to be eager loaded, or not be serialized at all. In short, you are responsible for more stuff but you’re in full control of your app design.
3)Database Version Control
This is a big one. Versioning databases is hard, but with code first and code first migrations, it’s much more effective. Because your database schema is fully based on your code models, by version controlling your source code you're helping to version your database. You’re responsible for controlling your context initialization which can help you do things like seed fixed business data. You’re also responsible for creating code first migrations.
When you first enable migrations, a configuration class and an initial migration are generated. The initial migration is your current schema or your baseline v1.0. From that point on you will add migrations which are timestamped and labeled with a descriptor to help with ordering of versions. When you call add-migration from the package manager, a new migration file will be generated containing everything that has changed in your code model automatically in both an UP() and DOWN() function. The UP function applies the changes to the database, the DOWN function removes those same changes in the event you want to rollback. What’s more, you can edit these migration files to add additional changes such as new views, indexes, stored procedures, and whatever else. They will become a true versioning system for your database schema.
Code-first appears to be the rising star. I had a quick look at Ruby on Rails, and their standard is code-first, with database migrations.
If you are building an MVC3 application, I believe Code first has the following advantages:
Easy attribute decoration - You can decorate fields with validation, require, etc.. attributes, it's quite awkward with EF modelling
No weird modelling errors - EF modelling often has weird errors, such as when you try to rename an association property, it needs to match the underlying meta-data - very inflexible.
Not awkward to merge - When using code version control tools such as mercurial, merging .edmx files is a pain. You're a programmer used to C#, and there you are merging a .edmx. Not so with code-first.
Contrast back to Code first and you have complete control without all the hidden complexities and unknowns to deal with.
I recommend you use the Package Manager command line tool, don't even use the graphical tools to add a new controller to scaffold views.
DB-Migrations - Then you can also Enable-Migrations. This is so powerful. You make changes to your model in code, and then the framework can keep track of schema changes, so you can seamlessly deploy upgrades, with schema versions automatically upgraded (and downgraded if required). (Not sure, but this probably does work with model-first too)
Update
The question also asks for a comparison of code-first to EDMX model/db-first. Code-first can be used for both of these approaches too:
Model-First: Coding the POCOs first (the conceptual model) then generating the database (migrations); OR
EF 代码优先和模型优先起初看起来很酷，并且提供了数据库独立性，但是在这样做时，它不允许您指定我认为非常基本和常见的数据库配置信息。例如，表索引、安全元数据或具有包含多个列的主键。我发现我想使用这些和其他常见的数据库功能，因此无论如何都必须直接进行一些数据库配置。
我发现 DB First 期间生成的默认 POCO 类非常干净，但缺乏非常有用的数据注释属性或到存储过程的映射。我使用 T4 模板来克服其中一些限制。 T4 模板非常棒，尤其是与您自己的元数据和部分类结合使用时。
模型优先似乎有很大的潜力，但在复杂的数据库模式重构过程中给我带来了很多错误。不知道为什么。
I use EF database first in order to provide more flexibility and control over the database configuration.
EF code first and model first seemed cool at first, and provides database independence, however in doing this it does not allow you to specify what I consider very basic and common database configuration information. For example table indexes, security metadata, or have a primary key containing more than one column. I find I want to use these and other common database features and therefore have to do some database configuration directly anyway.
I find the default POCO classes generated during DB first are very clean, however lack the very useful data annotation attributes, or mappings to stored procedures. I used the T4 templates to overcome some of these limitations. T4 templates are awesome, especially when combined with your own metadata and partial classes.
Model first seems to have lots of potential, but is giving me lots of bugs during complex database schema refactoring. Not sure why.
我仍然首先设计我的表，然后内部构建的工具为我生成 POCO，因此它承担了为每个 poco 对象执行重复任务的负担。
当您使用源代码控制系统时，您可以轻松地跟踪 POCO 的历史记录，但对于设计者生成的代码来说就没那么容易了。
我的 POCO 有一个底座，这让很多事情变得非常简单。
我有所有表的视图，每个基本视图都带来了我的外键的基本信息，我的视图 POCO 派生自我的 POCO 类，这又非常有用。
最后我不喜欢设计师。
Working with large models were very slow before the SP1, (have not tried it after the SP1, but it is said that is a snap now).
I still Design my tables first, then an in-house built tool generates the POCOs for me, so it takes the burden of doing repetitive tasks for each poco object.
when you are using source control systems, you can easily follow the history of your POCOs, it is not that easy with designer generated code.
I have a base for my POCO, which makes a lot of things quite easy.
I have views for all of my tables, each base view brings basic info for my foreign keys and my view POCOs derive from my POCO classes, which is quite usefull again.
IMHO I think that all the models have a great place but the problem I have with the model first approach is in many large businesses with DBA's controlling the databases you do not get the flexibility of building applications without using database first approaches. I have worked on many projects and when it came to deployment they wanted full control.
So as much as I agree with all the possible variations Code First, Model First, Database first, you must consider the actual production environment. So if your system is going to be a large user base application with many users and DBA's running the show then you might consider the Database first option just my opinion.
I think one of the Advantages of code first is that you can back up all the changes you've made to a version control system like Git. Because all your tables and relationships are stored in what are essentially just classes, you can go back in time and see what the structure of your database was before.
发布评论
评论（10）
我认为差异在于：
代码优先
数据库优先
模型优先
我预计 EF 4.1 还会有一些与代码优先与模型/数据库优先相关的其他功能。 Code First 中使用的 Fluent API 并不提供 EDMX 的所有功能。我希望存储过程映射、查询视图、定义视图等功能在首先使用模型/数据库和 DbContext（我还没有尝试过）时起作用，但它们在代码中不起作用。
I think the differences are:
Code first
Database first
Model first
I expect that in case of EF 4.1 there are several other features related to Code First vs. Model/Database first. Fluent API used in Code first doesn't offer all features of EDMX. I expect that features like stored procedures mapping, query views, defining views etc. works when using Model/Database first and
DbContext(I haven't tried it yet) but they don't in Code first.我认为“编程实体框架”的作者 Julie Lerman 的这个简单的“决策树”应该有助于更有信心地做出决定：
更多信息 这里。
I think this simple "decision tree" by Julie Lerman the author of "Programming Entity Framework" should help making the decision with more confidence:
More info Here.
数据库优先和模型优先没有真正的区别。
生成的代码是相同的，您可以组合这些方法。例如，您可以使用设计器创建数据库，然后使用 SQL 脚本更改数据库并更新模型。
当您首先使用代码时，您无法在不重新创建数据库并丢失所有数据的情况下更改模型。恕我直言，这个限制非常严格，不允许在生产中首先使用代码。目前还不能真正使用。
代码优先的第二个小缺点是模型构建器需要主数据库的权限。如果您使用 SQL Server Compact 数据库或控制数据库服务器，这不会影响您。
代码优先的优点是代码非常干净和简单。您可以完全控制此代码，并且可以轻松修改它并将其用作您的视图模型。
当您创建简单的独立应用程序而不进行版本控制并在需要在生产中进行修改的项目中首先使用模型\数据库时，我建议使用代码优先方法。
Database first and model first has no real differences.
Generated code are the same and you can combine this approaches. For example, you can create database using designer, than you can alter database using sql script and update your model.
When you using code first you can't alter model without recreation database and losing all data. IMHO, this limitation is very strict and does not allow to use code first in production. For now it is not truly usable.
Second minor disadvantage of code first is that model builder require privileges on master database. This doesn't affect you if you using SQL Server Compact database or if you control database server.
Advantage of code first is very clean and simple code. You have full control of this code and can easily modify and use it as your view model.
I can recommend to use code first approach when you creating simple standalone application without versioning and using model\database first in projects that requires modification in production.
引用相关部分 http:// www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework
Quoting the relevant parts from http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework
代码优先似乎是后起之秀。我快速浏览了 Ruby on Rails，他们的标准是代码优先，带有数据库迁移。
如果您正在构建 MVC3 应用程序，我相信 Code First 具有以下优点：
更新
该问题还要求将代码优先与 EDMX 模型/数据库优先进行比较。代码优先也可用于这两种方法：
Code-first appears to be the rising star. I had a quick look at Ruby on Rails, and their standard is code-first, with database migrations.
If you are building an MVC3 application, I believe Code first has the following advantages:
Update
The question also asks for a comparison of code-first to EDMX model/db-first. Code-first can be used for both of these approaches too:
我首先使用 EF 数据库，以便提供更大的灵活性和对数据库配置的控制。
EF 代码优先和模型优先起初看起来很酷，并且提供了数据库独立性，但是在这样做时，它不允许您指定我认为非常基本和常见的数据库配置信息。例如，表索引、安全元数据或具有包含多个列的主键。我发现我想使用这些和其他常见的数据库功能，因此无论如何都必须直接进行一些数据库配置。
我发现 DB First 期间生成的默认 POCO 类非常干净，但缺乏非常有用的数据注释属性或到存储过程的映射。我使用 T4 模板来克服其中一些限制。 T4 模板非常棒，尤其是与您自己的元数据和部分类结合使用时。
模型优先似乎有很大的潜力，但在复杂的数据库模式重构过程中给我带来了很多错误。不知道为什么。
I use EF database first in order to provide more flexibility and control over the database configuration.
EF code first and model first seemed cool at first, and provides database independence, however in doing this it does not allow you to specify what I consider very basic and common database configuration information. For example table indexes, security metadata, or have a primary key containing more than one column. I find I want to use these and other common database features and therefore have to do some database configuration directly anyway.
I find the default POCO classes generated during DB first are very clean, however lack the very useful data annotation attributes, or mappings to stored procedures. I used the T4 templates to overcome some of these limitations. T4 templates are awesome, especially when combined with your own metadata and partial classes.
Model first seems to have lots of potential, but is giving me lots of bugs during complex database schema refactoring. Not sure why.
在SP1之前处理大型模型非常慢（SP1之后没有尝试过，但据说现在很快）。
我仍然首先设计我的表，然后内部构建的工具为我生成 POCO，因此它承担了为每个 poco 对象执行重复任务的负担。
当您使用源代码控制系统时，您可以轻松地跟踪 POCO 的历史记录，但对于设计者生成的代码来说就没那么容易了。
我的 POCO 有一个底座，这让很多事情变得非常简单。
我有所有表的视图，每个基本视图都带来了我的外键的基本信息，我的视图 POCO 派生自我的 POCO 类，这又非常有用。
最后我不喜欢设计师。
Working with large models were very slow before the SP1, (have not tried it after the SP1, but it is said that is a snap now).
I still Design my tables first, then an in-house built tool generates the POCOs for me, so it takes the burden of doing repetitive tasks for each poco object.
when you are using source control systems, you can easily follow the history of your POCOs, it is not that easy with designer generated code.
I have a base for my POCO, which makes a lot of things quite easy.
I have views for all of my tables, each base view brings basic info for my foreign keys and my view POCOs derive from my POCO classes, which is quite usefull again.
And finally I dont like designers.
数据库优先方法示例：
无需编写任何代码：
ASP.NET MVC / MVC3 数据库第一种方法/数据库优先
我认为它比其他方法更好，因为这种方法的数据丢失更少。
Database first approach example:
Without writing any code:
ASP.NET MVC / MVC3 Database First Approach / Database first
And I think it is better than other approaches because data loss is less with this approach.
恕我直言，我认为所有模型都有一个很好的位置，但我对模型优先方法的问题是，在许多由 DBA 控制数据库的大型企业中，如果不使用数据库优先方法，您就无法获得构建应用程序的灵活性。我参与过许多项目，当涉及到部署时，他们想要完全控制。
因此，尽管我同意所有可能的变化：代码优先、模型优先、数据库优先，但您必须考虑实际的生产环境。因此，如果您的系统将是一个大型用户基础应用程序，有许多用户和 DBA 来运行，那么您可能会考虑数据库第一选项，这只是我的意见。
IMHO I think that all the models have a great place but the problem I have with the model first approach is in many large businesses with DBA's controlling the databases you do not get the flexibility of building applications without using database first approaches. I have worked on many projects and when it came to deployment they wanted full control.
So as much as I agree with all the possible variations Code First, Model First, Database first, you must consider the actual production environment. So if your system is going to be a large user base application with many users and DBA's running the show then you might consider the Database first option just my opinion.
我认为代码优先的优点之一是您可以备份对 Git 等版本控制系统所做的所有更改。因为所有表和关系都存储在本质上只是类中，所以您可以回到过去并查看数据库之前的结构。
I think one of the Advantages of code first is that you can back up all the changes you've made to a version control system like Git. Because all your tables and relationships are stored in what are essentially just classes, you can go back in time and see what the structure of your database was before.