实体框架提交模式

本文关键字：模式 提交 框架 实体 | 更新日期: 2023-09-27 18:13:48

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

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

我对我所做的每个提交更改都有一个回调函数。一种选择是在我的应用程序中抛出一个标志，在回调中检查这个标志是否在过渡期间被设置。如果设置了旗子，它会发射另一发子弹。不过看起来有点寒酸。有没有更好的办法?

谢谢。[编辑]

我没有我想要的那么多EF，但我想我把它们分开，如下面的代码(我的VM构造函数)所述…当我想提交更改时，它是在这些独立的实体列表上…

下面是一个示例调用提交更改(其中每个调用使用不同的实体列表)

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);

实体框架提交模式

我在同一个地方，我正在考虑实现一个队列，只是因为我可以确保我的操作被可靠地和有序地提交。我做了一些研究，但还没有找到一个好的模式来处理这种情况。

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

检查IsSubmitting并避免SubmitChanges，以使未提交的更改滚动到下一个称为(如您所描述的)的提交中。不幸的是，它最终会导致一些未提交的更改(用户会话中的最后一个更改没有持久化，因为当时IsSubmitting为真)。当这种情况发生时，这将是"坏运气"，特别是当多次提交不太可能很快发生时，但对于无法复制漏洞的用户和测试人员来说，这将是非常恼人的。

这样怎么样?

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

首先检查服务是否正在提交更改，如果是，则订阅PropertyChanged事件以在issubmitted更改值时获得通知。

相关文章：