Shortly speaking I am trying to link Castle Windsor container with Unitycontainer. Let me explain the context:
I have a project in which for very long time it used castle windsor. A few days ago, I got a bunch of dll's that I must consume / use from my old project. Those DLL's use Unity Container as their injection mechanism. I also have access to interfaces / implementations that are found in those dlls but I would not try to instantiate manually implementations but I would just prefer, if possible, to link the Unity container with my current castle windsor container. How could I achieve this?
So if I have:
public class MyService: IService
{
public MyService (IThidPartyService thirdParty)
{
}
}
If I resolve IService with windsor it would be nice that IThirdPartyService to be solved by the other container: Unity.
Thank you!.
I think this is a perfect example for the use of a custom ISubDependencyResolver. Whenever Castle won't know how to resolve a specific dependency it will address that custom resolver. That new resolver will depend on the Unity Container and will use it to resolve "for" Castle.
Castle's documentation states that:
If previous places weren't able to resolve the dependency resolver
will ask each of its sub resolvers (ISubDependencyResolver) if they
can provide the dependency.
So when that dependency will not be found in Castle it will seek your new resolver which will provide the dependency.
Here is a working example with both Constructor Injection and Property Injection:
class Program
{
static void Main(string[] args)
{
var unityContainer = new UnityContainer();
unityContainer.RegisterType<IDependency, Dependency1>();
unityContainer.RegisterType<IPropertyDependency, PropertyDependency1>();
WindsorContainer castleContainer = new WindsorContainer();
castleContainer.Kernel.Resolver.AddSubResolver(new UnityResolver(unityContainer));
castleContainer.Register(
Component.For<SomeType>());
var result = castleContainer.Resolve<SomeType>();
}
}
public interface IDependency { void Foo(); }
public class Dependency1 : IDependency { public void Foo() { } }
public interface IPropertyDependency { }
public class PropertyDependency1 : IPropertyDependency { }
public class SomeType
{
public SomeType(IDependency dependency) { ConstructorDependency = dependency; }
public IDependency ConstructorDependency { get; private set; }
public IPropertyDependency PropertyDependency { get; set; }
}
public class UnityResolver : ISubDependencyResolver
{
public UnityResolver(UnityContainer container)
{
Container = container;
}
public bool CanResolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
{
return Container.Registrations.Any(z => z.RegisteredType.Equals(dependency.TargetType));
}
public object Resolve(CreationContext context, ISubDependencyResolver contextHandlerResolver, ComponentModel model, DependencyModel dependency)
{
return Container.Resolve(dependency.TargetType);
}
public UnityContainer Container { get; set; }
}
And the result:
As for the code for checking Unity for the CanResolve - I'm sure it can be improved - I do not know much about Unity
Related
I'm working on a project which currently uses the Service Locator Anti-Pattern all over the code. I'm starting the process to slowly convert everything to using dependency injection, however because of the sheer size of the project I'd like to do this over the course of time.
I'm have a custom factory with 100's of dependencies registered with custom implementations. So I'd like to just wrap my container with unity, if my current container doesn't have the implementation then fall back to use unitys.
I've written this class to wrap IUnityContainer
public class GlobalFactoryUnityWrapper : IUnityContainer
{
IUnityContainer _unityContainer = new UnityContainer();
IUnityContainer _parent;
public GlobalFactoryUnityWrapper(IUnityContainer parent = null)
{
this._parent = parent ?? this._unityContainer.Parent;
}
public IUnityContainer Parent => this._parent;
//... Other IUnityContainer members
public object Resolve(Type type, string name, params ResolverOverride[] resolverOverrides)
{
if(GlobalContext.InstanceFactory.CanGetInstance(type))
{
return GlobalContext.InstanceFactory.GetInstance(type);
}
return this._unityContainer.Resolve(type, name, resolverOverrides);
}
}
I have most of the dependencies register for my controller there, However the controllers themselves are not, So it falls back to use unity's container.
Edit
I think I'm using the wrong thing, I should be using a strategy. my main goal is if the container doesn't contain an implementation, Fall back to use a what's registered in the old container
I needed to create a fallback strategy, this probably isn't the most optimal code but it's working for now
public class FactoryFallbackExtension : UnityContainerExtension
{
public FactoryFallbackExtension()
{
}
protected override void Initialize()
{
var strategy = new FallBackStrategy(Context);
Context.Strategies.Add(strategy, UnityBuildStage.PreCreation);
}
}
public class FallBackStrategy : BuilderStrategy
{
private ExtensionContext baseContext;
public FallBackStrategy(ExtensionContext baseContext)
{
this.baseContext = baseContext;
}
public override void PreBuildUp(IBuilderContext context)
{
var key = context.OriginalBuildKey;
if (key.Type.IsInterface)
{
if(GlobalContext.InstanceFactory.CanGetInstance(key.Type))
context.Existing = GlobalContext.InstanceFactory.GetInstance(key.Type);
}
}
}
Then When I configure my container I can just add the Container extension like so:
public static void Configure()
{
var container = new UnityContainer();
RegisterDepedencies(container);
container.AddExtension(new FactoryFallbackExtension());
GlobalConfiguration.Configuration.DependencyResolver = new UnityDependencyResolver(container);
SetControllerFactory(container);
}
When creating an application with Dependency Injection and it utilizes a framework for Dependency Injection such as Unity (or Ninject).
How do you initialize registering the interfaces to the container at the beginning all together and keep them available for the application to use throughout its running lifecycle of the application?
Do you need to pass the DI Container to each method that may utilize dependency injection, or is there some way to make the container globally accessible so that you can register them all together in the beginning and access them throughout running the application without having to continually pass them, and be able to utilize them when ever needed?
Environment: Visual Studio 2015, C#, Microsoft Unity (for DI Container)
Example Code
static void Main(string[] args)
{
// Make Unity resolve the interface, providing an instance
// of TrivialPursuit class
var diContainer = new UnityContainer();
diContainer.RegisterType<IGame, TrivialPursuit>();
var gameInstance = diContainer.Resolve<IGame>();
var xotherClass = new AnotherClass();
xotherClass.TestOtherClassOtherMethod();
}
------ Another class without context of the Dependency Injection Class ------
public void TestOtherClassOtherMethod()
{
IGame gameInstance = -- -Container is Not available to resolve from in this class ---
}
Reason: I don't want to need to pass every possible type that I may need later on to each class I load up, I will just want to use the instances when I need them. The more deeper I get into classes, later as the application becomes more complex, I won't want to pass down instances for each type up from the Main() method to each class.
A Dependency Injection (DI) container is just that. A framework for facilitating DI. You don't pass the container around in order to resolve instances of objects. You just request the type you need in your classes constructor and the DI framework will inject the appropriate dependency.
Mark Seemann has written a good book on dependency injection that I would recommend.
You register everything that'll need to be resolved with the container in the composition root. That is to say when your program starts up is when everything should be registered.
Let's say we have the following code:
public class MyClass
{
public Run()
{
var dependency = new Dependency1();
dependency.DoSomething();
}
}
public class Dependency1
{
public void DoSomething()
{
var dependency = new Dependency2();
dependeny.DoSomethingElse();
}
}
public class Dependency2
{
public void DoSomethingElse()
{
}
}
This gives us the above dependency chain: MyClass -> Dependency1 -> Dependency2.
The first thing we should do is refactor the classes to take their dependencies through their constructor and rely on interfaces rather than concretions. We can't inject dependencies unless there is a place to inject them (constructor, property, etc).
Here is the refactored code:
public interface IMyClass
{
void Run();
}
public interface IDependency1
{
void DoSomething();
}
public interface IDependency2
{
void DoSomethingElse();
}
public class MyClass : IMyClass
{
public readonly IDependency1 dep;
public MyClass(IDependency1 dep)
{
this.dep = dep;
}
public void Run()
{
this.dep.DoSomething();
}
}
public class Dependency1 : IDependency1
{
public readonly IDependency2 dep;
public MyClass(IDependency2 dep)
{
this.dep = dep;
}
public void DoSomething()
{
this.dep.DoSomethingElse();
}
}
public class Dependency2 : IDependency2
{
public void DoSomethingElse()
{
}
}
You'll notice the classes now all take their dependencies through their constructors and do not new up anything. Classes should only take in dependencies that they actually need. For example, MyClass does not NEED a Dependency2 so it doesn't ask for one. It only asks for a Dependency1 because that's all it needs. Dependency1 NEEDS Dependency2, not MyClass.
Now to wire it all up WITHOUT a container we would just new it all up in the composition root:
void Main()
{
var myClass = new MyClass(new Dependency1(new Dependency2()));
}
You can see how that could get cumbersom if we had tons of classes and depdencies. That's why we use a container. It handles all the depdency graph for us. With a container we'd rewrite it as follows:
void Main()
{
// the order of our registration does not matter.
var container = new Container();
container.Register<IDependency1>.For<Dependency1>();
container.Register<IDependency2>.For<Dependency2>();
container.Register<IMyClass>.For<MyClass>();
// then we request our first object like in the first example (MyClass);
var myClass = container.Resolve<IMyClass>();
myClass.Run();
}
In the second example the container will handle wiring up all the dependencies. So we never need to pass Depedency2 to MyClass and then to Depedency1. We only need to request it in Dependency1 and the container will wire it up for us like in the first example.
So in your example we would rewrite it like so:
static void Main(string[] args)
{
var game = new UnityContainer();
game.RegisterType<IGame, TrivialPursuit>();
game.RegisterType<IAnotherClass, AnotherClass>();
game.RegisterType<IYetAnotherClass, YetAnotherClass>();
var gameInstance = game.Resolve<IGame>();
// you'll need to perform some action on gameInstance now, like gameInstance.RunGame() or whatever.
}
public class Game : IGame
{
public Game(IAnotherClass anotherClass)
{
}
}
public class AnotherClass : IAnotherClass
{
public AnotherClass(IYetAnotherClass yetAnotherClass)
{
}
}
public class YetAnotherClass : IYetAnotherClass {}
In these cases there is no need to pass the container around. You register your dependencies with the container then request them in your classes constructors. If you wish to use the container in the class WITHOUT requesting it through the constructor then you are not doing DI you are just using the container as a singleton service locator. Something that should generally be avoided.
Container as a Service Locator
This should be generally avoided but if you want to use the container as a service locator you have two options:
1) Pass the container into your classes that need it through the constructor.
You can use the above examples for wiring your classes up for DI. But instead of requesting a dependency like IDependency in the constructor you just pass the container.
public class Game : IGame
{
public Game(IContainer container)
{
var blah = container.Resolve<IBlah>();
}
}
2) Request your container through a static class:
public static class ServiceLocator
{
private static IContainer container;
public static IContainer Container
{
get
{
if (container == null)
{
container = new Container();
}
return container;
}
}
}
Register everything as normal in your composition root using the ServiceLocator class. Then to use:
public class MyClass
{
public void DoSomething()
{
var blah = ServiceLocator.Container.Resolve<IBlah>();
}
}
So I have windsor set up and all of my services registered. I have a class that requires these services in the ctor, but this class isn't registered with windsor as it does not have an interface and I don't want to give it one for the sake of dependency resolution. What I'm really interested in, is having windsor resolve and inject my registered dependencies and hand me back an initialized class -- basically a factory.
The problem that I'm running into is that windsor throws because the dependent class has not been registered:
void Main()
{
var container = new WindsorContainer();
container.Register(Component
.For<ITestInterface>()
.ImplementedBy<TestImpl>()
.LifestyleTransient());
var c = container.Resolve<TestClass>(); // throws because TestClass isn't registered
c.Run();
}
public class TestClass
{
private ITestInterface _d;
public TestClass(ITestInterface d)
{
_d = d;
}
public void Run()
{
_d.Do();
}
}
public interface ITestInterface
{
void Do();
}
public class TestImpl : ITestInterface
{
public void Do()
{
Console.WriteLine("done");
}
}
What I don't want to end up doing, is something like this:
var dependency1 = container.Resolve<ITestInterface>();
var c = new TestClass(dependency1);
c.Run();
Because now we're in service locator territory. But more importantly, classes that have several dependencies...well that could get tedious.
How can I get windsor to have the desired factory effect? Or is this even possible with Windsor? I recall this being possble with Ninject.
So the popular response seems to be "Just register the component" which I really don't like at all because for such a simple use case, I could end up with a config class with hundreds of unnecessary registrations. That's kind of silly. So in the meanwhile, until I discover some built in functionality for this, I've create a cheesy extension that should land me somewhere in the middle. This extension simply takes the type, registers it for you and then tries to resolve it. That way, it's leveraging Windsor's own ctor resolution logic:
public static class WindsorExtentions
{
public static T Construct<T>(this IWindsorContainer container)
where T : class
{
if (!container.Kernel.HasComponent(typeof(T)))
container.Register(Component.For<T>());
var instance = container.Resolve<T>();
return instance;
}
}
What I would really like to do is register it, resolve it, then unregister it, but it appears that the RemoveComponent method has been removed in 3.0. This should be fine in the meanwhile. It obviously isn't all-inclusive with use cases, but when you have loads of proxy classes that have several required dependencies to be injected, I think this helps.
Usage:
var myClassWithDependencies = myContainer.Construct<MyClassWithDependencies>();
public class MyClassWithDependencies
{
public MyClassWithDependencies(
IFacebookClient facebookClient,
IGooglePlusClient googlePlusClient,
ITwitterClient twitterClient,
ISalesforceClient salesforceClient,
IReportRepository reportRepo,
IUserRepository userRepo)
{
}
}
I have a Castle Windsor container registration class as follows...
public class WindsorInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(Component.For<IConfigProvider>()
.ImplementedBy<ConfigProvider>()
.LifeStyle.Singleton);
container.Register(Component.For<IDbRepository>()
.ImplementedBy<DbRepository>()
.LifeStyle.Singleton
.DependsOn(Dependency.OnValue(
"connectionString",
// -- Somehow call GetConfig() on the IConfigProvider --
)));
}
}
The DbRepository needs a connection string to be passed in on object construction. However, that connection string is actually supplied by the IConfigProvider.
Is it possible to get Castle Windsor to somehow resolve the IConfigProvider at this point and call the GetConfig method?
Open to other options if this is not a good idea.
You could use DynamicParameters to accomplish this:
container.Register(Component.For<IDbRepository>()
.ImplementedBy<DbRepository>()
.LifeStyle.Singleton
.DynamicParameters((k,d) =>
{
var configProvider = k.Resolve<IConfigProvider>();
d["connectionString"] = configProvider.GetConfig();
}
)));
From the documentation:
DynamicParameters works with a delegate which is invoked at the very beginning of component resolution pipeline.
In other words, you'll retrieve the connection string just before the component is resolved.
you might wanna checkout castle Windsor's typed factory facility.
https://visualstudiomagazine.com/articles/2011/12/01/windsor-beyond-dependency-injection.aspx
Edit:
Here's an example of exactly what you want to do..
http://joseoncode.com/2011/01/09/windsor-isubdependencyresolver-example/
Implement AbstractFacility which will resolve your connection string
public class DependenciesFromAppSettings : AbstractFacility
{
protected override void Init()
{
var dic = ConfigurationManager
.AppSettings
.AllKeys
.ToDictionary(k => k, k => ConfigurationManager.AppSettings[k]);
Kernel.Resolver.AddSubResolver(new DependenciesFromAppSettingsResolver(dic));
}
}
Implement ISubDependencyResolver
public class DependenciesFromAppSettingsResolver : ISubDependencyResolver
{
private readonly IDictionary<string, string> webConfig;
public DependenciesFromAppSettingsResolver(IDictionary<string, string> webConfig)
{
/// you can pass in your configprovider object here (or similar)
this.webConfig = webConfig;
}
public bool CanResolve(Castle.MicroKernel.Context.CreationContext context,
ISubDependencyResolver contextHandlerResolver,
Castle.Core.ComponentModel model,
Castle.Core.DependencyModel dependency)
{
//make sure your connectionstring has value
}
public object Resolve(Castle.MicroKernel.Context.CreationContext context,
ISubDependencyResolver contextHandlerResolver,
Castle.Core.ComponentModel model,
Castle.Core.DependencyModel dependency)
{
//resolve your connectionstring here
}
}
Your repos looks like as follows:
public class MyRepo
{
public MyRepo(string connectionString)
{
}
}
Your castle Windsor container will look like as follows (i.e. adding facility):
IWindsorContainer container = new WindsorContainer();
///Register your ConfigProvider here
container.AddFacility<DependenciesFromAppSettings>();
container.Register(Component.For<MyRepo>());
Note the code is borrowed from above link.
Hope this helps
I am trying to avoid the anti-pattern of Container.Resolve(). How do I change the following to use contructor injection?
Installers.cs
public void Install(Castle.Windsor.IWindsorContainer container,
Castle.MicroKernel.SubSystems.Configuration.IConfigurationStore store)
{
container.AddFacility<TypedFactoryFacility>();
container
.Register(Component.For<IData>()
.ImplementedBy<Data>().LifeStyle.Singleton)
}
BootStrapper.cs
public class Bootstrapper
{
private static volatile IWindsorContainer _theWindsorContainer;
private static object syncRoot = new Object();
public static IWindsorContainer Container
{
get
{
if (_theWindsorContainer == null)
{
lock (syncRoot)
{
if (_theWindsorContainer == null)
{
_theWindsorContainer = new WindsorContainer().Install(FromAssembly.This());
}
}
}
return _theWindsorContainer;
}
}
}
OViewModel.cs
public IData ThisData {get;set;}
public OViewModel()
{
ThisData= Bootstrapper.Container.Resolve<IData>();
InitializeComponent();
}
How do I use Windsor Castle constructor injection to initialize the viewmodel and do constructor injection? Either InitializeComponentdoesn't get called or ThisData is null.
I wrote an article a few years ago about integrating Castle Windsor into WPF to achieve DI in your view models. It might be what you're looking for.
I'm not familiar with the particulars of Castle Windsor, but typically you would structure your OViewModel like this:
public class OViewModel
{
public IData ThisData { get; set; } //private set??
public OViewModel(IData _thisData)
{
ThisData = _thisData;
InitializeComponent();
}
}
That would be constructor injection. You can search for the term parameter injection for other ways of getting it done.
But basically the when an OViewModel is resolved by the container, it knows how to resolve an IData and will automatically resolve it for you.
Of course, this just backs things up -- whatever is creating the OViewModel needs to use container.Resolve and you don't want to do that. So you'll probably inject the view model (or an interface of it) (or a factory object) to that parent object. And so on back up the chain until you have single object that is the root of your application that you need to resolve from the container to get everything started.
Hopefully someone with more knowledge of the particulars of Castle Windsor can give you more details.