Служба Windows или запланированное задание, какое из них мы предпочитаем? - PullRequest
19 голосов
/ 20 апреля 2009

Если нам нужно написать программу, которая работает периодически, какой путь мы предпочитаем? Написание службы Windows или написание консольного приложения, которое работает как запланированное задание?

Ответы [ 10 ]

21 голосов
/ 20 апреля 2009

Я бы предложил запустить процесс как запланированное задание, если вы можете, и написать сервис, только если вам нужно. Службы немного сложнее написать (правильно), и если вы выполняете свой процесс по какому-либо расписанию, вам гораздо лучше использовать планировщик Windows, чем пытаться создать собственный планировщик (в servce).

  • Планировщик задач Windows более эффективен, чем ваш домашний планировщик
  • Планировщик задач Windows предлагает ряд параметров, которые вы почти наверняка не будете пытаться реплицировать, но которые впоследствии могут оказаться полезными
  • Если вы создаете сервис, вам придется перекомпилировать программу, если вы хотите изменить логику, которая определяет условия выполнения задачи. Если вы используете планировщик, вы просто переключаете некоторые опции и с этим покончено.

Если вы пытаетесь сделать выбор между ними, очевидно, что использование планировщика заданий является приемлемым вариантом. И если использование планировщика заданий является жизнеспособным вариантом, то создание службы почти наверняка является неправильным выбором.

13 голосов
/ 20 апреля 2009

Зависит от того, насколько регулярно вам это нужно.

Если это то, что нужно запускать каждые 60 секунд в течение всего дня, я бы пошел с Windows Service.

Если это то, что нужно запускать только один раз в день, я бы пошел с запланированной задачей

Что-нибудь посередине ... используйте свое суждение :) 1007 *

7 голосов
/ 20 апреля 2009

Начните с консольного приложения. Отделите логику, которая будет находиться внутри вашего цикла loop-process-sleep, тогда вы сможете легко переключаться между ними - даже в одном и том же EXE-файле.

Я сделал это. Мы могли бы позвонить:

ourservice.exe -console

и он просто побежал. Или

ourservice.exe -install

и он будет установлен как сервис:)

Я бы пошел по расписанию в 99% случаев. Если вам нужно все время работать, прослушивать порты, смотреть папку (возможно - можно делать каждые 10 секунд без проблем), а затем делать это в службе. Если все, что вы делаете, это просыпаетесь, выполняете некоторую обработку (или нет), а затем возвращаетесь в спящий режим: используйте планировщик. Это проще, чище (управление памятью, особенно если вы используете COM-объекты, и действительно, если вы используете MAPI), а параметры (еженедельно, но не по вторникам в 17:00) с планировщиком MS лучше, чем вы можете написать в время ..... которое НЕТ времени, поскольку оно уже существует и свободно

О, и отладить консольное приложение (планировщик) легче, чем службу .... :) Или кто-то "просто запустит его".

2 голосов
/ 22 октября 2009

Я думаю, что сервис может быть полезен, если вы хотите использовать WCF или .NET Remoting и иметь клиентские приложения, взаимодействующие с каким-либо хост-сервисом; в противном случае я согласен с тем, что запланированная задача предпочтительнее услуги, если более сложная служба не добавляет ничего нового.

И @Tom, его заявление о необходимости оставаться подключенным к компьютеру для выполнения запланированного задания неверно. Я только что проверил себя и подтвердил, что задание по расписанию Windows будет по-прежнему выполняться, даже если вы не вошли в систему (если, конечно, вы не выберете вариант, когда задание будет выполняться только во время входа в систему).

2 голосов
/ 20 апреля 2009

Избегайте услуг, если вы не должны их использовать.

Это процесс - что означает, что он все время . Неправильное использование системных ресурсов - плохая практика.

Меня лично оскорбляет то, что у других людей процесс выполняется 24/7 на МОЕМ компьютере, когда он совершенно не нужен. Это МОЯ производительность, которую они используют. Я отключаю все ненужные фоновые сервисы.

2 голосов
/ 20 апреля 2009

Или посмотрите на quartz.net , если вы хотите, чтобы что-то запускалось периодически. Это готовый каркас, который позволяет вам планировать задачи и избавляет вас от написания служебной части.

2 голосов
/ 20 апреля 2009

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

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

1 голос
/ 18 июня 2009

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

1 голос
/ 20 апреля 2009

«Это зависит», но я обычно предпочитаю запланированные задачи, для простоты:

  • Вам не нужно добавлять какой-либо стандартный сервисный код в вашу программу.
  • Ваша программа может быть запущена из командной строки для устранения неполадок (для этого вам потребуется использовать переключатели командной строки в служебной программе).

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

За то, что должно выглядеть как готовый продукт, а клиент должен установить себя, я бы пошел с Windows Service.

И расписание также является проблемой. Минимальное расписание для запланированного задания составляет одну минуту. Что-нибудь ниже этого, вам либо нужно использовать службу Windows, либо встроить цикл в вашу работу.

1 голос
/ 20 апреля 2009

Это зависит от того, что вы имеете в виду периодически? Каждую секунду, каждую минуту, каждый час, каждый день?

Я бы сказал, что чем чаще выполняется задача, тем более предпочтительной является служба Windows.

...