BackgroundWorker распараллеливают в ASP.NET
Как уже было сказано, NVI - это прозаичная идиома, связанная с категорией языков. Этому способствует и Herb Sutter, потому что он помогает заключать контракты:
- инварианты класса
- контракты функций (утверждения по переданным параметрам и возвращаемое значение)
- повторяющиеся операции (например, протоколирование)
- контроль над генерируемыми исключениями (плохая идея, хотя;))
Однако реализация может существенно различаться, например, другой пример реализации NVI состоит в том, чтобы объединить его с Pimpl:
class FooImpl;
class Foo
{
public:
enum type { Type1, Type2 };
Foo(type t, int i, int j);
int GetResult() const;
private:
FooImpl* mImpl;
};
И для реализации:
struct FooImpl
{
virtual ~FooImpl();
virtual int GetResult() const;
};
class FooType1: public FooImpl
{
public:
FooType1(int i, int j);
virtual int GetResult() const;
private:
/// ...
};
Я всегда обнаружил, что он передал точку лучше , Вы поняли это?
Главное, что virtual является деталью реализации. И разоблачение деталей реализации в интерфейсе - плохая идея, потому что вы можете изменить их.
Кроме того, детали реализации, как правило, несовместимы с бинарной совместимостью. Например, добавление нового метода virtual в класс может изменить макет виртуальной таблицы (обычная техника реализации) и, таким образом, botch совместимость двоичных файлов. На gcc вам нужно убедиться, что вы добавите последний (среди виртуальных), если хотите сохранить совместимость.
Используя комбинацию NVI + Pimpl выше, нет virtual вообще ( даже не закрытый) в классе выставлен. Макет памяти совместим с обратной связью. Мы достигли бинарной совместимости.
Здесь мы используем сразу несколько шаблонов:
- Метод шаблона
- Стратегия (поскольку мы можем поменять указатель на будет)
- Factory (чтобы решить, какую реализацию мы получим)
6 ответов
Если Вы не хотите пользоваться библиотеками AJAX, или почтовая обработка ДЕЙСТВИТЕЛЬНО долга и была бы тайм-аут стандартный запрос Ajax, можно использовать метод AsynchronousPostBack, который был "старым взломом" в дни .net 1.1.
По существу то, что Вы делаете, имеют Вашу кнопку отправки, начинают почтовую обработку в асинхронном состоянии, в то время как пользователь взят к промежуточной странице. Преимущество для этого - то, что у Вас может быть свое промежуточное обновление страницы так же по мере необходимости, не волнуясь об ударе стандартных тайм-аутов.
, Когда Ваш фоновый процесс будет завершен, он поместит немного "сделанного" флага в базу данных/приложение, variable/whatever. Когда Ваша промежуточная страница делает обновление себя, она обнаруживает этот флаг и автоматически перенаправляет пользователя к "сделанной" странице.
Снова, Ajax заставляет все это обсудить, но если по некоторым причинам у Вас будет очень интенсивный или своевременный процесс, который должен быть сделан по сети, то это решение будет работать на Вас. Я нашел хорошее учебное руководство на нем здесь и там существуют еще многие.
я должен был использовать процесс как это, когда мы работали над "веб-регистрацией" приложение типа, которое взаимодействовало через интерфейс с приложением сторонних производителей и их импортом, API был ужасно медленным.
РЕДАКТИРОВАНИЕ: GAH! Прокляните Вас Guzlar и Ваши богоподобные способности к вводу 8^D.
Вы не должны делать никакой поточной обработки от страниц ASP.NET. Любой поток, который длителен, рискует быть уничтоженным, когда рабочий процесс перерабатывает. Вы не можете предсказать, когда это произойдет. Любые продолжительные процессы должны быть обработаны сервисом окон. Можно начать эти процессы путем отбрасывания сообщения в MSMQ, например.
Это возможно. После того как Вы начинаете новую дискуссию асинхронно от страницы, запрос страницы продолжится и передаст страницу обратно пользователю. Асинхронный поток продолжит работать на сервере, но больше не будет иметь доступа к сессии.
, Если необходимо показать прогресс задачи, рассмотрите некоторые методы Ajax.
ThreadPool.QueueUserWorkItem(delegateThatSendsEmails)
или в Системе. Сеть. Почта. SmtpServer используют метод SendAsync.
Вы хотите поместить электронную почту, отправляющую код другого потока, потому что затем это сразу возвратит пользователя и просто обработает, неважно, сколько времени это берет.
Если Вы хотите использовать multitheading в своей ASP-странице, Вы могли бы с помощью простой модели потоков как это:
{
System.Threading.Thread _thread = new Thread(new ThreadStart(Activity_DoWork));
_thred.Start();
}
Activity_DoWork()
{
/*Do some things...
}
Этот метод является корректной работой с ASP-страницами. ASP-страница с BackgroundWorker не запустится, в то время как BackgroundWorker закончится.
То, что необходимо использовать для этого сценария, является Асинхронными Страницами, опцией, которая была добавлена в ASP.NET 2.0
, страницы Asynchronous предлагают аккуратное решение проблем, вызванных запросами I/O-bound. Обработка страницы начинается на потоке пула потоков, но тот поток возвращается к пулу потоков, после того как асинхронная операция ввода-вывода начинается в ответ на сигнал с ASP.NET. Когда операция завершается, ASP.NET захватывает другой поток от пула потоков и заканчивает обрабатывать запрос. Масштабируемость увеличивается, потому что потоки пула потоков используются более эффективно. Потоки, которые иначе застряли бы, ожидая ввода-вывода для завершения, могут теперь использоваться для обслуживания других запросов. Прямые бенефициарии являются запросами, которые не выполняют долгие операции ввода-вывода и могут поэтому войти и выйти из конвейера быстро. Долгое ожидание для вхождения в конвейер оказывает непропорционально негативное влияние на производительность таких запросов.