Do you use IOC containers/Dependency Injection Frameworks?

Again, IoC implies using interfaces in your implementations. You have DI inject concrete implementations that implement the interfaces.

During startup DI can have quite a high penalty. However as soon as that is done, each object has a reference to the concrete implementation chosen at startup time.

Not sure where the runtime cost is...

You do know that different containers resolve instances differently?. What you state is THEORY but that does not necessarily mean that every framework adheres to said THEORY precisely. Thus some containers resolve instances faster than others. Perhaps in the java world you have a single framework for this but like most .NET libraries there are about a billion alternatives.

Obviously the container must know about interface/concretes etc, but what i am pointing out is that PRISM/Unity is SLOW in comparison to the other DI containers out there. If you wanna use MVVM for WPF rather go with caliburn micro. Not to mention Unity is XML configured (the last time i played with it).

Anyways enjoy deploying 50gigs of dlls with your app for the enterprise patterns. :D
 
Last edited:
but what i am pointing out is that PRISM/Unity is SLOW in comparison to the other DI containers out there.

What i'm trying to understand is how dependency injection performance between these frameworks is even an issue, let alone bringing camel piss into the equation. What code are you writing that you need to consider DI to be a large influencer of performance?

If you wanna use MVVM for WPF rather go with caliburn micro.

Yes, another MVVM framework, great, but what DI injector would you use with it?

From their site: "Use any dependency injection container". I'm looking into Caliburn now (seems like a decent framework, would like to spend some time playing with it) but it doesn't do any of the dependency injection from what I can tell. You still need a dependency injector. Of all the blog posts i'm reading now, seems a lot of people using Caliburn revert to using Unity for the DI.

Not to mention Unity is XML configured (the last time i played with it).

I don't use any XML for unity. Nor for PRISM actually. It can prove useful, but I don't. Either way, not sure why that would even be an issue. If you want more flexibility, XML configuration is really helpful. Why would that even be an issue?

Anyways enjoy deploying 50gigs of dlls with your app for the enterprise patterns. :D

If by 50gigs you mean 122KB for the Unity dll (or 1.61MB for PRISM and Unity combined), then sure.
 
ROFL, Unity is pretty crap in my opinion.

A old but still relevant article on IoC Containers

http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison

Still waiting for some more backing to this comment. Come on, you've got me on the cusp of changing frameworks here. Semaphore has even got me reading up on another MVVM framework. Bring it home... show me why Unity is crap. I want to make the change to that awesome DI container you are pushing me towards, but I need something to go on!

What's crap about Unity? What would you suggest instead. Benefits / Drawbacks. Pros / Cons. Give me something dammit, don't leave me hanging here! Show me the way forward!
 
Its hardly a millisecond, and if you start building high traffic websites with thousands of people those "milli" seconds start adding up very fast. Very narrow minded thinking imo.

well you're typing it who else's opinion would it be? at the time i wrote the system ninject was pretty much the only non XML based ioc i could find.

and it was fast at the time compared to whatever else existed.

like i said its not the bottleneck worth looking at. if a million people go to my site tomorrow my db and webserver will fall over long before my ioc.

go for the seconds before milliseconds.
 
Ninject, I only use it because that was what I started with when going through .Net MVC tuts. I'm sure there are other DI's but Ninject works fine and I'm not too worried about min/maxing.
 
I started using Autofac. Just yesterday I started seeing limitations with it's use in Windows Forms and had to scrap it's use but will use it more for other project types in future.
 
Take back what I said, works with Unity.

C#:
public class UnityResolver
{
    protected IUnityContainer container;

    public UnityResolver(IUnityContainer container)
    {
        this.container = container ?? throw new ArgumentNullException("container");
    }

    public object GetService(Type serviceType)
    {
        try
        {
            return container.Resolve(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return null;
        }
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        try
        {
            return container.ResolveAll(serviceType);
        }
        catch (ResolutionFailedException)
        {
            return new List<object>();
        }
    }
}

C#:
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
    IUnityContainer container = new UnityContainer();
    container.RegisterType<IAuthorRepository, AuthorRepository>();

    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(container.Resolve<FrmAuthors>());
}

Then on the form.

C#:
private IAuthorRepository _authorRepository;

public FrmAuthors(IAuthorRepository repository)
{
   _authorRepository = repository;
  .
  .
  . Peanut Butter Jelly Time
  .
  .
}
 
Last edited:
Top
Sign up to the MyBroadband newsletter
X