• Как спроектировать отказоустойчивое решение для приложения при нестабильной БД?

    @newalex Автор вопроса
    Выше я написал: "То, что его изменения попадут в базу не прямо сейчас, а через несколько секунд(в случае проблем с базой) в моем случае на логику работы и на пользователя никак не повлияет". В таком случае я не считаю, что пользователю вообще надо что то показывать, беспокоить его какими то дополнительными сообщениями. Да и такое требование в ТЗ описано.

    С точки зрения реализации видимо самый простой вариант - проапдейтить EF до 6ой версии и использовать DbExecutionStrategy (https://msdn.microsoft.com/ru-ru/library/system.da...(v=vs.113).aspx)
  • Как спроектировать отказоустойчивое решение для приложения при нестабильной БД?

    @newalex Автор вопроса
    Я как раз и хочу, чтобы пользователю не выдавались сообщения о такой проблеме. То, что его изменения попадут в базу не прямо сейчас, а через несколько секунд(в случае проблем с базой) в моем случае на логику работы никак не повлияет.

    Локальный кеш... если только в памяти. Изменения в базе очень примитивны - смена статуса заявки например, комментарий в пару строк. Пока не могу придумать, как мой репозиторий будет складывать неудачные транзакции в кеш и потом их деплоить.