代码优先方法与数据库优先方法
我正在开发一个 asp.net MVC 3 Web 应用程序，并且首先使用数据库，但是在使用实体框架将数据库表映射到实体类之后，我正在与这些表进行交互，因为我将使用代码优先方法进行交互通过将数据库表作为类和对象来处理。
因此，在将表映射到实体类之后，我发现代码优先方法和数据库优先方法非常相似，但除了从头开始编写实体类（如代码优先）之外，我从现有数据库表创建了实体类 - 这是就我而言更容易、更方便。
那么，是否存在一些特定情况，除非我使用一种方法而不是另一种方法，否则我将无法执行某些功能，而到目前为止我还找不到任何方法？
I am working on an asp.net MVC 3 web application and I am using database first, but after I have mapped the DB tables into entity classes using entity framework, I am interacting with these tables as I will be interacting on the code first approach by dealing with Database tables as classes an objects.
So after mapping the tables into entity classes I find that the code first approach and DB first are very similar but except of start writing the entities classes from scratch (as in code first) I have created the entity classes from existing database tables - which is easier and more convenient in my case.
So are there specific cases on which i will not be able to do some functionalities unless i am using one approach over the other which till now i cannot find any?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在使用 EF 4.1 之前的 db-1st EDMX 处理过许多令人头痛的问题后，我偏向于代码优先。但我不会传播它。
除了直接存储过程映射之外， Pawel 的回答中提到的函数导入功能注释，当您使用 db-first 时，您将无法更改生成文件中的命名空间或任何其他代码。据我所知，所有文件都嵌套在 .tt 文件下。如果有办法将它们移动到逻辑文件夹中&你的项目中的命名空间，那么我不知道它。
另外，如果您想将 DbContext 与实体分离到单独的项目中，我记得这在 EF 4.1 之前是可能的。但它更麻烦，因为每次数据库更改后您都必须在两个 .tt 文件上运行自定义工具。对于代码优先，这非常简单，因为您正在处理纯 OOP。
Having dealt with many many headaches using db-1st EDMX pre EF 4.1, I am partial to code-first. But I'm not going to evangelize it.
In addition to the direct sproc mapping & function import features mentioned in Pawel's answer & comment, you won't be able to change the namespaces or any other code in the generated files when you use db-first. Afaik all of the files are nested under the .tt file. If there is a way to move them into logical folders & namespaces in your project, then I'm not aware of it.
Also if you ever want to separate your DbContext into a separate project from your entities, I recall this was possible pre-EF 4.1. But it was more cumbersome, because you had to run custom tool on both .tt files after each db change. With code-first this is pretty straightforward because you're dealing with pure OOP.
我认为 CodeFirst 的最大限制（与 ModelFirst/DatabaseFirst 方法相比）是您无法将 CUD 操作映射到存储过程。如果您不打算这样做，那么您就可以开始了。
更具体地说 - 您可以在 DbSet 上使用 SqlQuery 方法调用存储过程，这将导致跟踪返回的实体，或者在 Database 类上使用更通用的 SqlQuery 和 ExecuteSqlCommand（对于 Database.SqlQuery，返回的对象不必是实体，并且有不跟踪这些对象）。就是这样。您无法将创建/更新/删除操作映射到存储过程。也不支持 FunctionImports
编辑
现在可以将 CUD 操作映射到 EF6 中的存储过程
I think that the biggest limitation of CodeFirst (as compared to ModelFirst/DatabaseFirst approaches) is that you cannot map your CUD operations to stored procedures. If you are not planning to do that then you should be good to go.
To be more specific - You can invoke stored procedures using SqlQuery method on DbSet which will cause the returned entities to be tracked or more general SqlQuery and ExecuteSqlCommand on Database class (for Database.SqlQuery the returned objects do not have to be entities and there is no tracking for these objects). That's about it. You cannot map Create/Update/Delete operations to stored procedures. FunctionImports are not supported as well
EDIT
It's possible to map CUD operations to stored procedures in EF6 now