Entity Framework IsSubmitting шаблон?

Question

У меня есть несколько методов, которые в конечном итоге вызывают мой this._context.SubmitChanges метод.Поскольку все мои методы работают асинхронно, в моем приложении возможно (маловероятно, что albiet), что несколько методов могут попытаться отправить их, прежде чем завершится другая передача.

Теперь я знаю, что могу использовать метод IsSubmitting, чтобыне пытайтесь позвонить одному представителю, когда происходит другое.Мне просто интересно, в каком направлении идти отсюда.Я не уверен, что это действительно необходимо для настройки очереди, поскольку несколько объектов, которые хотят отправить изменения, будут свернуты при вызове .SubmitChanges.

У меня есть функция обратного вызова на каждой отправке, которую я делаю.Одним из вариантов было бы добавить флаг в мое приложение, которое при обратном вызове проверяет, был ли установлен флаг во время промежуточного периода.Если флаг был установлен, он выстреливает еще один раунд.Кажется, хакерский хотя.Есть ли способ лучше?

Спасибо.

[Редактировать]

У меня не так много EF-фу, как хотелось бы, но я думаю, что держу их отдельно, как обрисовано в общих чертахв приведенном ниже коде (мой конструктор VM) ... когда я пытаюсь отправить изменения, это происходит в каждом из этих независимых entityLists ...

Здесь приведен пример вызова submitchanges (где каждый вызов используетдругой список сущностей)

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

Вот код из моего конструктора viewmodel:

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

Я нахожусь в том же месте, и я рассматриваю возможность создания очереди просто потому, что тогда я могу быть уверен, что мои операции выполняются надежно и в порядке.Я провел небольшое исследование и до сих пор не нашел хорошего шаблона для решения этой ситуации.

Однако ваш шаблон обратного вызова кажется простым обходным путем.Хаки в том, что у нее нет структуры, но если вы убедитесь, что все отправленные сообщения проходят через один фрагмент кода, то это должно быть достаточно легко реализовать и поддерживать.Почти наверняка было бы быстрее реализовать этот шаблон очередей.

Проверка IsSubmitting и избегание SubmitChanges, чтобы позволить незафиксированному изменению перейти в следующую отправку, которая называется (как вы описываете), работает нормально,К сожалению, это в конечном итоге приведет к некоторым незафиксированным изменениям (последнее изменение в сеансе пользователя не было сохранено, потому что IsSubmitting было верно в то время).Это будет «неудача», когда это произойдет, особенно потому, что маловероятно, что многократные отправки произойдут быстро, но это будет крайне раздражающим для пользователей и тестировщиков, которые не смогут повторить ошибку.

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 изменяет значение. Судя по тому, что я видел, это похоже на дело.