问题标签 [self-tracking-entities]

我有一个 MVC2 应用程序，我开始使用STE的。我正在寻找有关更新应该如何工作的一些说明。

背景：

如果我有一个带有相关类别实体和相关帖子/评论实体的博客实体。在 MVC 中，我使用主博客实体和类别而不是相关帖子呈现视图。当我将博客实体回发到服务器时，我可以看到相关类别，但看不到被序列化回服务器的实体中的帖子（因为它们不在视图中）。此外，博客实体的更改状态为“已添加”。

然后我尝试调用Applychanges()并SaveChanges()在此博客实体上执行更新，但由于与帖子的 FK 关系以及数据库中有相关帖子但未附加到我发回的实体这一事实而失败。

通过一些进一步的测试......如果我在连接到服务器（状态=未更改）时获取博客实体的当前实例（以及所有相关的 FK 实体），则修改属性（状态=已修改）并更新它按预期工作.

所以我的问题是： 如果我的相关实体没有在视图中呈现，因此没有与 Blog 实体一起回发，更新应该工作吗？

为什么博客实体以“已添加”状态而不是“已修改”状态返回帖子？我会假设它会返回所有已更改实体的“已修改”changestate，然后当我调用ApplyChanges/SaveChanges()仅修改后的项目时会尝试更新，这就是我不需要所有相关实体的原因。

我应该能够直接从客户端传递实体，ApplyChanges()/SaveChanges()还是应该将实体发回服务器，从数据库中获取现有副本，对该副本应用更改，然后将现有对象发回？

我正在使用 EF4 自我跟踪实体（VS2010 Beta 2 CTP 2 加上新的 T4 生成器）。但是当我尝试更新实体信息时，它不会按预期更新到数据库。

我设置了 2 个服务调用。一个用于返回资源对象的 GetResource(int id)。第二个调用是 SaveResource(Resource res); 这是代码。

在我看来，ChangeTracker.State 总是显示为“未更改”。

这段代码有什么问题吗？

去年，我使用实体框架（当然是 .NET3.5）为我们的项目开发了一个数据访问服务，并使用 Julie Lerhman 的书作为开发状态跟踪 POCO 对象的指南。我们使用 WCF，也有 Silverlight 3 客户端。我们正在转向 .NET 4.0，我想改用代码生成来消除开发人员浪费的时间来编写 POCO 类和翻译类。

根据我所做的研究，似乎有 3 种状态跟踪 POCO 的方法：

1) 更改的跟踪代理：似乎对我们没有用，因为这似乎不适用于 WCF 序列化。

2）基于快照：在检索 POCO 实体图时拍摄快照，将客户端返回的图与该快照进行比较，并比较差异......对我来说似乎很好。

3）自我跟踪实体：代码生成器生成用于在 POCO 对象内进行自我跟踪的逻辑。这似乎与我们现在所做的很接近，只是它都是为我们生成的。

我正在尝试找出所有这些方法之间的优缺点。我猜测 1 和 2 是“连接的”，并且他们需要最初查询 POCO 的 ObjectContext 以保持实例化，但无法确认这一点。我也看不出为什么有人会真正为选项 1 烦恼，因为选项 3 似乎做同样的事情，而且更多......

快照对我来说似乎是最简单的，但如果这需要 ObjectContext 长时间保持打开状态，我不太确定......

我只是一名初级程序员，所以这里的任何建议，尤其是关于 Silverlight 3（我相信选项 2 和 3 与 Silverlight 3 一起使用，但 2 可能有问题）都非常感谢。

自我跟踪实体。惊人的。

除非你做类似的事情

没有一个自跟踪实体正在跟踪（直到它们可能被反序列化）。

美好的。因此，我们必须认识到返回给我们的实体可能没有启用跟踪。

怎么办？？？

我尝试过的事情

对于给定的方法体：

以下所有实现FigureItOut均失败：

也不

也不

也不

也没有什么我能想到的，除了

1. 从数据库中获取原始实体
2. 手动比较每个属性
3. 根据需要更新属性

确切地说，我应该对不跟踪自己的自我跟踪实体做什么？

小更新：

盲目地将实体标记为修改后的作品，但这似乎有点臭。在这种情况下我们能做到最好吗？

我正在使用实体框架为 PatientEntities 组合一个 WCF 数据服务。

我的解决方案需要满足这些要求：

• 实体 Patient 的属性 DateOfBirth 作为字符串存储在 SQL Server 中。如果实体类不使用“字符串”类型而是使用 DateTime 类型，那将是理想的。（我希望这是可能的，因为我们正在从存储层中抽象出来）。哪里可以设置转换机制来转换日期时间/字符串，以便实体和 SQL Server 同步？我无法更改存储层的结构，所以我必须解决它。
• 需要使用 WCF 数据服务（只读，因此无需保存更改），因为客户端将能够使用 LINQ 表达式来使用该服务。他们可以根据所需的任何给定查询场景生成结果，而不受 GetPatient(int ID) 等单一方法的限制。

我曾尝试使用 DTO，但遇到了将 ObjectContext 映射到 DTO 的问题，我认为这在理论上是不可能的……或者如果是的话，太复杂了。

我尝试使用自我跟踪实体，但如果我是正确的，它们需要来自 .edmx 文件的元数据，并且这不允许使用不同的属性数据类型。

我还想为我的 Entity getter 方法添加自定义，以便在返回之前执行类型为“string”的属性“MRN”。Replace("MR~", string.Empty)。我可以将它添加到 getter 方法，但问题是实体框架将在下次刷新实体类时覆盖它。有没有固定的地方可以放这些？

我应该改用 POCO 吗？这将如何与 WCF 数据服务一起使用？服务将在哪里获取元数据？

我正在使用 Entity Frameworks 4 和自我跟踪实体创建一个项目。我希望能够从 sql server 2008 数据库或 sql server compact 数据库中获取数据（开关位于配置文件中）。我正在使用存储库模式，我将把自我跟踪实体放在一个单独的程序集中。

我需要两个 edmx 文件吗？如果是这样，我如何在单独的程序集中只生成一组 STE？我还需要生成两个上下文类吗？我不确定这一切的管道。任何人都可以帮忙吗？

达伦

我忘了补充一点，这两个数据库是相同的，而精简版是供离线使用的。

我正在使用自我跟踪实体，并已将实体类移动到另一个程序集，方法是使用“添加为链接”指向此处提到的 TT 文件。但是现在，当我更新模型（例如更改属性名称）时，模板不会自动运行，因此实体类不会更新。

我当然可以手动运行模板来获取更新，但如果它以我移动类之前的方式自动运行会更容易。有什么办法可以做到这一点？

达伦。

在我看来，EF4 中的继承实体 (TPT) 正在发生一个奇怪的现象。

我有三个实体。1. 资产 2. 财产 3. 活动

属性是资产的派生类型。属性有许多活动（多对多）

在我的 EDMX 中对此进行建模时，一切似乎都很好，直到我尝试将新属性插入数据库。如果该属性不包含任何活动，它可以工作，但是当我向新属性添加一些新活动时，一切都会崩溃。

事实证明，经过 2 天的网络爬网和摆弄，我注意到在 EF 存储 (SSDL) 中，实体之间的一些约束在更新过程中没有被拾取。

链接属性和活动的 Property_Activity 表仅显示一个约束 FK_Property_Activity_Activity 但缺少 FK_Property_Activity_Property。

我知道这是一个实体框架异常，因为当我将数据库中的关系切换为：

资产 <--> Asset_Activity <--> 活动

更新后，所有外键约束都被拾取并且保存成功，无论新属性中是否有活动。

1. 这是有意的还是EF中的错误？

2. 我该如何解决这个问题？

3. 我应该完全放弃继承吗？

在我们的多层业务应用程序中，我们有ObservableCollections从服务调用返回的自我跟踪实体。

我们的想法是我们希望能够从集合客户端获取实体、添加、更新和删除它们，然后将这些更改发送到服务器端，在那里它们将被持久化到数据库中。

自我跟踪实体，顾名思义，自己跟踪他们的状态。创建新的 STE 时，它具有已添加状态，当您修改属性时，它会设置已修改状态，它也可以具有已删除状态，但是当从实体中删除时ObservableCollection（显然）不会设置此状态。如果您想要这种行为，您需要自己编写代码。

在我当前的实现中，当从 中删除实体时ObservableCollection，我将其保存在影子集合中，以便在将ObservableCollection发送回服务器时，我可以将删除的项目一起发送，以便 Entity Framework 知道删除它们。

类似于以下内容：

现在，如果用户决定将他的更改保存到服务器，我可以获取已删除项目的列表，并将它们一起发送：

此时，UpdateCustomers如果删除了任何项目，该方法将验证我的影子集合，并将它们发送到服务器端。

这种方法效果很好，直到您开始考虑这些影子集合的生命周期。基本上，当ObservableCollection垃圾回收时，我们无法知道我们需要从字典中删除影子集合。

我想出了一些复杂的解决方案，在这种情况下基本上可以进行手动内存管理。我每隔几秒钟检查一次引用是否处于非活动状态，在这种情况下，我会删除影子集合WeakReference。ObservableCollection

但这似乎是一个糟糕的解决方案......我希望 StackOverflow 的集体天才能够阐明更好的解决方案。

编辑：

最后我决定继承ObservableCollection. 生成了服务代理代码，因此将其更改为返回我的派生类型是一项相对简单的任务。

感谢所有的帮助！

我一直在将实体框架与自我跟踪实体代码生成模板结合使用，用于我最新的 silverlight to WCF 应用程序。这是我第一次在实际项目中使用实体框架，我希望能够在我的数据库模式发生变化时自动更新项目的整个数据访问层，从而为自己节省大量时间和精力。

令人高兴的是，我发现通过添加新表、更改列名、添加新列等来更新我的数据库模式可以通过使用实体上的数据库更新选项传播到我的业务对象类框架模型。

我受伤的地方是我的 WCF 服务中的 CRUD 操作，以响应我的 Silverlight 客户端上的操作。我在我的 Silverlight 应用程序中使用相同的自我跟踪实体框架业务对象，但我发现我不断地不得不解决诸如在更新对象时未正确处理外键关联或更改跟踪器对某个状态的状态感到困惑的问题Silverlight 端的对象和 WCF 层内的数据访问操作引发了不稳定。

与以前的项目相比，我现在花更多的时间来处理这些怪癖，在以前的项目中，我使用 Linq-to-SQL 作为滚动我自己的业务对象的起点。

只是我绝望，还是自我跟踪实体接近一些应该避免的东西，直到它更成熟？