In the README.md of the FreshMVVM repo it is explained which interface has to be implemented to use any other IoC container besides the built-in version of TinyIoC.
Is there anyone here who already created a implementation for DryIoC and get it to work properly? I'd know how to implement the functions like Register<RegisterType, RegisterImplementation> and Resolve<RegisterType>, but besides that I'm more or less lost. Also it seems that if I use a custom IoC container implementation pages and their viewmodels cannot be resolved without explictely registering them in the first place. This is not necessary with the built-in container.
Related
I'm using AutoMappper 5.2 in my MVC project. I have made use of IMapper creating profiles which I understand profiles are a way to organise mappings. I am injecting IMapper into my controllers using Simple Injector to register an instance.
What I would like to know is can you use them in a way where you only retrieve/set up the profile you need for a specific controller? If so, how would you go about that? If you have to add all the profiles into one mapping configuration object does that have a performance impact or is it marginal?
I cannot find any resources or questions that deals with using a specific type of profile, they only deal with creating and registering them.
I think my answer to a similar question might help you. It is the last answer here: How to register AutoMapper 4.2.0 with Simple Injector.
It's basically what Steven said.. you need to create a generic profile wrapper that implements the IMapper interface, with the generic argument being a specific profile. This allows you to create any number of profiles, batch-register them all, and to inject only the one that you need in your controller:
ProfileMapper<ApplicationProfile> appProfileMapper;
ProfileMapper<MvcProfile> mvcProfileMapper;
ProfileMapper<GuestProfile> guestProfile;
I want to integrate vaadin 7 with osgi but there is no longer any AbstractApplicationServlet class.
I've followed the integration using the vaadin bridge by Neil Bartlett https://github.com/njbartlett/VaadinOSGi.
I've tried using the VaadinServlet somehow but with no luck.
I've also searched for other solutions but found none.
Do you have any suggestions?
Thanks
Vaadin 7 has a lot of design changes that are not visible for default use cases, but especially for OSGi integration you have to do some extra work.
To get you started you should try to understand the initialization process concerning the classes:
VaadinServlet, VaadinServletService, VaadinSession and UIProvider.
The problematic parts are the methods that use classname parameters as arguments, you will have to work around this by e.g. implementing a factory that directly injects your instances.
If you look at the source for UIProvider.createInstance(..) you can see that the original implementation tries to create a new instance, this will fail since vaadin does not see your classes in OSGi. The same principle applies for the other classes i mentioned as well.
Another thing you have to look at is the new separation of jars in Vaadin 7.
A good approach is to attach a bundle fragment with a blueprint context. that registers a BundleHttpContext the same way it worked in Vaadin 6. Attaching fragments also works for the themes you want to use.
Sorry that i can't provide a turnkey solution, but i hope this helps you to look into it yourself.
I have seen this line of code in several tutorials for using Unity in asp.net mvc3. I was under the impression that Service Locator is an anti-pattern and not best practice. Is this Service Locator something other than the anti-pattern defined, or is this line of code / this implementation considered bad practice.
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
Old question, but for the benefit of others:
While I absolutely agree with the mantra "Service Location is an anti-pattern", there are definitely exceptions to that rule.
When you use Dependency Injection (like Unity) then, yes, certainly don't use ServiceLocator and only use constructor injection for all your service classes. (Also don't use "new" for anything other than value objects like DTOs.)
However, there are cases where you simply can't use constructor injection and then the only way to get access to a service is to use a workaround to access your Unity container directly, and in such cases, ServiceLocator is a good standard way to accomplish that. This is the case when the class isn't instantiated by you (or more specifically, it isn't instantiated by Unity) but by the .NET framework for example.
A few simple examples of where ServiceLocator might be useful, is to get access to services registered in your Unity container from:
an implementation of a WCF IEndpointBehavior or IClientMessageInspector
an implementation of a WPF IValueConverter
or you may not necessarily even want to get access to "services" from the class, but you simply want to write code that is unit-testable, but for some reason the class can't be instatiated at all (or not easily) because it would normally be constructed by the .NET Framework, so you extract your custom code into a class that is testable, and resolve it in the non-testable class using the ServiceLocator.
Note that this line is not ideal:
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(Container));
The ServiceLocator.Current property is going to execute the delegate provided every time you access Current, i.e. a new UnityServiceLocator is going to get created every time. Instead, you probably want to do this:
IServiceLocator locator = new UnityServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => locator);
If you create a framework which is designed to be container agnostic the service locator (although it should be a No-Go in an application) is an additional layer of indirection that allows you to swap out Unity for something different. In addition the use of the service locator does not enforce the use of DI for applications that use that framework.
It is the same anti-patten that people talk about. All that line is doing is setting the service locator provider to be an instance of UnityServiceLocator, i.e. to use the Unity implementation of the ISerivceLocator. Optionally if you would like you can have your own implementation is IServiceLocator and use that instead of UnityServiceLocator.
Using Service Locator is considered a bad practice for various reasons as listed here
Can anyone shed some light on the advantages and disadvantages of using a custom ActionInvoker like so to perform dependency injection on custom ActionFilters as opposed to using a custom FilterProvider as demonstrated here?
In both cases you are going to still want to avoid constructor injection on your ActionFilters, and to me it seems that all the custom FilterProvider does in this case is adds additional overhead of having to register your ActionFilters and the provider in your container.
The big advantage of filter providers is that it allows constructor injection if done right. The example you linked does not demonstrate this correctly. To use constructor injection you can not use filter attributes. Instead you have to separate the two things the declaration that you want to apply a filter (e.g. using an attribute) and the filter implementation.
I'm not sure if there is a good implementation for Unity. See on http://www.planetgeek.ch/2010/11/13/official-ninject-mvc-extension-gets-support-for-mvc3/ how it could feel like. But this is a Ninject example. Probably you can take its implementation on github and port it to Unity.
I was just starting to get comfortable with MVC when somebody mentioned IoC containers to me, and now I feel like I've fallen a few thousand feet and need to climb back up again. I was tempted to just ignore them, but then I read up on the Component Lifestyle. This seems like a big deal to me, as explained, uncommited changes to database updates might leak across requests if my repositories Lifestyle is set to Singleton instead of PerWebRequest.
So my question...is there a way to create the Component Lifestyle affect without using IoC containers, or is that the only option?
You can always create an implementation as a Singleton. However when speaking about a Repository I don't think there is a need. This is not the real purpose to using an IoC though. Using the IoC decouples the user of your code from the implementation itself. It makes testing easier as you can swap things in and out as you need too. Also, in my case I find it very useful for other purposes as well. Take caching for example. In my local dev I use Lucene.NET to provide my cache implementation with a disk based cache. Then when I push to my development and staging platforms I use the standard .net cache implementation. Then when I push to production I might use a Velocity or MemCached implementation. I don't have to do anything fancy to get from point A to point B since I am using StructureMap (my preferred IoC container).
It seems to be that Component Lifestyle is more of a design decision than an IoC decision. All three of the methods mentioned here for managing the life of an object can be done without IoC...but that might be an interesting side effect of an IoC (in some cases).