EF4：ObjectContext 生命周期？
我正在开发一个使用 Entity Framework 4 和 SQL Compact 4 的 WPF 桌面应用程序。我看到了两种不同风格的 Repository 类：
Repository实例化一个>ObjectContext，当Repository被垃圾收集时被释放。ObjectContext的生命周期与应用程序的生命周期相同。一个单独的
DataStoreManager类在应用程序的生命周期中创建并保存一个ObjectContext。当需要存储库时，命令会从DataStoreManager获取ObjectContext引用，并将其传递给新存储库的构造函数。ObjectContext的生命周期就是应用程序的生命周期。
这两种方法都被认为是不好的做法吗？两者相比是否具有绝对优势？这两种方法是否被视为最佳实践？开发人员是否比另一个更广泛地接受或使用？感谢您的帮助。
I am developing a WPF desktop app that uses Entity Framework 4 and SQL Compact 4. I have seen two distinct styles of Repository classes:
The
Repositoryinstantiates anObjectContext, which is disposed of when theRepositoryis garbage-collected. The lifetime of theObjectContextis the same as the lifetime of the application.A separate
DataStoreManagerclass creates and holds anObjectContextfor the life of the application. When a repository is needed, a command gets anObjectContextreference from theDataStoreManagerand passes it to the constructor for the New Repository. The lifetime of theObjectContextis the lifetime of the application.
Is either approach considered a bad practice? Does either present any absolute advantages over the other? Is either approach considered best practice? Is either more widely accepted or used by developers than the other? Thanks for your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我本以为在多次访问中保持 ObjectContext 打开是一种不好的做法。一旦损坏，您就需要回收并处理损坏。
存储库模式更多地用于数据访问的抽象，但不一定映射到上下文的生命周期。
工作单元模式更多的是关于一个或多个数据库/存储库访问的封装，即用例可能需要您添加一个新博客，然后添加第一个默认帖子，这可能需要调用两个存储库，此时您可能想要共享上下文并将这两个命令封装在一个事务中。添加第二个帖子可能会在几个小时后完成，并且是一个新的上下文/工作单元。
DJ 正确地提到了通常在应用程序级别设置的上下文生命周期。
I would have thought that holding an ObjectContext open over multiple accesses would be bad practice. As soon as it becomes corrupted then you would need to recycle in and handle the corruption.
The Repository pattern is more for abstraction of data access but doesn't necessarily map to lifetime of context.
The unit of work pattern is more about encapsulation of one or more database/repository accesses i.e. a use case may have you adding a new Blog and then adding the first default post, this may require calling two repositories, at this point you might want to share the context and encapsulate these two commands in a transaction. Adding a second post might be done hours later and be a new context/unit of work.
DJ is right in mentioning Context lifetimes which you'd set generally at an application level.
最佳实践取决于您的用户将如何使用该应用程序：
以及您的应用程序的结构。
如果一次只有一个用户使用您的应用程序，您甚至可以将实体上下文创建为静态实例。
上下文可以按请求、每个线程、每个表单使用。
阅读更多： http:// /blogs.microsoft.co.il/blogs/gilf/archive/2010/02/07/entity-framework-context-lifetime-best-practices.aspx
The best practice is depended on how your users are going to use the application:
And how your application is structured.
if there is only one user using your application at one time, you can even create your entity context as a static instance.
context can be used per request, per thread, per form.
read more: http://blogs.microsoft.co.il/blogs/gilf/archive/2010/02/07/entity-framework-context-lifetime-best-practices.aspx