#c# #asp.net #.net #asynchronous
#c# #asp.net #.net #асинхронный
Вопрос:
У меня есть веб-приложение, и пользователи делают запросы на изменение больших объемов данных. Возможно, сохраняется 1000 или более объектов.
Я заранее проверяю эти запросы, а затем начинаю сохранять данные. Сохранение по отдельности действительно не занимает много времени, но кратно нескольким тысячам, и это так. Я использую фреймворк OR / M и не хочу отходить от него … и на самом деле это не узкое место.
Я мог бы создать постоянный граф объектов меньшего размера — просто «план» о том, как сохранить его остальную часть, а затем сохранить его каким-либо другим способом, но я бы действительно предпочел более простое решение.
В идеале я бы проверил, а затем запустил асинхронную задачу, которая сохраняла бы все данные. Пользователь получит подтверждение после его проверки, и они могут продолжить свой веселый маленький путь.
Возможно ли это в .NET? Есть предложения?
Спасибо
Комментарии:
1. обратите внимание, что не будет никакой гарантии , что данные будут сохранены при этом подходе — если это важно для вашего API, вам придется дождаться ответа на сохранение
2. Понятно — однако все, что может привести к сбою сохранения в асинхронном режиме, также приведет к сбою в режиме синхронизации. Я полагаю, проблема заключается в том, что пользователь получает уведомление о том, что это не удалось. Еще раз спасибо.
Ответ №1:
Вы можете сначала проверить входные данные, установить какую-то метку состояния, указывающую, что все прошло нормально, а затем запустить часть сохранения в новом потоке.
Я имею в виду что-то вроде этого:
protected void Button1_Click(object sender, EventArgs e)
{
new Thread(() => {
//logic to save the data goes here.
}).Start();
Label1.Text = " Input validated. Thanks!";
}
Пользователь может безопасно закрыть браузер, и операция завершится.
Редактировать
Комментарий Broken Glass верен в том смысле, что этот подход плохо масштабируется. Есть лучший способ выполнить этот тип асинхронных операций. Это подробно описано здесь .
Комментарии:
1. Это веб-приложение — может быть любое количество пользователей — вы должны использовать пул потоков вместо явного создания нового потока.