I have interface (e.g. IMyInterface). I need to get of which type object will be created if I call kernel.Get<IMyInterface>(). Not the instance of IMyInterface but the type of instance without creating instance itself. Is it possible?
Ninject doesn't have this functionality. From a Ninject IKernel (like StandardKernel) you can call GetBindings(Type) but Ninject uses a provider model, so the binding's provider has to be invoked to view the result.
I would suggest creating a custom meta-service to mappings of services to implementations, if this functionality really needs to be dynamic.
Related
I would like to know in best practice questions and think of easily testable classes, when I need multiple different instances of the same (fabricated) object within a specific class, which approach is recommended?
Before I used the Service Manager build method, but it is no longer recommended to inject Service Manager directly into a class, right?
i have a little problem using doctrine 2 in Zend Framework 2 i have custome class that i use to manipulate doctrine generated model (basically to inject data and populate), to make that work i need the entity manager which is available through the service manager as indicated in Jason Grimes tutorial here http://www.jasongrimes.org/2012/01/using-doctrine-2-in-zend-framework-2/.
In his tutorial it works (i tested it) as the ServiceLocator is called from a controller class, but for the application i am writing i have to use custom (non controller) classes to interact with the entities. How do i achieve this? Using the servicelocator from a custom class that is not a controller? Thank you all in advance
You need to do two steps
Implement Zend\ServiceManager\ServiceLocatorAwareInterface in your custom class. This allows to the Framework to inject the Service Locator for you.
Convert your custom class to a service and retrieve it using Service Manager. This component will check if the class implement ServiceLocatorAwareInterface and the inject the ServiceLocator before returning to you the instance
In Caliburn.Micro documentation the authors mention such possibility:
documentation link
IHandle inherits from a marker interface IHandle. This allows the use of casting to determine if an object instance subscribes to any events. This enables simple auto-subscribing if you integrate with an IoC container. Most IoC containers (including the SimpleContainer) provide a hook for being called when a new instance is created. Simply wire for your container’s callback, inspect the instance being created to see if it implement IHandle, and if it does, call Subscribe on the event aggregator.
How is it possible to achieve this with MEF?
This question is the same as Caliburn.Micro. Automatically call eventaggregator.Subscribe() for IHandle implementors with Autofac
So how is similar functionality as the described AutoSubscribeHandersModule implemented in MEF?
I blogged about how to do the auto-wiring for the Event Aggregator with MEF in Caliburn Micro here;
http://www.kjetilk.com/2011/10/auto-wiring-eventaggregator.html.
In short; You need to add the MEFContrib (nuget -> Install-Package MefContrib), implement an IExportedValueInterceptor that subscribes any IHandle instances, and plug the interceptor into the MEF creation pipeline using an InterceptionCatalog in the bootstrapper.
Check MEFContrib's InterceptingCatalog. Just put IHandle instead of IStartable as described in the referenced article.
I've read a couple of articles about creating a generic repository in Entity Framework. In every article the ObjectContext is passed as an argument to the constructor like this:
public Repository(ObjectContext context)
{
_context = context;
}
In a web application the preferred way to handle ObjectContext lifestyle is per web request. This means that these repositories must also have lifestyle per web request, if used in in a web context. This spreads to services using repositories and further on if we stick to constructor injection...
I think the ObjectContext life cycle should be handled outside the repositories, for example in a HttpModule. I would also like to handle repositories as singletons instead, and then ObjectContext can't be injected in the constructor. Another mechanism for getting the ObjectContext into the repository must be used, like an ObjectContextFactory.
Whats the downside of handling the repositories with a singleton lifestyle?
One issue with repositories being singletons, as with any other objects, is that determining what dependencies the repository has becomes more difficult. When you require that a context is passed in the constructor that is a clear declaration of a dependency on the ObjectContext class. If you were to use a static factory to get a reference to an object context then it would be necessary to see the implementation of the repository to know how it uses the factory.
A common way to achieve what you're looking for, namely the ability to manage the scope of the ObjectContext class outside of the repository is by using a dependency injection library, such as Autofac. You can register the ObjectContext class such that a new instance is created for every HTTP request. Then if you also register the repository class, when a repository is requested the dependency injection container will attempt to get a reference to the ObjectContext dependency. Since only one instance of ObjectContext will be created per HTTP request multiple repositories within that scope will receive the same instance. The Autofac page has example of integrating with ASP.NET that you can look at.
I am migrating to ASP.NET MVC 3.
Now I have some ways of resolve controller with IoC.
My controller need a contructor injection parameter for repositories.
Setting DependencyResolver.SetResolver works. But I don´t know if this is correct way or I need to Register a IControllerActivator at my container too.
What you need is a ControllerFactory.Most IOC containers have an existing implementation. If you need a custom one, check this article:
http://develoq.net/blog/?p=144
Update
It's the correct way. DependencyResolver is generic for everything, and you need to register the IControllerActivator in it.
http://bradwilson.typepad.com/blog/2010/10/service-location-pt10-controller-activator.html