计划任务或Windows服务
我必须创建一个应用程序，该应用程序将从数据库读取一些信息，处理数据，将更改写回数据库，然后将包含这些更改的电子邮件发送给某些用户或组。我将用 C# 编写此内容，并且此过程必须每周在特定时间运行一次。这将在 Windows 2008 Server 上运行。
在过去，我总是会采用创建带有计时器的 Windows 服务并在 app.config 文件中设置运行时间/日期的方式，以便可以对其进行更改，并且只需重新启动即可捕获该服务。更新。
不过，最近我看到了一些博客文章，建议编写一个控制台应用程序，然后使用计划任务来执行它。
我读过很多讨论这个问题的帖子，但还没有看到关于哪个过程更好的明确答案。
你们觉得怎么样？
感谢您的任何想法。
I have to create an app that will read in some info from a db, process the data, write changes back to the db, and then send an email with these changes to some users or groups. I will be writing this in c#, and this process must be run once a week at a particular time. This will be running on a Windows 2008 Server.
In the past, I would always go the route of creating a windows service with a timer and setting the time/day for it to be run in the app.config file so that it can be changed and only have to be restarted to catch the update.
Recently, though, I have seen blog posts and such that recommend writing a console application and then using a scheduled task to execute it.
I have read many posts talking to this very issue, but have not seen a definitive answer about which process is better.
What do any of you think?
Thanks for any thoughts.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果它是每周一个的应用程序，为什么要浪费资源让它在本周剩余的时间里在后台运行呢？
控制台应用程序似乎更合适。
我使用的典型经验法则就是这样的。首先我问几个问题。
基本上从这里开始，如果执行频率是每天或不太频繁，我几乎总是倾向于计划任务。然后看看更改的频率，如果对计划更改的需求很高，我也会尝试倾向于计划任务，以允许对计划更改进行无编码更改。最后，如果除了时间之外还有其他触发器的想法，那么我将倾向于 Windows 服务来帮助“面向未来”应用程序。例如，每次用户将文件放入 X 文件夹时，要求都会更改为运行。
If it is a one per week application, why waste the resources for it to be running in the background for the rest of the week.
A console application seems much more appropriate.
The typical rule of thumb that I use is something along these lines. First I ask a few questions.
Basically from here if the frequency of execution is daily or less frequent I'll almost always lean towards a scheduled task. Then looking at the frequency for changes, if there is a high demand for schedule changes, I'll also try to lean towards scheduled tasks, to allow no-coding changes for schedule changes. lastly if there is ever a thought of a trigger other than time, then I'll lean towards windows services to help "future proof" an application. Say for example the requirement changes to be run every time a user drops a file in X folder.
我遵循的基本规则是：如果您需要连续运行，因为感兴趣的事件可能随时发生，请使用服务（或 UNIX 中的守护程序）。
如果您只想定期执行某些操作，请使用计划任务（或
cron）。这里的关键是您的短语“必须每周在特定时间运行一次”- 执行计划任务。
The basic rule I follow is: if you need to be running continuously because events of interest can happen at any time, use a service (or daemon in UNIX).
If you just want to periodically do something, use a scheduled task (or
cron).The clincher here is your phrase
"must be run once a week at a particular time"- go for a scheduled task.如果您只有一个应用程序并且需要它每周运行一次，那么调度程序可能会很好，因为不需要在系统上运行单独的服务和进程，而系统上的服务和进程大部分时间都是空闲的。
If you have only one application and you need it to run once a week may be scheduler will be good as there is no need to have separate service and process running on the system which will be idle most of the time.