views:

60

answers:

1

The more I research a couple topics with regards to ASP.net, the more I feel like there's a real gap on how and where to properly apply a few things to the ASP.net realm (both webforms and mvc).

Workflow Foundation

I love using WF; however, everything that I've ever read is that it's not recommended for ASP.Net apps because of the 1 workflow hosting environment per app domain restriction. Now I haven't seen where this restrictions changed but I also can't find any information about this restriction since the old .Net 3.0 (.netfx) days. I have been seeing advice to make workflows into services which sounds good; however, wouldn't such have the exact same limitations where if the service is hit too often, it would result in some performance issues? Is there a place for WF in ASP.Net and if so, where?

Parallel Processing

The same thing for parallelism. The advice that I've always seen/read about doing multi-threaded ASP.Net applications was to not do it because of the way the thread pool is setup in the application pools of IIS. Now with .Net 4 coming out and multi-core processors everywhere, multi-threading seems to be one of the hottest topics again. I like what I'm seeing in the parallel extensions in 4.0; however, is the advice still don't do it in ASP.Net or is there some places where it'd be recommended at this point?

Does the advice on these two items from years ago still stand? Should they still be avoided in the ASP.Net world?

Thanks

+4  A: 

Multithreading remains fairly irrelevant in ASP.Net - the reason is that pretty much any code you write in ASP.Net is intended to handle a single request. There are two main reasons for using multiple threads in other types of application:

  • Updating UI while another thread does the work - on a web app the user won't receive anything until the entire task is complete anyway.
  • Better performance by using all available cores - not much benefit when the other cores are busy handling requests from other users.

Workflow is designed mostly for long running tasks - don't use it where some simple code in a button click handler would do. Remove the requirement for an instant response and a simple queue takes care of most potential performance issues. I have used WF within ASP.Net pages, but I wouldn't do it if I needed speed or a large number of users.

Tom Clarkson
+1 For... Workflow is designed mostly for long running tasks
kevchadders