This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I am getting my UnitOfWork from a BasePage class, but now I need a UnitOfWork for a static method on one of my aspx.cs classes. Usually I could just instantiate the class I needed and call the method, would this work? Should I be using units of work inside static methods at all? Thanks, Edward |
|
|
Specifically this is for using AJAX with [WebMethod] xml tags. I am worried that this won't work well with disposing UnitOfWork on the call to end_request. Should I just create a temporary UnitOfWork inside these methods? |
|
|
If your static method is being called as part of an HTTP request, and you want it to participate in the same unit of work as the rest of that request, then you can just use PerRequestUnitOfWorkScope: public static void MyMethod() { Remember, PerRequestUnitOfWorkScope is a conduit to the request-wide UOW: you don't need to use the same PRUOWS to get the same UOW. |
|
|
public static void MyMethod() { Do I need to put .Current after that? |
|
|
Yes, you do. Sorry about that! |
|
|
Ivan, This post brought up a question that I have been meaning to ask. If you access the PerRequestUnitOfWork from within a usercontrol, does this also return the request wide UOW? |
|
|
Yes. Request-wide means request-wide*. It doesn't matter where you are in the handling of the HTTP request -- page, Global.asax event, IHttpHandler, pipeline module, user control, library called from UI code, anywhere -- PerRequestUnitOfWorkScope will return the same unit of work for the entire duration of the HTTP request. This is because PerRequestUnitOfWorkScope doesn't actually store the UOW itself. Rather, it backs onto the HTTP request context, HttpContext.Current. And HttpContext is the same for the entire duration of the HTTP request, no matter which bit of code is running at the time. So the UOW depends only on which HTTP request you're in, not on which component happens to be running code at the time. When you ask PRUOWS for the current unit of work, it looks in HttpContext.Current.Items (under a super-secret key) to see if there is a unit of work already stashed there. If there is, it returns that; if not, it creates a new UOW and stashes it under that key. Writing somePruows.Current is therefore roughly equivalent to writing (MyUnitOfWork)(HttpContext.Current[BAKED_IN_KEY]). As you can see from the 'expanded' version, it doesn't care which page, user control or whatever you're in -- it only cares which HTTP request you're in. Hope that clarifies things! * There are two qualifications to this: 1. It is only 'request-wide' in the context of getting your UOWs from PRUOWS. If you spin up your own UOW in a user control using LightSpeedContext.CreateUnitOfWork(), that will NOT be the same UOW as you get from PRUOWS. (However, if a user control creates its own instance of PRUOWS, that will share the HttpContext as any other instances created during the same request, so it WILL return the same UOW.) 2. PRUOWS actually scopes by type as well as by request. So if you create a PRUOWS<BobsUnitOfWork> and a PRUOWS<MikesUnitOfWork> then these will return different UOW objects. |
|