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
|
Hi, I'd like to use LightSpeed within the context of the DotNetNuke ASP.NET application framework. The problem is that DotNetNuke modules do not have access to modify the Global.asax file to add the BeginRequest and EndRequest code I see in the LS samples. How can I setup/configure LightSpeed to do a "per request unit of work" (which I assume is recommended mode for ASP.NET applications?) without access to the Global.asax ? I do have the ability to modify the web.config, is there a special HttpModule or something I could write that would do the necessary stuff to implement a per request UnitOfWork pattern using LightSpeed? Or some other config/setup I could do programmatically? |
|
|
An IHttpModule would certainly be one way of doing this -- in your IHttpModule.Init implementation, subscribe to the BeginRequest and EndRequest events of the provided HttpApplication, with the same code as you see in the Global.asax.cs samples. You might also be able to do something similar from within the DNN page lifecycle. If DNN provides overridable "page initialising" and "page disposing" methods (or analogous methods on a controller class) then you could implement a base controller class that initialises and disposes the PerRequestUnitOfWorkScope. I don't know enough about DNN to say exactly where this might fit into the DNN framework though. |
|
|
Ok, I'm going to try the IHttpModule method, but I'm new to LS and I'm confused as to what exactly to put in the Init(), BeginRequest() and EndRequest() lifecycle events. I know I need to new up a "context" such as LightSpeedContext() or LightSpeedContext<MyUnitOfwork>(), but what's the difference between the standard and generic<> version? Looking at the samples, I see different code in the "Store" sample vs. the "FilmFestival" sample vs. the "Poker" sample. My environment is ASP.NET Web Forms, with my custom IHttpModule to subscribe to the Application BeginRequest and EndRequest events, and I'd like to implement the recommended "Session per Request" pattern for web apps. Could you tell me which solution in the /Samples folder is the correct one to use? It seems like some of the samples use the explicit "PerRequestUnitOfWorkScope" class, but others do not? thanks.
|
|
|
The difference between LightSpeedContext and LightSpeedContext<T> is that when you call CreateUnitOfWork, the normal version returns IUnitOfWork and the T version returns your own UnitOfWork-derived class. If you want to use LINQ queries, then you'll want the latter, because the base IUnitOfWork interface doesn't declare all the useful domain-specific LINQ query properties (e.g. StoreUnitOfWork.Customers). Store and Poker are relatively old samples; FilmFestival is more up-to-date and is the better one to follow. FilmFestival is written using ASP.NET MVC though, and therefore may be a bit harder for you to map onto a Web Forms application. However since you are proposing to use an IHttpModule rather than a page-centric approach then this shouldn't be a huge issue. You should be able to follow a similar model to what's shown in FilmFestival's ControllerBase class, in terms of creating a scope on demand and stashing it in the current HttpContext; the IHttpModule probably needs to be involved only to make sure it gets disposed. (And if DNN has an equivalent to the OnResultExecuted method in Controller, then you may not even need that and you may be able to avoid the IHttpModule altogether.) Hope this is enough to get you going -- if not let us know and I'll get someone more ASP.NET-savvy than I am to chime in! |
|
|
Ok, I think I've got it working after looking at the FilmFestival sample in more detail. Does the "UnitOfWorkScopeBase<>" need to be set to null after calling Dispose() on it? In FilmFestivalController I noticed that the code only creates a new instance if the member variable _unitOfWorkScope == null. However, in my testing, that variable is only null the very first time the application is started up. Each web request that variable is not null, therefore it's reusing the same instance, is that ok? I am calling Dispose() on the UOW object, but it looks like that does not make it null for future web requests. Is this correct? |
|
|
"Does the "UnitOfWorkScopeBase<>" need to be set to null after calling Dispose() on it?" Not in the FilmFestival scenario, because it's a member variable of the Controller class, and the Controller object is about to be thrown away. If there was a possibility it could be reactivated, then we might null the reference so that we weren't returning a disposed object. If you're holding a scope object as a member of your IHttpModule, I don't think you'll ever need to null it, because you'll never dispose it, you'll keep reusing it, and will instead dispose the UOW object. "Each web request that variable is not null, therefore it's reusing the same instance, is that ok?" Yes, it is okay to reuse a scope object (that has not been disposed). The same PerRequestUnitOfWorkScope will serve up a new and different unit of work to each new HTTP request. "I am calling Dispose() on the UOW object, but it looks like that does not make it null for future web requests. Is this correct?" Yes, it is correct to call Dispose on the UOW object. Don't call Dispose on the scope object -- UnitOfWorkScopeBase.Dispose is broken. Also, a minor efficiency detail: if you call _scope.Current.Dispose(), and this page request happens to have gone through without needing a UOW, then this will create a UOW and immediately dispose it. You may therefore want to put an if (_scope.HasCurrent) guard around the _scope.Current.Dispose() call. |
|