Question

Is it a recommended practice to raise all the events asynchronously if the class (event raising object) does NOT interested on how the parameters of the events are manipulated by the client objects (receivers of the events)?!

Please guide me?

Answer 1

No it’s not a recommended practice.

You have to consider other factors, like:

• Thread affinity requirements of the generting class.
• Whether UI elements are involved (a variation on thread affinity)
• Whether the classes responding to events can accept concurrent processing on multiple threads (aka are they threadsafe).
• Whether there is thread-local data involved (e.g. Thread.CurrentPrincipal, HttpContext, etc)
• Whether you are gaining anything from multi-threaded processing.

Multithreading makes things complicated. Asynchronous event handling requires multithreading. You should only introduce complexity if it buys you something (e.g. improved performance, more responsive user interaction, simplification of something else that would be even more complicated).

Without knowing the details of your specific situation, it’s impossible to recommend whether asynchronous eventing is appropriate. But all things being equal – I would avoid asynchronous eventing unless I had a strong reason for it.