实体框架4：为所有实体创建一个图表是否有意义？ [英] Entity Framework 4: Does it make sense to create a single diagram for all entities?
问题描述
我的假设：
- 数据上下文可以指多个实体。
- 如果您有两个数据源，说MS SQL服务器和Oracle，EF需要两个不同的图来访问数据。
- EF图数据上下文是工作单位，有一个Save（）图。 （确定你可以把它包装在一个UnitOfWork类中，但它基本上有相同的职责）。
假设是正确的，这里是我的问题：
-
如果您没有将所有实体保留在同一个EF图表上，那么您如何维护数据完整性像订单一样，如果没有客户，就不可能存在？这仅仅是为了验证完整性来加载数据的存储库的功能，还是我们对数据库引用完整性错误进行try / catch？ >
-
您不会为每个实体创建一个EF图表？例如，我不会期望更改客户，并更改为产品被写在一起，因为它们与彼此无关（将它们放在同一个图上会导致它们一起写入）。或者是EF图表的范围，以涵盖存储在同一存储介质中的所有类似实体？
是划分这样的实体的规范，还是只有一个持有所有实体的图表？我会认为后者，但思维越来越好。
拥有一个包含所有实体的大型EDM不是一个很好的做法，不推荐。
使用一个大型EDM将导致以下几个问题：
元数据的性能问题负载时间：
随着模式文件的大小增加，解析和创建内存模型所需的时间也将增加。
视图生成中的性能问题：
视图生成是一个编译由用户进入客户端实体Sql视图，将用于查询和存储实体到数据库。该进程首次运行时查询或SaveChanges发生。视图生成步骤的性能不仅取决于模型的大小，还取决于模型的互连。如果两个实体通过继承链或关联连接，则称它们是连接的。类似地，如果通过外键连接两个表，则它们被连接。随着您的架构中连接的实体和表的数量增加，视图生成成本增加。
混合设计器曲面：
从大数据库模式生成Edm模型时，设计师表面与许多实体混乱，很难理解您的实体模型总体看起来如何。如果您没有对实体模型的良好概述，您将如何自定义？
Intellisense体验不是很好：
当您从数据库中生成一个名为1000的Edm模型时表格，最终会有1000个不同的实体集。想象一下，在VS代码窗口中键入上下文时，您的智能感知体验将如何。
混乱的CLR命名空间：
由于模型模式将具有单个EDM命名空间，生成的代码将类放在单个命名空间中。
有关更详细的讨论，请查看 在实体框架中使用大型模型 - 第1部分
解决方案：
虽然没有开箱即用的解决方案这表示相反，您应该 自然断开您的模型中的子集 ，这意味着基于您的域模型，您应该提出不同的域模型集，每个域模型包含相关的对象，而每个集合是不相关的，并与另一个断开连接。两者之间没有外键可能是分离的好兆头。这是有道理的，因为在大型模型中，通常您的应用程序不需要将数据库中的所有表映射到一个实体模型才能工作。
即使这种分离不是100％可能 - 意味着有数据库中有其他表的外键子表，它仍然鼓励您做他们分开。当您这样做时，您必须承担相应设置外键的责任。没有导航属性可以让您获取表示此外键的实体。当然，如果需要，您可以在其他容器中手动查询此实体。
此外，有关如何在重用类型时将一个大型实体模型拆分为较小实体模型的一些提示和技巧，请查看： 在实体框架中使用大型模型 - 第2部分
关于您的问题：订单和客户属于相同的自然域，应该保持在相同的EDM中。就像我说的那样，你可以将它们分散在两个不同的实体数据模型上，但是你必须承担设置适当的外键的责任，否则你将得到运行时异常，同样的，客户和产品应保存在单独的实体数据模型中。遵循这些规则，您可以在数据访问层中提出一个明确定义的域集设计。
I wrote a few assumptions regarding Entity Framework, then a few questions (so please correct where I am wrong). I am trying to use POCOs with EF 4.
My assumptions:
- Only one data context can exist for an EF diagram.
- Data Contexts can refer to more than one entity.
- If you have two data sources, say MS SQL server and Oracle, EF requires two different diagrams to access the data.
- The EF diagram data context is the "Unit of Work", having a single Save() for anything on the diagram. (Sure you could wrap it in a UnitOfWork class, but it essentially has the same duties).
Assuming that's correct, here are my questions:
If you don't keep all entities on the same EF diagram, how do you maintain data integrity, like "Orders" cannot exist without a "Customer"? Is this solely a function of the repository to load data just to verify integrity, or do we "try/catch" on database referential integrity errors?
Wouldn't you create an EF diagram for each Entity? For example, I wouldn't expect changes to a customer and changes to a product to be written together as they have nothing to do with each other (having them on the same diagram would cause them to be written together). Or is the scope of an EF diagram to encompass all similar entities stored in the same storage medium?
Is it the norm to divide up the entities like that, or just have a single diagram holding all the entities? I would think the latter, but the thinking is getting the better of me.
Having one big EDM containing all the entities generally is NOT a good practice and is not recommended.
Using one large EDM will cause several issues such as:
Performance Issue in Metadata Load Times:
As the size of the schema files increase, the time it takes to parse and create an in-memory model for this metadata would also increase.
Performance Issue in View Generation:
View generation is a process that compiles the declarative mapping provided by the user into client side Entity Sql views that will be used to query and store Entities to the database. The process runs the first time either a query or SaveChanges happens. The performance of view generation step not only depends on the size of your model but also on how interconnected the model is. If two Entities are connected via an inheritance chain or an Association, they are said to be connected. Similarly if two tables are connected via a foreign key, they are connected. As the number of connected Entities and tables in your schemas increase, the view generation cost increases.
Cluttered Designer Surface:
When you generate an Edm model from a big database schema, the designer surface is cluttered with a lot of Entities and it would be hard to make sense of how your Entity model in total looks like. If you don’t have a good overview of the Entity Model, how are you going to customize it?
Intellisense experience is not great:
When you generate an Edm model from a database with say 1000 tables, you will end up with 1000 different entity sets. Imagine how your intellisense experience would be when you type "context." in the VS code window.
Cluttered CLR Namespaces:
Since a model schema will have a single EDM namespace, the generated code will place the classes in a single namespace.
For a more detailed discussion, have a look at Working With Large Models In Entity Framework – Part 1
Solution:
While there is no out of the box solution for this but it suggests that instead, you should Naturally Disconnected Subsets in your model meaning that based on your domain model, you should come up with different sets of domain models each containing related objects while each set is unrelated and disconnected from the other one. No Foreign Keys in between could be a good sign for separation. And this make sense because in a large model, usually your application does not require all the tables in a database to be mapped to one Entity Model in order to work.
Even if this kind of separation is not 100% possible - meaning that there are subsets of tables that have out going foreign keys to other tables in the database - it still encourages you do separate them. When you do this, you would have to take the responsibility of setting the foreign key appropriately. There would be no navigation property that allows you to get the Entity that represents this foreign key. Of course you could manually query for this Entity in the other container if needed.
Also, for some tips and tricks on how you can split one large entity model into smaller ones while reusing types, take a look at: Working With Large Models In Entity Framework – Part 2
About your question: Order and Customer belong to the same natural domain and should be kept in the same EDM. Like I said, you can scatter them over 2 different entity data models but then you have to take the responsibility of setting the appropriate foreign keys or you'll get runtime exceptions, by the same token, Customer and Product should be kept in separate entity data models. Following these rules, you can come up with a well defined domain set design in your data access layer.
这篇关于实体框架4：为所有实体创建一个图表是否有意义？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
