EF Code First 对关系使用默认规则与配置.docVIP

【译著】Code First ：使用Entity. Framework编程(4) 第4章 对关系使用默认规则与配置 在第3章，你已经掌握了默认规则与配置对属性以及其在数据库映射的字段的影响。在本章，我们把焦点放在类之间的关系上面。这包括类在内存如何关联，还有数据库中的外键维持等。你将了解控制多重性关系，无论是否是必须的，还将学习级联删除操作。你会看到默认行为以及如何使用Data Annnotations和Fluent API来控制关系。 你会看到很多只能使用Fluent API而不能使用Data Annotations的情况。上一章我们介绍过映射到非Unicode数据库类型就只能在Fluent API中找到。在前几章你已经看到了几个有关默认关系的例子，如代码4-1，就是通过建立类型为ListLodging的Lodging属性与炻Destination建立了联系。 Example 4-1. The Destination class with a property that points to the Lodging class { public爄nt燚estinationId {爂et;爏et; }型就只 public爏tring燦ame {爂et;爏et; }爏et; public爏tring燙ountry {爂et;爏et; }; }型 public爏tring燚escription {爂et;爏et; }就只能 public燽yte[] Photo {爂et;爏et; }et; public燣istLodging Lodgings {爂et;爏et; }Flu } 在Lodging类（代码4-2）也有一个Destination属性代表单个Destination实例。 Example 4-2. The Lodging class with its reference back to the Destination class public?class?Lodging { public?int?LodgingId {?get;?set; } public?string?Name {?get;?set; } public?string?Owner {?get;?set; } public?bool?IsResort {?get;?set; } public?decimal?MilesFromNearestAirport {?get;?set; } public?Destination Destination {?get;?set; } } ? Code First观察到您既定义了一个引用又有一个集合导航属性，因此引用默认规则将其配置为一对多关系。基于此，Code First可以确定Lodging（外键）与Destination（主键）具有依赖关系。因此获表Lodging需要要一个外键映射到Destination的主键。在第2章你已经看到，在Lodgings表中确实建立了Destination_DestinationId外键字段。 本章将全面解析Code First在处理关系的默认规则以及如何按我们的意图覆写这些规则。 应用程序逻辑中的关系 一旦Code First已经创建了模型与关系，EF框架就会将这些关系视为与使用EDMX文件映射的POCO是类似的。所有你在使用POCO对象对EF框架编程的方法和规则仍然适用。例如，如何有一个外键属性和一个导航属性关系，EF框架就会保持他们的同步。如果存在双向关系，EF框架也同样会保持他们的同步。EF框架在什么点上同步值取决于您是否在利用动态代理。没有代理，EF框架将会隐式或显示调用DetectChanges。使用代理，同步的响应发生在属性值变更的时候。事实上你不需要关心是否调用DetectChanges因为DbConext将会在你调用任何依赖同步的方法自动调用。EF框架开发团队建议你如果需要只用动态代理；通常这都是围绕着性能调优进行的。没有代理的POCO类通常使交互关系理简化，因为你没必要知道代理相关的附加行为。 多重性关系 如前所述，Code First在看到导航属性和可选的外键属性时将创建关系。有关导航属性和外键属性的细节将帮助我们来确定多重关系的每一端。本章对外键将关注更多一点；现在我们来看看在类中没有外键属性定义的情况。 Code First在处理多重性关系时应用了一系列规则。规则使用导航属性确定多重性关系。即可以是一对导航属性互相指定（双向关系），也可以是单个导航属性（单向关系）。 ?如果你的类中包含一个引用和一个集合导航属性，Code First视为一对多关系； ??如果你的类中仅在单边包含导航属性（即要么是集合要么是引用，只有一种），Code First也将其视为一对多关系