实体框架是提交模式吗？

Question

我有许多方法最终会调用我的 this._context.SubmitChanges 方法。由于我的所有方法都是异步操作的，因此在我的应用程序中（尽管不太可能），多个方法可能会在另一个提交更改完成之前尝试提交。

现在，我知道我可以使用 IsSubmitting 方法来确保我不会在另一个提交发生时尝试调用一个提交。我只是想知道从这里该往哪个方向走。我不确定是否真的有必要设置一个队列，因为希望提交更改的多个实体都将在 .SubmitChanges 调用下汇总。

我所做的每个提交更改都有一个回调函数。一种选择是在我的应用程序中添加一个标志，在回调中检查该标志是否在过渡期间设置。如果设置了标志，则会发射另一轮。虽然看起来很黑客。有更好的办法吗？

谢谢。

[编辑]

我没有我想要的那么多 EF fu，但我认为我将它们分开，如下面的代码（我的 VM 构造函数）中所述...当我想要提交更改时，它位于每个独立的实体列表上...

这是对submitchanges的调用示例（其中每个调用都使用不同的实体列表）

this._keywordSource.Add(new Keyword() { keyword = searchText });
if (this._context.Keywords.HasChanges && !this._context.IsSubmitting)
{
    this._context.SubmitChanges(KeywordsAddedCompleted, null);
}

这是我的视图模型构造函数中的代码：

this._gnipRuleSource = new EntityList<GnipRule>(this._context.GnipRules);
this._keywordSource = new EntityList<Keyword>(this._context.Keywords);
this._cachedSource = new EntityList<CachedKeywordResult>(this._context.CachedKeywordResults);
this._feedSourceSource = new EntityList<FeedSource>(this._context.FeedSources);

this._gnipRuleLoader = new DomainCollectionViewLoader<GnipRule>(LoadGnipRules, LoadGnipRulesCompleted);
this._keywordLoader = new DomainCollectionViewLoader<Keyword>(LoadKeywords, LoadKeywordsCompleted);
this._cachedLoader = new DomainCollectionViewLoader<CachedKeywordResult>(LoadCachedKeywords, LoadCachedKeywordsCompleted);
this._feedSourceLoader = new DomainCollectionViewLoader<FeedSource>(LoadFeedSources, LoadFeedSourcesCompleted);

this._gnipRuleView = new DomainCollectionView<GnipRule>(this._gnipRuleLoader, this._gnipRuleSource);
this._keywordView = new DomainCollectionView<Keyword>(this._keywordLoader, this._keywordSource);
this._cachedView = new DomainCollectionView<CachedKeywordResult>(this._cachedLoader, this._cachedSource);
this._feedSourceView = new DomainCollectionView<FeedSource>(this._feedSourceLoader, this._feedSourceSource);

Answer 1

我在同一个地方，我正在考虑实现一个队列，只是因为这样我就可以确保我的操作可靠且按顺序提交。我做了一些研究，但尚未找到处理这种情况的好模式。

不过，您的回调模式似乎确实是一个简单的解决方法。 Hacky 缺乏结构，但如果您确保所有提交都通过一段代码，那么它应该很容易实现和维护。实现排队模式几乎肯定会更快。

检查IsSubmitting并避免SubmitChanges，让未提交的更改滚入下一个被调用的提交（如您所描述的），效果很好。不幸的是，它最终会导致一些未提交的更改（用户会话中的最后一个更改未保留，因为 IsSubmitting 当时为 true）。当这种情况发生时，这将是“运气不好”，特别是因为多次提交不太可能很快发生，但对于无法复制该错误的用户和测试人员来说，这将是非常烦人的。

Answer 2

像这样的事情怎么样？

if (!_serviceContext.IsSubmitting)
{
    _serviceContext.SubmitChanges();
}
else
{
    PropertyChangedEventHandler propChangedDelegate = null;
    propChangedDelegate = delegate
        {
            if (!_serviceContext.IsSubmitting)
            {
                _serviceContext.SubmitChanges();
                _serviceContext.PropertyChanged -= propChangedDelegate;
            }
        };
    _serviceContext.PropertyChanged += propChangedDelegate;

}

首先，我检查服务是否正在提交更改，如果是，我会订阅 PropertyChanged 事件，以便在 IsSubmitting 更改值时收到通知。从我所看到的来看，它似乎可以解决问题。