Linq to SQL：每个请求只使用一个DataContext是否正确？

Question

我们在这里使用Linq to SQL。目前，我们的存储库倾向于新建自己的DataContext对象，因此如果您正在使用多个存储库，那么您将使用多个DataContexts。

我正在做一些重构，以便在我们的工作中允许依赖注入。我假设我们想要一个'每个请求1个DataContext'模式，所以我将相同的DataContext（对Web请求唯一）注入所有存储库。

但是今天发生了一些事情。在我的重构之后，我们得到了一个ForeignKeyReferenceAlreadyHasValueException，因为设置了外键字段而不是设置了相应的关联属性。据我所知，从Linq到SQL直接设置外键是错误的（即我们的代码执行此操作是错误的），但是在我完成重构之前我们从未得到错误。

所以我只是想检查 - 每个请求一个DataContext肯定是正确的方法吗？

Answer 1

每个请求一个DataContext是一种方法，而不是唯一的方法，但通常是一个很好的方法。

通过使用单个DataContext，您可以将所有提交保存到请求的末尾，并立即提交所有更改。 SubmitChanges会自动封装事务中的所有更改。

如果您使用多个上下文，则需要在事务中封装您的请求，以便在请求中途失败时回滚更改。使用多个上下文会增加一些开销，但这通常不重要。

我在不同的应用程序中使用过单个和多个datacontexts并且两者都很好用，如果它需要大量重写以转到单个DataContext，如果你没有任何其他强大的重写理由，你可以保留多个上下文

Answer 2

如果您正在使用transactionscope，那么您会发现多个datacontexts方法将为每个新的存储库创建一个新的数据库连接，该存储库在transactioncope中的事务处于挂起状态时会新建一个新的datacontext。当事务范围包装了一个请求，该请求执行了大量存储库对象并且池中的连接用完时，我们遇到了这种情况。 因此，如果您计划使用trnasactionscope来管理事务中的复杂业务流程，那么请务必使用共享的datacontext。