3

我与一位资深的 .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 的一大好处。 ..

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

4

1 回答 1

4

Microsoft 建议 ObjectContext 是短暂的，我的经验使我相信 ObjectContext 的生命周期应该理想地与网络请求/用户操作的持续时间相关。

我犯了一个错误，试图在桌面应用程序中使用全局的、长期存在的 ObjectContext，这完全是一场灾难。如果您要实现缓存、欠/重做编辑语义等内容，那么您应该考虑使用与底层数据实体明显分离的 ViewModel 类的设计。使用 EntityFramework 帮助您构建模型对象图，然后从中构建 ViewModel。当您想要保存更改时，允许您的 ViewModel 存储库重新连接到底层实体，更改它们的属性并保存更改。这允许更“可缓存”、更灵活、独立于 ORM、单元测试友好的设计。

In terms of change tracking, try not to think of it as a cheap "user-made-a-change" mechanism for the UI, but rather as an expensive mechanism for tracking which recently-created entities need to be considered when saving changes.

于 2010-09-29T08:54:03.557 回答