我正在开发一个asp.net MVC 3 Web应用程序，我首先使用数据库，但是在使用实体框架将数据库表映射到实体类之后，我正在与这些表进行交互，因为我将在代码第一种方法是将Database表作为类对象进行处理。
因此，在将表映射到实体类之后，我发现代码第一种方法和DB首先非常相似，但除了从头开始编写实体类之外（在代码中首先）我已经从现有数据库表创建了实体类 - 在我的情况下，这更方便，更方便。
那么除非我使用一种方法而不是另一种方法，否则我将无法做某些功能的特定情况，直到现在我找不到任何方法？
答案 0 :(得分：2)
使用db-1st EDMX pre EF 4.1解决了许多令人头疼的问题，我偏向代码优先。但我不打算传福音。
除了直接的sproc映射＆amp; Pawel的答案中提到的功能导入功能＆amp;注释，当您使用db-first时，您将无法更改生成的文件中的命名空间或任何其他代码。 Afaik所有文件都嵌套在.tt文件下。如果有办法将它们移动到逻辑文件夹＆amp;你的项目中的命名空间，然后我不知道它。
另外，如果您想将DbContext分离成与实体分开的项目，我记得这可能是在EF 4.1之前。但它更麻烦，因为每次db更改后你必须在两个.tt文件上运行自定义工具。使用代码优先，这非常简单，因为您正在处理纯OOP。
答案 1 :(得分：1)
我认为CodeFirst的最大限制（与ModelFirst / DatabaseFirst方法相比）是您无法将CUD操作映射到存储过程。如果你不打算这样做那么你应该好好去。 更具体一点 - 您可以在DbSet上使用SqlQuery方法调用存储过程，这将导致返回的实体被跟踪，或者在Database类上更常见的SqlQuery和ExecuteSqlCommand（对于Database.SqlQuery，返回的对象不必是实体，并且有没有跟踪这些对象）。就是这样。您无法将创建/更新/删除操作映射到存储过程。
也不支持FunctionImports修改
现在可以将CUD操作映射到EF6中的存储过程