我与一位高级开发人员合作，他是一名大师.NET架构师。在过去的6个多月里，我们已经提出了许多建设性的论点，一般来说，我在大多数讨论中都承认失败。我和他一起学习筹码。然而，我们目前有一个设计问题不同意，我想要一些意见/建议，因为他没有设法让我相信他的立场，我会坚持我的枪，直到有人能给我证据证明我我错了。
我们使用Entity Framework 4.0，我们在不同的模型中使用BOTH持久感知和自跟踪实体。我们开始使用自我跟踪实体来跟踪我们通过WCF线路序列化/反序列化到我们的Silverlight应用程序的实体图的更改。它非常有效。我们还开始将自我跟踪实体用于我们没有跨越WCF的模型，但许多仍然是持久意识到的实体/模型。
我的同事认为Entity Frameworks ObjectContext应该尽可能保持在最短的时间内。他坚持认为它只应该在查询所需的时间和持续时间所需的时间之间。任何与实体完成的业务工作都应该分离完成。对于我们拥有的每个实体模型，我们有一个查询类和一个持久类，它们都是IDisposable，并且在实例范围内具有ObjectContext，并且在方法中具有查询/持久性逻辑。我们在业务逻辑中使用这些查询/持久性类，而不是直接在业务逻辑中使用ObjectContext。构造这些类实例时，ObjectContext和Disposed也是如此，ObjectContext Disposed也是如此。这些类就像我们的LINQ操作的包装器，它将EF与业务逻辑分开并协助重用LINQ查询。
现在首先考虑非自我跟踪实体：
我理解为什么他想要这个以及没有长时间运行的ObjectContext的愿望，但我的问题是他总是希望将简单的业务逻辑与ObjectContext分离，以及我们有一个单独的查询和持久化上下文这一事实根据我们的设计意味着没有ObjectContext状态跟踪我们的业务逻辑中使用的实体。对于非自我跟踪实体，这意味着如果我们修改业务逻辑中的实体，我们还必须在持久化之前手动设置实体的修改状态。当使用多个更改持久化复杂图形时，这是一个真正的痛苦。此外，我怀疑我们可以手动完成，EF也会自动完成。
对于我们的自我跟踪实体，这种情况是相同的，因为跟踪仅在图形被反序列化时打开，因此当在执行查询的服务中使用WITHIN时，与上下文分离，仍然没有自我跟踪 - 跟踪实体。
我的问题是，实体框架使用的最佳实践是什么？如何设计实体框架DAL？ ObjectContext应该有多长时间？业务逻辑是否应始终与ObjectContext分离？如果是这样，我们如何在从ObjectContext分离工作时进行状态跟踪？我正在考虑的一个选项是将我们所有的实体转换为自跟踪实体，并使用一些图形遍历代码来遍历查询的图形并对图形中的所有实体进行跟踪，以便即使在工作服务端也可以打开自我跟踪（基本上模仿自跟踪实体图被反序列化时会发生什么）...
我不是建议我们长时间保持ObjectContext，但是在查询和持久性之间分离并且失去ObjectContext状态跟踪给我的好处似乎很愚蠢......我们正在失去一个巨大的好处EntityFramework ......
很抱歉很长的帖子......感谢任何帮助。
答案 0 :(得分：4)
Microsoft建议ObjectContext是短暂的，我的经验让我相信ObjectContext的生命周期理想地应该与web请求/用户操作的持续时间相关。
我错误地尝试在桌面应用程序中使用全局的，长期存在的ObjectContext，这是一场彻头彻尾的灾难。如果您要实现缓存，/重做编辑语义等等，那么您应该考虑使用与底层数据实体明显分离的ViewModel类的设计。使用EntityFramework帮助您构建Model对象图，然后从中构建ViewModel。如果要保存更改，请允许ViewModel存储库重新连接到基础实体，更改其属性并保存更改。这允许更“可缓存”，灵活，ORM独立，单元测试友好的设计。
在变更跟踪方面，尽量不要将其视为UI的廉价“用户自制变更”机制，而是将其视为一种昂贵的机制，用于跟踪最近创建的实体需要在何时进行考虑保存更改。