I made a custom SessionStateStore provider, however the dependencies were not resolving. I used Unity for DI.
I googled a lot about this problem and got some useful hints, but still I can't get it right.
the providers are constructed and managed by the framework, and there is no opportunity for us to intercept that construction to provide additional dependency injection
override the Initialize() method in your custom provider, and do the dependency injection there
There's a similar problem and a decent solution here and here(StructureMap, not Unity), but I can't get it right.
Please help. Thanks.
Providers are really painful things. There's really no nice way to address this problem, but a practical way is to handle the provider as a Composition Root - in other words, as if it was the entry point of the application. Within the provider you can compose all of your services.
If you use a DI Container (like Unity) you can store the container instance in HttpContext and get it from there to compose your object graph from within the provider.
Related
I want to be able to configure ASP.NET's dependency injection framework to be able to resolve me an instance of Common.Logging's ILog interface. Creating an instance of ILog is done via the Common.Logging's static LogManager.GetLogger methods which require a type as a parameter.
This means that when resolving an instance of ILog I need to know the target type that the DI engine is trying to inject into. In the past I've used autofac modules to solve this problem which other have asked about here, but it would nice to be able to do this purely with ASP.NET's built in Ioc.
I can see that there is the ability to resolve an instance by creating a method that takes an IServiceProvider, but there is no context of the type being injected into that I can see.
Does anyone know how a service can be resolved at runtime with knowledge of the type its being injected into?
I posted the same question in the ASPNET dependencyinjection repo issue register and apparently its not possible.
Is it possible to do property injection with the OrchardCMS?
I know that Orchard uses Autofac and that Autofac does do property injection, but I need to know how to do property injection for the IOrchardServices interface.
Our team is looking at Orchard but our code base is all in ASP.NET 4.0 WebForms and so we will continue to serve aspx pages and slowly migrate those said pages into Orchard as time permits.
With that, we'll need a way to get access to the OrchardServices object. I'm thinking that this is something I'd have to come up on my own. Does any one have any good examples of performing property injection in Orchard?
It's pretty simple - look into the source how it's done with ILogger interfaces and do the same for IOrchardServices. The source file is Orchard.Framework/Logging/LoggingModule.cs. It's exactly what you are looking for, I guess.
Everything is being done via Autofac module (implementation of Autofac.Module class). What that class does is to:
register the implementation of ILogger interfaces (Load method) and
get properties of the processed object and set appropriate ones to object resolved from the container (AttachToComponentRegistration method).
Pretty simple. Autofac modules are a nice way to plug into the DI process.
It would be enough just to copy that source file to your custom Orchard module and changing ILogger to IOrchardServices (and, of course the registered class). The class I mentioned makes use of factory pattern to create instances, but you can change that to simple object creation via new and get rid of the factory-related things.
I'm working on an ASP.Net website along with a supporting Class Library for my Business Logic, Data Access code, etc.
I'm EXTREMELY new and unfamiliar with the Unity Framework and Dependency Injection as a whole. However, I've managed to get it working by following the source code for the ASP.NET 3.5 Portal Starter Kit on codeplex. But herein lies the problem:
The Class Library is setup with Unity and several of my classes have [Dependency] attributes on their properties (I'm exclusively using property setter injections for this). However, the Global.asax is telling Unity how to handle the injections....in the Class Library.
Is this best practice or should the Class Library be handle it's own injections so that I can re-use the library with other websites, webapps or applications? If that is indeed the case, where would the injection code go in this instance?
I'm not sure how clear the question is. Please let me know if I need to explain more.
Though not familiar with Unity (StructureMap user) The final mappings should live in the consuming application. You can have the dll you are using define those mappings, but you also want to be able to override them when needed. Like say you need an instance of IFoo, and you have one mapped in your Class Library, but you've added a new one to use that just lives in the website. Having the mappings defined in the site allows you to keep things loosely coupled, or else why are you using a DI container?
Personally I try and code things to facilitate an IOC container but never will try and force an IOC container into a project.
My solution breakdown goes roughly:
(Each one of these are projects).
Project.Domain
Project.Persistence.Implementation
Project.Services.Implementation
Project.DIInjectionRegistration
Project.ASPNetMVCFrontEnd (I use MVC, but it doesn't matter).
I try to maintain strict boundaries about projects references. The actual frontend project cannot contain any *.Implementation projects directly. (The *.implementation projects contain the actual implementations of the interfaces in domain in this case). So the ASPNetMVCFrontEnd has references to the Domain and the DIInjectionWhatever and to my DI container.
In the Project.DIInjectionWhatever I tie all the pieces together. So this project has all the references to the implementations and to the DI framework. It contains the code that does the registering of components. Autofac lets me breakdown component registration easily, so that's why I took this approach.
In the example here I don't have any references to the container in my implementation projects. There's nothing wrong with it, and if your implementation requires it, then go ahead.
I want to isolate all my code from the IoC container library that I have chosen (Unity). To do so, I created an IContainer interface that exposes Register() and Resolve(). I created a class called UnityContainerAdapter that implements IContainer and that wraps the real container. So only the assembly where UnityContainerAdapter is defined knows about the Unity library.
I have a leak in my isolation thought. Unity searches for attributes on a type's members to know where to inject the dependencies. Most IoC libraries I have seen also support that. The problem I have is that I want to use that feature but I don’t want my classes to have a dependency on the Unity specific attribute.
Do you have any suggestions on how to resolve this issue?
Ideally I would create my own [Dependency] attribute and use that one in my code. But I would need to tell the real container the search for my attribute instead of its own.
Check out the Common Service Locator project:
The Common Service Locator library
contains a shared interface for
service location which application and
framework developers can reference.
The library provides an abstraction
over IoC containers and service
locators. Using the library allows an
application to indirectly access the
capabilities without relying on hard
references. The hope is that using
this library, third-party applications
and frameworks can begin to leverage
IoC/Service Location without tying
themselves down to a specific
implementation.
Edit: This doesn't appear to solve your desire to use attribute-based declaration of dependency injection. You can either choose not to use it, or find a way to abstract the attributes to multiple injection libraries (like you mentioned).
That is the basic problem with declarative interfaces -- they are tied to a particular implementation.
Personally, I stick to constructor injection so I don't run into this issue.
I found the answer: Unity uses an extension to configure what they call "selector policies". To replace the attributes used by Unity, you just code your own version of the UnityDefaultStrategiesExtension class and register you own "selector policies" that use your own attributes.
See this post on the Unity codeplex site for details on how to do that.
I'm not sure that it's going to be easy to do the same if I switch to another IoC library but that solves my problem for now.
Couldn´t you just setup your configuration without the attributes, in xml. That makes it a bit more "unclear" I know, personally I use a combination of xml and attributes, but at least it "solves" your dependency on unity thing.
I have been building web sites with ASP.NET for a while now. At first I avoided learning the intricacies of the ASP.NET Provider Model. Instead I used the canned providers where necessary, and leaned heavily on Dependency Injection frameworks for all my other needs.
Recently however, I have been writing pluggable components for ASP.NET and of course writing lots of custom provider based solutions in order to make that happen. It has become quickly apparent to me however, that a lot of initialization code is being duplicated, which is a bad thing.
So...
Are there any best practices that have emerged on how to avoid the configuration spaghetti code?
Have you built, or have any examples (base/helper classes, custom attributes, reflection) to share of abstracting the basic initialization code out so building custom providers is easier?
NOTE:
Please do not try and send me to the Provider Toolkit site. I have already exhausted that resource, which is why I am turning to the SO Community :)
I just did a rough implementation of rather basic implementation of the membership and role providers, and I don't have any code duplication at all!
I have divided everything into three projects (plus tests):
Application - asp.net mvc app. models, controllers etc.
Infrastructure - IoC and Interfaces
Infrastructure.Web - Providers
The model for User and Role implement interfaces from Infrastructure and those classes get registered to the IoC on application startup. The providers then asks the IoC to resolve the classes and does it's thing. This way I can add things to the model and user interface yet using the same providers. The one problem I've noticed, is that the web being launched by the "ASP.NET Configuration"-button can't use the providers, as the setup is being done in Application_Start and the "ASP.NET Configuration" is another web. I don't see this as a problem though.