将整个数据库加载到数据模型？
我决定使用实体框架作为数据层。
我有超过 200 张桌子，有两个问题：
1. 创建数据模型 (*.edmx) 时 - 我应该包含所有表（整个数据库）吗？
2. 稍后我可以将表添加到数据模型中吗？
I've decided to use the entity framework as data layer.
I have more then 200 tables, and two questions:
1. When creating the data model (*.edmx) - should I include all tables (entire db)?
2. Later, will I be able add tables to the data model?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，您希望表示数据模型中的所有表，否则您无法将它们作为实体进行访问。对于像您这样的大型数据库模式，一种策略是将其分成单独的部分（单独的 .emdx 文件），这些部分共同构成数据模型 - 拥有单个 .edmx 模型可能会在某些时候减慢 VS 的速度 - 但我个人还没有经历过这种情况，因此您必须自己尝试一下 - 从现有数据库创建初始模型很容易且不费力。
您可以随时将表添加到数据模型中，集成向导允许您只需将其指向现有数据库即可选择要添加的表。
Typically you want to represent all tables in your data model, otherwise you cannot access them as entities. One strategy for larger database schemas such as yours is to split it into separate parts (separate .emdx files) that together constitute the data model - having a single .edmx model can slow down VS at some point - I personally have not experienced this though, so you will have to try it out yourself - creating the initial model from an existing database is done easily and without effort.
You will be able to add tables at any point to the data model, the integrated wizard allows you to pick and choose which tables you want to add just by pointing it to an existing database.
我同意@BrokenGlass 的观点。 VS 2010 SP1 应该有 改进了设计器的性能，对于较大的模型效果更好，但单个模型中的 200 个表仍然太多了。
ADO.NET 团队发表了两篇有关使用大型模型的文章：第 1 部分 和 第 2 部分。一般来说，这些文章不仅涉及将映射拆分为多个 EDMX，还涉及在多个 EDMX 中共享一些公共实体，这非常有帮助。如果没有这种共享，您就无法在另一个 EDMX 中引用一个 EDMX 中的实体。此外，每个 EDMX 都有自己的
ObjectContext。将映射拆分为多个 EDMX 应基于某些架构决策：例如按组件拆分或按聚合根拆分。无论如何，使用多个 EDMX 会增加应用程序的复杂性，并且您仍然必须了解 EF 功能无法跨多个 EDMX 使用 - 因此，例如您无法在映射到不同 EDMX 的实体之上创建 linq-to-entities 查询。我回答了一个问题，其中描述了一些如何使用多个 EDMX 文件< /a> 在单个
ObjectContext中，但我建议在必须之前不要使用该解决方案 - 该解决方案的唯一有意义的用法是为从数据库更新的实体单独使用 EDMX，以及为手动定义的 SSDL 单独使用 EDMX（例如自定义定义查询）。原因是从数据库更新功能将删除您的更改，因此将它们单独保存在从不更新的 EDMX 中会很有帮助。I agree with @BrokenGlass. VS 2010 SP1 should have improved performance of the designer which works much better with larger models but still 200 tables in single model is too many.
ADO.NET team published two articles about working with large models: Part 1 and Part 2. Generally these articles are not only about splitting your mapping into multiple EDMXs but also about sharing some common entities in multiple EDMXs which can be really helpful. Without this sharing you can't an reference entity from one EDMX in another EDMX. Also each EDMX will have its own
ObjectContext. Spliting a mapping into multiple EDMX should be based on some architecture decission: for example split by a component or split by an aggregate root. Anyway using multiple EDMX will increase the complexity of the application and you must still understand that EF features don't work accross multiple EDMXs - so for example you can't create a linq-to-entities query on top of entities mapped in different EDMXs.I answered a question where I describe some hack how to use multiple EDMX files in the single
ObjectContextbut I recommend not using that solution until you must - the only meaningful usage of that solution is separate EDMX for entities updated from database and separate EDMX for SSDL defined manually (for exemple custom DefiningQuery). The reason is that Update from database function will delete your changes so it is helpful to keep them separately in EDMX which is never updated.