![]() I think keeping both the DefaultServiceProvider & CurrentServicePrivder is important Csla needs to track the Default (or Root, if you'd prefer). Therefore this would have to be an instance level AsyncLocal field, but we just want a single backing field for CSLA to consume this from as opposed to currently where it checks ContextManager or WebContextManager. Ideally, concurrent CSLA unit tests would be able to run, each thread settings its own root IServiceProvider if needed to provide better isolation between the different test scenarios. I think a static property should be avoided, as that complicates unit testing. ![]() ![]() So I am left with the following suggestions: ![]() Therefore its a bit hard to follow the convention Services for this CSLA property, when the scopes could represent anything as far as CSLA is concerned. However in CSLA's case, it doesn't know (or care) whether the scoped IServiceProvider given to it represents an Http Request, or some other more granular scope, like a background job, or an individual data portal operation. When asp.net core creates a scoped IServiceProvider for a request, you can access it on IHttpContext.RequestServices - so the asp.net core convention so far, seems to be to name the property like this: Services - which gives rise to ApplicationServices (for root IServiceProvider) and RequestServices (for request scoped IServiceProvider). Therefore, for the root IServiceProvider, I propose CSLA ApplicationContext has a method like this:ĪpplicationContext.SetApplicationServices(IServiceProvider sp) Īnd the property for CSLA to get this can be internal to CSLA so it can use it as a fallback where necessary. net core for the root IServiceProvider is to refer to it as ApplicationServices.įor example, the ApplicationServices property on IApplicationBuilder interface: With respect to naming, the convention used in. This will enforce the idea that code external to the CSLA framework shouldn't be using this mechanism to get access to the root IServiceProvider - (code outside CSLA can grab and manage a reference to the root IServiceProvider for its own purposes, in its own way) - but should only be handing it to CSLA so CSLA can do it its thing. Therefore it may make sense to restrict access to the root IServiceProvider, by making it an internal property, so external code can set the root IServiceProvider, but can't get at it. AFAIK this is the only reason CSLA will need a reference to the root IServiceProvider. CSLA will usually always want to get the current scoped IServiceProvider, and there will be some CSLA logic that may fallback to the root IServiceProvider if there is no scoped IServiceProvider available. We should also look at when / why CSLA needs this root IServiceProvider. For example in a console app that doesn't use scopes it might be valid to operate within the root scope only. Perhaps this needs to be moved into ApplicationContext as a static property (I generally try to avoid static properties though) or perhaps it should only ever be sourced from the default ContextManager - basically I just think the there should one single backing field for the root IServiceProvider, as it doesn't seem to make a difference which context you want the root provider in (Web vs non web) as the root IServiceProvider will always be the same in either case - and CSLA would only ever want to use this, when there was no more granular scope available. I am not sure of the benefit of having the individual ContextManagers hold the reference to the root IServiceProvider. This means there are currently 4 possible backing fields for these two different IServiceProvider's. You can see however that ApplicationContext doesn't actually hold these references itself, it sources them from the correct ContextManager at the time - of which there could be two - either the default ContextManager or the WebContextManager. ApplicationContext provides access to two different IServiceProvider's - there is the root one - which is exposed via the property named DefaultServiceProvider, and the scoped one, exposed by the property ServiceProviderScope - they can be seen on this commit:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |