In your example, you're not managing any state. Anyone can call ProcessRequest
as many times as they want on the same instance and they will get a new DateTime.
But what if you did this:
private DateTime _dateTime = DateTime.Now;
public void ProcessRequest(HttpContext context)
{
context.Response.Write(_dateTime);
}
Now you'll get the same response every time after the handler instance is instantiated. Unless ASP.NET generates a new one every time.
IsReusable
can indicate whether your handler class manages any state that is OK to share between separate requests. If it manages state that isn't OK to share, then it's not likely to be externally idempotent - or possibly even not thread-safe. Calling ProcessRequest
with the same input conditions may not result in the same output, because your specific handler implementation also has some instance-level variables that are not OK to share when it determines the output. (And in fact, technically your current implementation is an example of that). In these cases the instance is probably not "reusable" - and ASP.NET needs to generate a new instance each time to ensure predictability.
So for cases where you don't manage state, or you have very simple handlers where the state is "obvious" (like the example we have here), IsResuable
might seem pointless. But if you have a very complex handler - possibly one that does keep some state that's expensive to initialize but OK to share - you would want to indicate to ASP.NET it's OK to reuse it for performance.