我的任务是拥有一个允许利用实体框架进行持久数据读取/写入的组件。请记住以下几点：
- 我不关心“写入/更新”的数据是否应该立即可供阅读（或者更改应该立即可供读者使用）；
- 出于性能考虑，我想在阅读时关闭实体跟踪；
- 数据读写会连续进行；
所以问题是：
拥有两个独立的上下文是个好主意吗？只要组件存在，它们就会存在。一种上下文用于写入/更新（定期调用 SaveChanges），另一种用于读取（实体跟踪）。
我是否会从这种方法中获益，或者相反会遇到问题？
提前致谢。
my task is to have a component that allows persistent data reads/writes utilizing Entity Framework. Keeping in mind the following:
- I do not care about 'written/updated' data should be immediately accessible for reading (or changes should be immediately available for reader);
- I would like to turn off entities tracking when reading for performance sake;
- Data reading and writing will run continuously;
So the question is:
is this a good idea to have two separate contexts, that will live as long as components lives. One context is for write/update (with periodically SaveChanges call), another one is for reading (with entities tracking off).
Will I potentially gain benefits or on the contrary have issues with this approach?
Thanks in advance.
发布评论
评论（2）
我认为这不是一个好主意，因为您将成为无法控制的数据模型的重复。
I don't think that's a good idea because you would be a duplication of your data model that would not be able to control.
建议的做法是使用较短的上下文，这样它们最终不会在内存中保存太多对象，从而避免冲突的更改和复杂的关系，
这可能会有所帮助
http://blogs.msdn.com/b/dsimmons/archive/2008/03/02/more-about-how-to-fit-the-objectcontext-into-apps.aspx
the recommended practice is to have shorter lived contexts, so they dont endup holding too many objects in memory and thus conflicting changes and complex relationships
this might help
http://blogs.msdn.com/b/dsimmons/archive/2008/03/02/more-about-how-to-fit-the-objectcontext-into-apps.aspx