我应该为每个表创建一个 ADO.NET 实体数据模型，还是为整个数据库创建一个 ADO.NET 实体数据模型？
您是否应该为每个表使用一个 ADO.NET 实体数据模型？ 或者一个用于整个数据库的数据库，其中关系也被路由，等等......
Are you supposed to use one ADO.NET Entity Data Model for each table? Or one for your entire database where relationships are also routed, etc...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
对整个数据库执行此操作。 如果您为每个表创建一个数据模型，您将无法从导航关系中受益。
如果您使用像 Subversion 这样的签出/合并源代码控制，请注意设计者会破坏 XML，以致 Subversion 难以合并它。 在这种情况下，您通常必须每次都重新生成整个模型或手动合并。
Do it for the entire database. If you make a data model for every table you will not have the benefit of navigating the relationships.
If you're using checkout/merge source control like Subversion, be aware that the designer munges the XML to the extent that Subversion struggles to merge it. In this case you usually have to regenerate the entire model every time or merge by hand.
我对相关表使用实体数据模型。 根据数据库的大小，如果表少于 20 或 25 个，我只会创建一个模型。 为每个表创建单独的模型有点昂贵，因为每个模型都有一个要创建的 EntityConnection 对象。
我发现如果我有 5 到 15 个表，我可以很好地维护模型。 我的主要决定因素是功能。 我构建工程应用程序，例如我有大约 6 个钢结构组件表。 它们都在一个模型中。 它们共享通用的工程属性，因此可以更轻松地重用专门用于操作这些属性的代码。
这意味着我可以实例化模型、创建对象、在公共代码文件中操作/组织这些对象。 任何需要传播回数据库的更改都可以非常有效地完成。
最重要的是确定您对底层对象的需求和使用频率。 如果您要不断更新一两个表，那么在该模型中包含 30 个其他不相关的表是没有意义的。 在这种频繁使用少量表的情况下，创建这些对象的集合、操作这些集合并在适当的时间更新数据库可能是有意义的。
执行内存操纵比执行磁盘 I/O 便宜得多。 这只是我对框架的看法，我绝不是这方面的专家。
I use an Entity Data Model for related tables. Depending on the size of your database I would only create one model if there was less than about 20 or 25 tables. It is a bit expensive to create individual models for every table because each model has a EntityConnection object to be created.
I find I can maintain the models fairly well if I have between 5 and 15 tables. My main deciding factor is functionality. I build engineering applications so for example I have about 6 tables of structural steel components. They are all in one model. They share common engineering attributes so it's easier to reuse code that is specific to manipulating those attributes.
This means that I can instantiate the model, create the objects, manipulate/organize those objects within a common code file. Any changes that need to be propogated back to the database can be done quite efficiently.
The bottom line is determinig your need and frequency of use for the underlying objects. If your going to be constantly updating one or two tables then it doesn't make sense to have 30 other non-related tables inside that model. In this scenario where a small number of tables are being used frequently, it might make sense to create collections of these objects, manipulate the collections and update the database at appropriate times.
Memory maipulation is much cheaper to perform then disk I/O. This is just my take on the framework and by no means am I an expert at it.
一个用于整个数据库或至少是您将使用的表...
如果您有大量表，您可以将它们分解为模式或其他某种分类方式，但我想说这个想法从来都不是数据模型每桌...
One for your entire database or at least the tables you will be using...
If you have a large amount of tables you could break them up into schemas or some other categorical way, but I would say that the idea has never been data model per table...
我将独立于数据库模式设计数据的概念/对象模型，然后创建将概念模型与数据库模式最佳关联的映射。 它可能使用大多数（如果不是全部）表。 如果您想要与表进行一对一映射，您可能需要考虑使用 LINQ-to-SQL，因为它更易于使用。
I would design a conceptual/object model of the data independently of the database schema and then create the mapping that best relates the conceptual model to the database schema. It may use most if not all of the tables. If you want a one-to-one mapping to tables, you may want to consider LINQ-to-SQL instead, since it's easier to work with.
除了上面的答案之外，请记住 EF 模型实际上处于概念级别。 它不需要与数据库的结构有任何关系，当然也不需要代表整个数据库。
In addition to the answers above, keep in mind that an EF model is actually at a conceptual level. It doesn't need to have anything to do with the structure of your database, and certainly doesn't need to represent the entire database.
我认为如果您有大型数据库，那么您需要对数据库表进行分类。 但是您必须为每个表创建一个类，这是 ado.net 实体框架的主要要求。
当您更新数据库时，您可以更新数据模型。
首先设计数据库，然后创建 ado.net 实体模型。
I think If you are having large database then you need to categorize the database tables. But you have to create a class for each table that's a primary requirement of the ado.net entity framework.
When you update database then you can do with update data model.
First design your database then create ado.net entity model.