Do you use IOC containers/Dependency Injection Frameworks?

N

nfbs

Expert Member
Joined
Jul 15, 2008
Messages
3,296
Reaction score
6
I am interested to know if other devs in SA are using IOC containers/Dependency Injection Frameworks and if so which ones
 
nfbs said:
I am interested to know if other devs in SA are using IOC containers/Dependency Injection Frameworks and if so which ones
Click to expand...

Ye for sure, it's an extremely important pattern when it comes to unit testing and being able to mock classes. It's a widely used pattern in the Laravel framework, which we recently switched to at work. Another key benefit is being able to easily swap out components after the fact, ie: if we switch SMS gateways, we can just tell our IoC container to instantiate a Clickatell library as opposed to a PanaceaMobile.

So ye, thumbs up to IoC containers and dependency injection :)
 
Spring framework is widely used pretty much everywhere in the world (including SA).

Any Java developer with experience that hasn't used it yet is behind the industry IMO.
 
Last edited:
As mention, in java, springframework and JavaEE make extensive use of DI via IOC. It's main advantage is the complete abstraction of all implementations from each other, and the ability to easily change, via configuration, what implementation is used
 
Use Ninject on one project, AutoFac, and currently using Funq(heavily modified thou) on a personal one.
 
Absolutely.

Unity inside PRISM is the flavour i'm familiar with.
 
nfbs said:
What do you use?
This shows some performance compared but most devs won't choose the best performance container.

Unity seem to be the most popular but it's hard to choose for.net since there isn't one that has become the standard
Click to expand...

Dont really use .NET di containers on our asp.net project. Because our asp.net project is built entirely with angular.js
 
sp4ceman said:
we use it in a website. there are so many more places to worry about perf than our di injector. a millisecond or 10 is negligible
Click to expand...

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.
 
semaphore said:
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.
Click to expand...

I'm confused, how does it add up?

Most of the IoC cost is at bootstrapping. Once your objects are wired up correctly, it is just like any other application.

Maybe the .NET implementation is different...
 
Gnome said:
I'm confused, how does it add up?

Most of the IoC cost is at bootstrapping. Once your objects are wired up correctly, it is just like any other application.

Maybe the .NET implementation is different...
Click to expand...

Resolving instances of said wired objects. Wiring up is done at bootstrap, resolving is not and i'm referring to the resolving mechanisms not the initial bootstrapping.

But my point is that why use something that is slower than something else, that offers better if not more functionality...
 
semaphore said:
I would rather drink camels piss than use Unity.
Click to expand...

jeanres said:
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
Click to expand...

que?

What's so bad about Unity? Using it in a WPF application, and haven't even considered why it could be a problem or what we're missing out on. Was part of the guidance on PRISM, so just went with it. Don't have particularly strong feelings about it.

Pro's / Cons? What am I missing out on?
 
semaphore said:
Resolving instances of said wired objects. Wiring up is done at bootstrap, resolving is not and i'm referring to the resolving mechanisms not the initial bootstrapping.

But my point is that why use something that is slower than something else, that offers better if not more functionality...
Click to expand...

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...
 
Gnome said:
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...
Click to expand...

I'm not sure what kind of code these guys are writing that they are considering the cost penalty of DI being a factor. What am I missing here? Are people really using it to instantiate millions of view models every few seconds without doing much processing in those classes? Every way I look at it, the % load of DI compared to other tasks performed per DI operation is incredibly small.

If you are looking at scale, registering thousands of transactions for thousands of users, then your percentage DI processing is still the same and you will need to scale the system according to the operations that use the majority of the processing time in any case.

How is the DI performance anything but a sideline consideration in an application? What am I missing here?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X