The best way to let asp.net fire events and methods automatically -according to a schedule-

Well, I'm sure this is not 开发者_高级运维the first time to see this question. and TBH you can find this question answered on many other websites and blogs -not only here-

But I never saw a complete answer for this question, I mean no one talked about the advantages and the disadvantages. no one shared a real experience.

Although Quartz.NET seems like a good solution but yet, there's no enough reviews or a good comparison between the different ways to achieve such a thing.

As far as I read about it I found this are the possible ways of doing this :

Using a: Web Service, Windows Appliction, Console Application, Quartz.NET.

Examples of stuff I want to achieve with the scheduled or automatic methods/events are like archiving after a certain period, auto deleting/moving records in the database, setting a property of an object after a certain time, automatically run some methods according to my holiday schedule.

I hope you'd share your experience either with one of those approaches or share a new way of doing this.

At the e-commerce Web site that I work for, we use Quartz.NET in a Windows service called the "Worker". It executes Quartz.NET IJob implementations via the programmatically-defined schedule and runs independently of the Web site processes. It does things like dispatch e-mails in batches, update statistics, refresh the SOLR indexes, and so on.

This way, we don't have to worry about our schedules getting reset or missed as a result of worker processes recycling, or dealing with the madness of having multiple instances running simultaneously on the same machine as a result of a Web garden. The Worker is installed, started, and stopped independently of the Web site, and could even exist on a separate machine, giving flexibility in maintenance and deployment.

The Web site and the Worker both share a common Model DLL that contains the object model and NHibernate configuration, so there is not much logical duplication of business logic.

Before I created the Worker/Windows service, I relied on simple console applications that were executed via scheduled tasks. This worked well up to a point, but as the site became more complex and required more and more batch jobs to run periodically, I found myself maintaining a lot of independent console programs and a lot of independent scheduled tasks, which became more difficult as the number of jobs required increased. By consolidating scheduling with Quartz.NET into a single Windows service, I now only have one process to keep an eye on and can be assured that any business logic changes are "in sync" since the model only has to be updated in two places--the Worker and the Web site--instead of many--the Web site and lots of little console applications.

I explored options like storing runtimes in the ASP.NET cache or keeping references around in the worker process's memory, but I found that (1) this made the exact execution time of the task dependent on incoming requests to the Web site and (2) the use of a Web garden caused unnecessary duplication of effort (since the task would be "scheduled" in multiple worker processes on the same machine).

Creating a Windows service that can be started and stopped via the usual Windows mechanisms has proved to be, in my humble opinion, the most logical, intuitive, and maintainable result in the long run.

Both the Web site and Worker use WiX to compile down to two Windows Installer MSI files, so updating them is a snap--just double-click the MSI on the server, and our update is good to go.

Hope that helps!

The obvious problem will be that a web application is intended as a request-response service. So, although probably hackable (and surely people have), you would need to respond to a request in order to kick off some sort of processing task. I know you want a webforms solution, but I would suggest this type of problem domain is not best solved with a web platform.

As a suggestion, although maybe not one you wanted to hear, you could of course use a Windows Service solution and all the good things that go with that platform (background timers, MSMQ processing, threading, easier security integration, etc) and surface it's information via a web based UI application (connected via WCF).

Check out the following question that was asking something similar:

https://stackoverflow.com/questions/3243400/how-to-do-background-processing-similar-to-that-on-stackoverflow/

I linked to a blog post by Jeff Atwood himself that had a unique approach to accomplish this:

https://blog.stackoverflow.com/2008/07/easy-background-tasks-in-aspnet/

I am not endorsing this approach but it's a good alternative if you don't want to make a service or use another tool.

I've seen this question asked in at least a 100 ways. In my experience the best way to go about scheduling is to start with a well thought out n-tier design. This allows you the flexibility to change out front ends as needed. For example, a console application to call Method1() which is handled by the windows task scheduler. I firmly suggest you stick to the windows task scheduler unless requirements drive you to do otherwise.

Timer's are a great idea, in concept. In execution they can be buggy or simply not function whatsoever depending on the environment (some timers don't work in win services).

As far as a Windows Application, I have never used this for a scheduled task (outside of compiling a console app as a winform app so the console window won't display). As it displays unecessary UI, confusing the user.

On the DB side you have new options like jobs and Triggers.

In summary, there is no silver bullet. I suggest you default to a console app and refactor your code so you have a nice design. Read a design pattern book if you need to.