Linq to SQL：每个请求仅使用一个 DataContext 是否正确？
我们在这里使用 Linq to SQL。目前，我们的存储库倾向于新建自己的 DataContext 对象，因此如果您正在使用多个存储库，那么您正在使用多个 DataContext。
我正在做一些重构，以允许在我们的工作中进行依赖项注入。我假设我们需要“每个请求 1 个 DataContext”模式，因此我将相同的 DataContext（对于 Web 请求来说是唯一的）注入到所有存储库中。
但今天发生了一些事情。在我的重构之后，我们得到了一个ForeignKeyReferenceAlreadyHasValueException，因为设置了外键字段而不是设置了相应的关联属性。据我从 Google 得知，在 Linq to SQL 中直接设置外键是错误的（即我们的代码这样做是错误的），但直到我完成重构之后我们才收到错误。
所以我只是想检查一下 - 每个请求一个 DataContext 是否绝对是正确的方法？
We're using Linq to SQL here. At present, our repositories tend to new up their own DataContext objects, so if you're working with several repositories, you're working with several DataContexts.
I'm doing some refactoring to allow dependency injection in our work. I have assumed that we would want a '1 DataContext per request' pattern, so I'm injecting the same DataContext (unique to the web request) into all the repositories.
But then something happened today. Following my refactoring, we got a ForeignKeyReferenceAlreadyHasValueException because a foreign key field was set instead of the corresponding association property being set. So far as I can tell from Google, setting the foreign key directly is wrong in Linq to SQL (i.e. our code was wrong to do this), but we never got the error until after I had done the refactoring.
So I just wanted to check - is one DataContext per request definitely the right way to go?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
每个请求一个 DataContext 是一种方法，不是唯一的方法，但通常是一种很好的方法。
通过使用单个 DataContext，您可以将所有提交保存到请求末尾并立即提交所有更改。 SubmitChanges 自动封装事务中的所有更改。
如果您使用多个上下文，则需要将请求封装在事务中，以便在请求中途失败时可以回滚更改。使用多个上下文会产生更多的开销，但这通常并不重要。
我在不同的应用程序中使用过单个和多个数据上下文，并且两者都工作得很好，如果需要大量重写才能转到单个 DataContext，如果您没有任何其他强有力的重写理由，则可以保留多个上下文。
One DataContext per request is one way to go, not the only one, but usually a good one.
By using a single DataContext you can save all submits to the end of the request and submit all changes at once. SubmitChanges automatically encapsulates all changes in a transaction.
If you use multiple contexts you need to encapsulate your request in a transaction instead to make it possible to rollback changes if the request fails halfway through. You get a little more overhead using multiple contexts but that is usually not significant.
I have worked with both single and multiple datacontexts in different applications and both works good, if it requires to much rewrite to go to a single DataContext you can keep multiple contexts if you don't have any other strong reason for a rewrite.
如果您使用的是 transactionscope，那么您会发现多数据上下文方法将为每个新存储库创建一个新的数据库连接，该存储库在 transactionscope 中的事务处于挂起状态时更新了新的数据上下文。当事务范围包装了一个使用大量存储库对象执行工作的请求并耗尽了池中的连接时，我们就遇到了这种情况。
因此，如果您计划使用 trnasactionscope 来管理事务中的复杂业务流程，那么一定要使用共享数据上下文。
If you are using transactionscope, then you will find that the multiple datacontexts method will create a new DB connection for each new repository that has a new datacontext newed up while the transaction in the transactionscope is pending. We ran into this when a transaction scope wrapped a request that performed work with a lot repository objects and ran out of connections in the pool.
So if you plan on using trnasactionscope to manage complex business processes in a transaction, definitely go with the shared datacontext.