不生成数据库但映射到现有表
我们希望首先使用模型为我们的应用程序生成干净的 EF 模型，但我们不想让模型生成新的数据库架构，而是希望手动在实体内将表映射到现有的一个或多个数据库表。有这方面的机制吗？
We'd like to use model first to generate clean EF models for our application but instead of having the model generate a new db schema we'd like to then manually do a table mapping within the entity to an existing database table or tables. Is there a mechanism for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当然是。
这称为实体框架代码优先，这是一个帮助您入门的好教程。
这个想法是您创建一些与您的存储库/数据库类分开的 POCO 类。在此存储库/数据库类中，您定义 POCO 之间的所有关系。幸运的是，实体框架有许多您可以利用的约定，这意味着您可能不需要定义每个关系和规则。
例如。如果您的类名为
User，那么它将假设（默认情况下，除非您覆盖它）数据库表名为Users并且 POCO 中的主键标识字段将是UserId并且与数据库表中的相同。Sure is.
This is called Entity Framework Code-First and this is a good tutorial to help getting you started.
The idea is that you create some POCO classes seperate to your Repository/Database class. In this Repository/Database class, you define all the relationships between your POCO's. Fortunately, Entity Framework has a number of conventions which you can leverage off, which means you might not need to define every relationship and rule.
Eg. If your class is called
User, then it will assume (by default, unless you override this) that the database table is calledUsersand the primary key identity field in the POCO will beUserIdand the same in the database table.不确定我是否理解这个问题，但是当您使用向导创建新的实体数据模型时，第一步允许您“从数据库生成”，只需将其指向您现有的数据库即可。然后，您可以删除不需要的表和/或手动修改表映射。还可以选择首先要在模型中表示哪些表。
Not sure if I understand the question, but when you use the wizard to create a new Entity data model, the first step allows you to "Generate from database", just point it to your existing DB. You can then cut out the tables you don't want and/or modify the table mappings manually. There's also the option to pick and choose which tables you want represented in your model in the first place.
我还使用 EF Model First 和 EF 4.0 寻找此选项。我还想从一个小的干净模型开始，因为我们有一个巨大的企业级应用程序，我们无法将所有内容导入到一个 edmx 中，因为由于我们数据库的规模，它甚至不可见。
因此，我们希望首先考虑模型作为构建更小、更清晰的模型的选项，然后将它们映射到数据库中的现有表。
这就是我们学到的。
模型首先生成将进入“现有数据库”的数据库模式。最初这有点误导，因为人们认为它创建了一个新的数据库。它实际上并不创建数据库本身。数据库必须存在，然后模型首先生成将进入数据库的 t-sql 脚本。
它会在项目中的新 .sql 文件中生成这些脚本，然后您可以查看该脚本或将其发送给 dba（如果有）。
假设您的表不存在，它将生成这些脚本作为表的创建。
因此，举个例子，如果您在模型中创建了一个“客户”实体，它将生成一个包含 CREATE TABLE T-sql 的脚本 (*.sql) 文件，用于为您的客户实体创建客户表，然后您可以在该表上运行现有的 sql 数据库。
这就是它的设计目的，基本上为新模型生成干净的表。
这是否意味着如果您的表已经存在，您根本无法使用它？不，你可以使用它。您只是不会运行它生成的创建脚本。我不相信它真的是为此设计的，但我们对此进行了测试，它确实有效。
您可能会遇到模型优先的其他问题，并且我们发现的一个限制是，因为模型优先旨在生成新的数据库模式，所以您无法映射到现有的存储过程。这对我们来说是一个问题，因此我们首先消除了模型作为我们架构的选项。
我们现在正在审查代码优先和数据库优先作为企业级系统的选项，现在我们倾向于代码优先。代码优先允许您创建可以使用的小型、可管理的上下文，这在大型企业级应用程序中似乎非常有益。
I also looked for this option using EF Model first with EF 4.0. I also wanted to start with a small clean model because we have a huge enterprise level application in which we cannot import everything into one edmx because it is not even viewable due to the scale of our database.
So we wanted to consider model first as an option to build smaller, cleaner models and then map them to our existing tables in our db.
This is what we learned.
Model first generates the db schema that will go into an "existing db". It is somewhat misleading initially because people think that it creates a new db. It does not actually create the db itself. The db must exist and then model first generates the t-sql scripts that will go into the db.
It generates these scripts in a new .sql file in your project which you can then view or send off to a dba if you have one.
It will generate these scripts as CREATES for tables assuming that your tables do not exist.
So, as an example, if you created a "Customer" entity in the model, it will generate a script (*.sql) file containing CREATE TABLE T-sql to create the customer table for your customer entity that you can then run on an existing sql database.
So this is what it is designed to do, generate clean tables for a new model basically.
Does this mean that you can't use it at all if your tables already exist? No, you can use it. You just wouldnt run the Create scripts that it generates. I don't believe it was really designed for this but we tested this and it did work.
Where you may run into additional problems with model first, and a limitation we have found, is that because model first is designed to generate new db schema, you cannot map to existing stored procedures. This was a problem for us and so we eliminated model first as an option for our architecture.
We are reviewing code first and db first right now as options for an enterprise level system and right now we are leaning toward code first at this time. Code first allows you to create small, manageable contexts that you can work with and this seems very beneficial in a large enterprise level application.