问题标签 [self-tracking-entities]

我正在使用自我跟踪实体，并且有一个场景，我有一个实体，它代表一个我们将称为表 A 的表。A 是另一个表 B 的父级，该表也表示为一个实体。在我的 WinForm 上，我有 3 个不同的绑定源，每个绑定源代表表 B 中不同类型的记录，但都是表 A 的子项。所以我想要完成的是使用实体/表 B 的导航属性来设置每个绑定源

例如

理想情况下，每个绑定源的 DataSource 将是 TrackableCollection 类型，因此当我保存 A 时，对 B 的 3 个过滤实例的所有更改也会被保存。

我为此尝试了一些不同的选择，但没有任何运气，所以我希望其他人也遇到过同样的情况。

谢谢！

我在更新实体框架实体中的外键时遇到问题。我正在使用自我跟踪实体，并且有一个具有某些关系的实体，其中外键也作为属性存在（EF4 的新功能之一）。键（一个整数）被标记为 Nullable 和 Concurrency Mode fixed。

具体来说，我有一个与确认用户具有多对 0..1 关系的警报实体。（一个用户可以确认多个告警，但一个告警只能被零个或一个用户确认）。

实体定义（简化）：

在我的自我跟踪实体中，确认用户 id 会自动生成为 Nullable，就像预期的那样，但是如果我将用户分配给已经持续存在的警报并运行 ApplyChanges，则自我跟踪上下文扩展会尝试将原始值（null）设置为EF 上下文（在上下文扩展中的 SetValue 中），但会默默地跳过它，因为 EdmType 的 ClrEquivalentType 是不可为空的 Int32。

自动生成的扩展代码：

当 EF 稍后尝试更新我的警报时，我得到一个 OptimisticConcurrencyException，因为它在 UPDATE 语句中构造了一个 WHERE 子句，它使用 0（零）作为原始用户外键值，而不是正确的“is null”。（WHERE 子句是 EF 乐观并发机制的一部分，其中标记为“固定”并发模式的属性的原始值会与数据库中的属性进行检查）。

EF 的自跟踪实体是否不完全支持可为空的外键/原始类型？如果不是，我是否被迫使用虚拟实体而不是 null 或者是否有其他解决方法？

更新 我试图在没有 STE 的情况下重现该问题，但普通 EF 似乎可以很好地处理可空外键的乐观并发，所以这是一个 STE 问题，而不是 EF 问题。自我跟踪实体存在许多问题，因此这里出现故障也就不足为奇了。如果我找到可以在 STE T4 脚本中实现的解决方法，我将在此处发布。

在使用自我跟踪实体和实体框架 4 时，我正在尝试建立使用辅助键的良好做法，但似乎有很多陷阱。

假设我有一个警报实体，它可以具有用户的 ConfirmingUser 导航属性。用户有一个 Id 作为主键，一个“登录”作为辅助键。在我的系统中的某个时刻，我将一个新的用户实体分配给警报的 ConfirmingUser。那时我只知道用户的登录名（辅助密钥），可以说它是一个 n 层架构，此时查找 Id 是不切实际的。警报随后被传输到将尝试存储警报的持久层。现在是棘手的部分。我需要确定 ConfirmingUser 是否已存在于数据库中并采取适当的措施。

这就是我现在的做法：

这种模式对我来说看起来相当丑陋和低效。有没有更好的方法来处理带有“外部”键的实体？

上述代码的一个有趣缺陷是无法用具有相同登录名的新用户替换 ConfirmingUser。即，当客户端应用程序想要将 ConfirmingUser 分配给警报时，它必须检查 ConfirmingUser 是否已经分配给具有相同登录属性的用户。原因是自跟踪实体的 ApplyChanges 将尝试将原始用户和新用户都复制到 EF 上下文中，但 EF 不允许原始值和新值是同一个实体（为什么它无法处理这对我来说没有明确的意义）。

我正在使用带有自我跟踪实体 T4 模板的实体框架，默认情况下，它将生成一个 SQL 查询，在 UPDATE 语句中设置实体上的所有属性。我只想要一个包含已修改属性的 UPDATE 语句。

我按照书中的说明修改了 T4 模板：Entity Framework Recipes: A Problem-Solution Approach page 503。

我在 T4 模板中更改为这一行：

使实体跟踪每个属性更改，而不仅仅是跟踪实体更改。

并且

进行这些更改后，我得到了 SQL 语句的所需结果，其中仅在 UPDATE 语句中修改了值/属性。然而，有一个奇怪的副作用。将可为 null 的 INT 属性从 null 更新为 null 以外的内容时，实体框架会忽略该更改。Self-Tracking Models 显示 ChangeTracker 中的更改，具有准确的 OriginalValue null，但是当实体框架尝试生成 UPDATE SQL 时，如果原始值为 null 且新值不为 null，则它没有看到该属性更改。如果原始值不为空并且值被更改，我会工作。

在从 null 到非 null 值的字符串属性上似乎可以正常工作，但是 int? 不管用。

有没有人有任何想法？

我们正在启动一个新的基于 Web 的产品，我们计划在其中通过 WCF 服务公开我们的业务逻辑。我们将使用 ASP.NET 4.0、C#、EF 4.0。将来我们希望基于这些服务构建 iphone 应用程序和 WPF 应用程序。我已经阅读了很多关于使用 POCO 与自我跟踪实体 (STE) 的内容，据我了解，STE 不适用于 Web 场景。任何人都可以更清楚地了解这个问题吗？

我与一位资深的 .NET 架构师一起工作。在过去的 6 个多月里，我们进行了许多建设性的争论，总的来说，我在大多数讨论中都承认失败。我从和他一起工作中学到了堆栈。然而，我们目前在一个设计问题上存在分歧，我想要一些意见/建议，因为他没有设法让我相信他的立场，我会坚持我的立场，直到有人能给我证据证明我我错了。

我们使用 Entity Framework 4.0，并在不同的模型中同时使用持久性感知和自我跟踪实体。我们开始使用自跟踪实体来跟踪我们通过 WCF 线路序列化/反序列化到 Silverlight 应用程序的实体图的更改。它非常有效。我们还开始将自跟踪实体用于我们未跨 WCF 采用的模型，但许多仍然作为持久感知实体/模型。

我的同事认为 Entity Frameworks ObjectContext 应该保留尽可能短的时间。他坚持认为它应该只存在于执行查询所需的时间长度和持久化某些东西所需的时间长度。与实体完成的任何业务工作都应该独立完成。对于我们拥有的每个实体模型，我们都有一个查询类和一个持久类，它们都是 IDisposable 并且在实例范围内具有 ObjectContext 并且在方法中具有查询/持久性逻辑。我们在业务逻辑中使用这些查询/持久性类，而不是直接在业务逻辑中使用 ObjectContext。当这些类实例被构造时，ObjectContext 也是如此，而当 Disposed 时，ObjectContext 也是 Disposed。

现在首先考虑非自追踪实体：

我理解他为什么想要这个以及不希望有一个长时间运行的 ObjectContext，但我的问题是他总是希望将微不足道的业务逻辑从 ObjectContext 中分离出来，而且我们在设计下有一个单独的查询和持久性上下文意味着在我们的业务逻辑中没有对正在使用的实体进行 ObjectContext 状态跟踪。对于非自跟踪实体，这意味着如果我们在业务逻辑中修改实体，我们还必须在持久化之前手动设置实体的已修改状态。在持久化具有多个更改的复杂图形时，这是一个真正的痛苦。我也怀疑我们是否可以手动完成，而 EF 会自动完成。

对于我们的自跟踪实体，这种情况是相同的，因为仅在反序列化图形时才打开跟踪，因此当在执行查询的服务中工作时，与上下文分离，自跟踪实体仍然没有跟踪.

我的问题是，使用实体框架的最佳实践是什么以及应该如何设计实体框架 DAL？ObjectContext 应该存在多长时间？业务逻辑是否应该始终与 ObjectContext 分离？如果是这样，我们如何在与 ObjectContext 分离时进行状态跟踪？我正在考虑的一个选项是将我们所有的实体转换为自我跟踪实体，并使用一些图形遍历代码来遍历查询的图形并为图形中的所有实体打开跟踪，这样即使在服务端工作时自我跟踪也会打开（基本上模仿反序列化自跟踪实体图时发生的情况）......

我并不是建议我们长时间保留 ObjectContext，但是在查询和持久性之间分离工作并且失去 ObjectContext 状态跟踪的好处对我来说似乎很愚蠢......我们正在失去 EntityFramework 的一大好处。 ..

对不起，长篇文章......任何帮助表示赞赏。

我有一个 WPF 应用程序使用 Entity Framework 4 和 Self-Tracking Entities 使用数据。在其中我有一个带有 2 个控件的窗口，其中一个使用 ContentControl 和来自合并资源字典的模板显示对象的“详细信息”部分。另一个具有相关对象所属的组列表框和它可能属于的可用组的组合框带有通过命令连接到控件的按钮，以根据组合框的 SelectedItem 从绑定的组集合中添加/删除项目. 所有这些都由 DependencyPropertys 绑定在一起。

在我的窗口中，我有对象的 DP，我们正在编辑的 EditedItem 和一个只读属性，其中包含它可能属于的组的组列表，并通过 XAML 将其绑定到我的控件。

所以....

如果我为我的一个实体创建一个新实例，请设置它的属性，如下所示：（真的这是确切的代码）

并将其设置为我的 Window 的 EditedItem 它可以正常工作！

但是，如果我从数据库中获取完全相同的实体，则 Groups ListBox 为空。有任何想法吗？

我正在使用带有 EF4 的 STE 开发 Silverlight 4 应用程序。我创建了一个 Silverlight 项目，其中包含使用我的 STE T4 模板生成的所有实体类，并在 VS 上正确构建。但是，当我使用 Visual Studio 添加 WCF 代理并检查“在引用程序集中重用类型”（具有对我的 Client.Model 程序集的所有 STE 的引用）时，Visual Studio 代理生成器添加了一些在我的 STE 模型上定义的类，如 ObjectList（列表）、ObjectsAddedToCollectionProperties（字典）、ObjectsRemovedFromCollectionProperties（字典）和 OriginalValuesDictionary（字典）。

因此，当我使用 Visual Studio 并尝试使用这些类时，两个项目中有两个具有相同名称的类，一个来自我的 STE 模型，另一个来自 Visual Studio 代理生成命名空间。

我错过了什么吗？我的项目运行良好，我可以申请 STE。

谢谢。

路易斯·格雷罗。

我在 WCF 客户端-服务器应用程序中使用自跟踪实体。我的 WCF 服务返回各种实体，这些实体可以使用相应的 Update 方法进行更新。

这工作了一段时间，但现在我遇到了问题。为了保持重点，我将把这个讨论限制在一个特定的案例中，简化为最基本的内容。

我的一张表称为 SystemDefinition。它没有外键，但另一个表（Route）有一个外键。因此，它在实体模型中有一个导航属性（称为 Routes）。所有其他列都是标量。该表和相应的实体有一个名为 Id 的主键列，类型为 Guid。该数据库是 SQL Server Compact v3.5。

要重现该问题，我可以：

1. 使用我的 WCF 服务的 GetSystem() 方法检索单个 SystemDefinition 实体
2. 在客户端中，在实体上调用 MarkAsDeleted()
3. 调用 UpdateSystem()，将实体作为参数传递

UpdateSystem() 中的代码很简单（为了清楚起见，删除了非必要代码）：

该实体是在没有 Include() 子句的情况下检索的，这意味着 Routes 集合为空（无论如何，如果 Route 中没有具有 SystemDefinition 外键的行，则仍然会发生错误）。所以我传递给 Update 方法的 SystemDefinition 实体是图中唯一的实体。但是我仍然遇到以下异常：

InvalidOperationException：AcceptChanges 无法继续，因为对象的键值与 ObjectStateManager 中的另一个对象冲突。在调用 AcceptChanges 之前确保键值是唯一的。

异常由第一个方法调用 (ApplyChanges) 引发。我确定 ObjectContext 是新鲜的，为每个方法调用创建一个新的。

我已经将代码一直调试到它抛出的位置（在 ObjectContext.FixupKey() 中），但代码对我来说意义不大，并且微软的源代码中没有注释来说明导致它的条件实际上意味着什么.

当然，该消息具有误导性？更新中只涉及一个实体。可能会发生什么？

PS。我发现一个论坛帖子建议覆盖实体类上的 GetHashCode() 和 Equals() 方法可能会有所帮助。如果错误是由于 ObjectStateManager 无法确定要更新的实体实际上与上下文中的某个实体相同，那么这将是有道理的。我试过了（使用部分类），但不幸的是它没有帮助。所以现在我迷路了。欢迎大家提出意见。

如何将 JSON 字符串反序列化为这种类型的实体（为了简单起见，删除了自跟踪属性）：

角色也是具有两个属性的简单类。TrackableCollection 是 Collection (System.Collections.ObjectModel) 的后代。

所以我想要：拥有这样的 JSON 字符串

{"Id":0, "Name":"Test User", "Roles": [{"Id":1, "Name": "Role 1"}, {"Id":2, "Name": "Role 2"}, {"Id":3, "Name": "Role 3"}]}

获取具有正确反序列化角色集合的实体。