在我的项目中，我首先使用EF Core流畅的配置。我读了一些有关所有类型的文章，但是下面的情况对我来说并不十分清楚：
假设我有一个Project实体和一个实体ProjectType。
我应该将该属性映射为：
Entity<Project>.HasOne<ProjectType>(); 或者更确切地说
Entity<Project>.OwnsOne<ProjectType>();
该ProjectType实体应映射到表ProjectType(ProjectTypeId, Name, Description)
据我了解，拥有是
“只能出现在其他实体类型的导航属性上的类型。这些类型称为拥有实体类型。包含拥有实体类型的实体就是其所有者。拥有实体本质上是所有者的一部分，没有它就不能存在”
就我而言
“ProjectType只能出现在Project实体类型的导航属性上。ProjectType本质上是的一部分，Project没有它就不能存在” ...但是，按照我的理解，要创建一个单独的表，我需要使用HasOne，而不是OwnsOne...如果有人能更好地解释这个想法，那就太好了。非常感谢。
ProjectType听起来像一个参考表，否则可以在应用程序的整个生命周期中（例如通过系统管理角色）对其进行修改。使用新的“ Owns”是一种约定，可以帮助强制执行诸如特定于类型的组合以及在关系数据模型中链接表之类的概念。
一个更好的组合示例：假设您有一个项目，并且作为项目的一部分，有一些相当大且不经常使用的细节。诸如图像或其他二进制数据，或一些大文本之类的东西。当您获取一个或多个项目时，将这些BLOB / CLOB详细信息包含在Project表中可能会成为灾难的根源，因此您可以将它们标准化为一个单独的相关表，称为ProjectDetails，或者可能是几个相关表。这样，大多数情况下，当您使用Project并加载那些您不必担心会一直拉回这些大字段的实体，您可以引用ProjectDetails以仅在实际需要时才包含它。由于ProjectDetails本身并不能真正起到任何作用，因此它不需要DbSet或类似的东西，因此我们可以设置从Project到OwnsOneProjectDetails的关系。
另一方面，ProjectType在配置应用程序的过程中可能会具有DbSet来建立新的项目类型。您可能还希望根据“项目类型”关联其他与项目相关的详细信息。在这种情况下，将Project改为HasOneProjectType更有意义。我们可以拥有一个DbSet of ProjectTypes来管理，其他实体也可以按ProjectTYpe，Project Stages / Phases等进行过滤。
就数据库模式在Owns和之间而言Has，没有区别。这仅与EF DbContext将如何与实体一起使用有关。
使用的其他常见示例Owns是链接表。例如，您有一个地址表，在订单，客户等之间共享。都不是“拥有者”地址，但他们确实拥有自己的链接表：订单拥有者OrderAddress，客户拥有CustomerAddress。这些实体“具有”地址。我们可能仍要检查地址，因为它们代表实际位置，并且将订单等关联到其他位置与“调整”为实际位置记录的详细信息之间存在区别。（即，更正街道名称或城市名称）无需分别处理Order或Customer范围之外的OrderAddresses或CustomerAddresses。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句