实体框架 - 反向外键检查答案

【问题标题】：Entity Framework - Reverse Foreign Key Check实体框架 - 反向外键检查
【发布时间】：2011-05-12 16:04:12
【问题描述】：

我们有一个系统，允许管理员在系统内构建新的内容类型，包括与其他表的外键链接。然后管理员可以重建数据库，此时它会创建表和所有必要的关系，然后重建 EDMX 并重新编译所有内容。像冠军一样工作（不是我写的，否则我可能知道答案）。

我们的一个缺点是当用户删除一条可能被另一个表中的项目链接到的记录时。由于参照完整性，这会引发错误。当然，我正在捕捉这一点，但我现在所能提供的只是一个通用的“你不能删除这个项目，因为它与某些东西相关联”类型的错误。我宁愿检查该项目是否可删除，如果不是，则禁用该按钮。

有没有一种方法可以在运行时确定要删除的项目链接到哪个表/行？通常，我只是查询相关表，但由于这个应用程序的性质，我不知道其他表在设计时会是什么。

简而言之，如果我有：

Foo: FooID, FooName 栏：BarID、FooID、BarName Pow：PowID、FooID、PowName

是否可以在运行时判断 Foo 中的一行由于来自 Bar 或 Pow 的 FK 链接而无法删除，如果是，我可以判断哪个表导致错误？

提前致谢；第一次在这里发帖，所以请原谅任何礼仪错误:)。

【问题讨论】：

标签： entity-framework reflection foreign-keys entity foreign-key-relationship

【解决方案1】：

您必须查询元数据并获取所有导航属性的列表

ObjectSet = context.CreateObjectSet<YourEntityType>();

// Get entity set for current entity type
var entitySet = ObjectSet.EntitySet;
// Get name of the entity's navigation properties
_propertyNames = ((EntityType)entitySet.ElementType).NavigationProperties.Select(p => p.Name).ToArray();

现在您拥有在删除之前必须检查的属性。要检查属性，您必须加载这些成员，并且必须检查相关实体是否存在。两者都可能需要大量反射，这会影响应用程序的性能。

我不得不说你的应用程序架构很糟糕。就像一个例子：哪里不应该使用EF，或者不应该如何使用EF。

【讨论】：

我粗略的描述和编造的表格中有什么特别让你这么说的（“可怕”部分）？
是的，我在这里和那里看到了 Ladislav 的答案，它们通常质量很高，但我也对这个“可怕的架构”部分感到惊讶。 @Ladislav：您能否对此进行一些扩展，因为您的意思并不明显？
@zespri, @Chris：如果您使用 EF，则定义模型、定义数据库并编写使用模型的代码、测试应用程序并部署它。对模型的任何更改都取决于开发人员，他们必须确保应用程序仍然可以工作，并且不会因更改而破坏任何用例。显然，问题中描述的方法，其中管理员可以触发一些修改模型、重新生成类、重建程序集和重新部署应用程序的自动很棒的功能，这很难违反这一点。我什至不明白你为什么这样做，你怎么能使用未知功能？
@Ladislav：我跟着你。事实上，它比我描述的要多得多，但我尽量不做一个大的帖子。该应用程序是一个 CMS，并且正在创建的表主要使用基于基本内容类型的逐表继承模型。系统对所有 CRUD 操作使用动态数据，并且管理工具（在我们的例子中，管理员几乎是开发团队）在其中具有保护措施，以防止更改核心/必填字段等。
@Chris：好的，动态数据——现在更有意义了。