This project is read-only.

Why IWorkContextAccessor instead of WorkContext?

Topics: Core
Dec 31, 2011 at 12:27 AM

Seeing recent changesets where the latter was changed to the former I'm just curious, what is the motivation? (I'm doubly curious because I'm using the same approach to access the work context.)

Dec 31, 2011 at 12:31 AM

You want to access this late. Same reason why some dependencies are better in a Work<T>. Otherwise bad things happen.

Dec 31, 2011 at 10:56 AM
Edited Dec 31, 2011 at 10:56 AM

Thanks, that's what I have also figured out the hard way... But wouldn't it be better then to only store the IWorkContextAccessor reference and then get the context with GetContext() in subsequent methods instead of storing the WorkContext instance by calling GetContext() in the ctor? I really can't remember it exactly, but I experienced "bad things" when calling GetContext() in the ctor, maybe it was an IHtmlFilter...

Dec 31, 2011 at 11:41 AM

Also, doing any work in the constructor other than storing references can be hazardous from a performance aspect.

Dec 31, 2011 at 5:23 PM

It depends on what sort of service is requesting it. I saved the WorkContext just because I didn't want it to be resolved multiple times. And changed to IWorkContextAccessor because ISingleton can't get WorkContext, and Autofac is throwing an exception in this case, which makes sense. So those recent changes are almost prevention work.

Dec 31, 2011 at 5:25 PM

@randompete, resolving a reference by constructor injection or in the constructor itself should have the same performance impact. Interesting though is that I pushed some changes to remove the calls to InjectUnsetProperties() which was heavy. Resulting in almost 100% performance gain in terms of requests per second.