I'm wondering if the IoC Container should be referenced only by the class that instantiates and configures it, or if it can be injected into other classes, VMs and VML for example. I'm asking because i saw many people pass it through the ViewModelLocator's construtctor and use it from there.
Is this approach acceptable or to be avoided?
Thank you very much.
You are correct - passing container is Doing it Wrong since it goes against the whole Inversion of Control idea. Here's a few links for you:
Here's how I use IoC containers (and part 2)
I also recommend checking out Windsor's documentation, especially Concepts section which is quite universal (and will be useful to you even if you're not using Windsor).
Related
All the articles and papers about this subject, provide overly simplistic examples. The concepts are easy to understand. However, without substantial experience (both myself and my teammates) in this subject, it is not trivial to map the concepts to actual design decisions in a real life system. No way to validate my architecture.
Can anyone provide me with a real system implementation, that correctly implements IoC.
Note: I am not talking about dependency injection. I'm currently using a container, and I use system wide injection. I am more interested in the way code is kept decoupled, i.e., how is library separation performed (to what extent), and how and where is the interface/contract code declared and included.
Thanks
The open-source GlassFish application server (https://glassfish.java.net/) uses hk2 (https://hk2.java.net) as a DI container. It has several areas where implementations are kept separate from contracts, and where in fact implementations of those contracts can be dynamically added or removed while the server is up and running.
For example take a look at the command-line (asadmin) facility. Users can deploy OSGi bundles that can add new implementations of the command-line contract which will then dynamically be added to the set of things asadmin can do. This is a good example of how to use IoC in order to keep your contracts and services separated.
It is also instructive in that GlassFish was not originally designed with a DI container, so it is a good real-world use case for how to add DI/IoC into systems that were not originally designed in that way.
I have a relatively basic question but more than anything just need some clarity really, I have been using Prism (Composite Application Guidance) to create a WPF MVVM desktop application in C#, this bit I am all clear about (or so I thought) along with IoC and Module based architecture etc. At the same time I have started using MEF and realise that there is a kind of grey area between the two (I have found and read a number of articles/blogs on hosting MEF Extensions in IoC containers and the like.
However....recently I have started looking at Enterprise Library 5 and this is whats led to my confusion. Where do they all fit together? So Prism uses DI with a Module based architecture... EntLib uses Di with an Application Block type architecture... and MEF doesn't use DI at all? Does this mean that EntLib and Prism are entirely separate architectual methods or that one is a subset of the other? Also could MEF be used with either/both?
Any explanation would be most welcome.
Many thanks
I, too, was puzzled by the difference between IoC and MEF. The simplest way I found to describe them, was this:
MEF is for discovering and instantiating something you don't know about.
IoC is for requesting something you do know about.
A little bit of context. MEF will always instantiate the import that you request at least once. You are not capable of creating it yourself, and putting it into the catalogue ready to be used. MEF is responsible for creating and satisfying the imports. Dynamically loaded DLLs, where you don't know which DLLs are arriving, is a good example.
IoC on the other hand - you request an implementation from the current library, and you are given one. But you are also responsible for ensuring that an implementation exists.
IoC is for dependency injection. MEF is for extensibility.
Take a look at these 2 posts:
Should I use MEF for my general IoC needs?
Prism and MEF
As to Enterprise Library, in v5.0 we've made it container-agnostic. Even though Enterprise Library ships with Unity container out-of-the-box, it is architected to work with any container of your choice or MEF. You do need to provide an appropriate configurator (see info on configurators at the end of this summary)
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.
Using a IOC container will decrease the speed of your application because most of them uses reflection under the hood. They also can make your code more difficult to understand(?). On the bright side; they help you create more loosely coupled applications and makes unit testing easier. Are there other pros and cons for using/not using a IOC container?
If you're using an IOC container in a simple fashion, reflection is only used on startup - the application is wired up to start with, and then it runs as normal without any intervention from the container. Of course, if you're using the IOC to resolve dependencies after you've started running, that may be slightly different - although I'd still expect it to resolve lazily and cache unless you've got it configured to create new instances each time.
As for making the code harder to understand - quite the reverse! With the dependencies explicitly stated, it's much easier to understand each component, and the configuration file(s) make it clear how the whole application hangs together.
Well I suppose a con I've experienced is that some developers don't seem to be able to grasp IoC. We've had a few people who were against it for no reason other than that they didn't understand them. (Not saying that's a bad reason to be against something, not at all.)
It does add a bit of abstraction that always seems to manage to confuse someone or other, but I'd say the pros far outweigh the cons in most cases.
I think it is fair to say if you have expert understanding of how to use IOC and tend to write good code anyway, then IOC will make your code easier to understand on all but the smallest systems.
However if you are working somewhere where most classes/methods are very large and the concept of refactoring has not yet taken hold, then trying to use an IOC is likely just to make the software harder to understand. The IOC also has to be leant by everyone that programs on the project, so that may be a consideration.
I see IOC as icing on the cake; I like the icing but only on a nice cake. If the cake is not nice to start with, sort out the cake first.
As to the performance overhead of using IOC, I don’t see this as a problem in most cases. The overhead need not be large, and given the speed of today’s CPU most of you run time is likely to be data access anyway. If a IOC proved to slow for a given bit of code I would look at adding some caching of returned object, or removing the IOC just from that bit of code.
I believe the assumption about reduced execution speed is much the same kind of argument as "C is faster than C#/Java". While this statement may be true for specific operations and/or structurally simple tasks it is not the case the moment complexity rises.
The way DI-frameworks let you focus on object creation and dependencies creates more efficient systems when code size increases. For large applications I'm almost certain DI-framework based code will outperform any alternative solution. There's simply so little redundancy in the runtime that it's hard to make it more efficient! Most of the additional overhead is also just at first load.
Advanced DI containers also lets you do "scope" magic that you can only dream of without the container. Using scope-proxies, spring can do the following:
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
Effectively you can have ten layers of singleton objects and all of a sudden something session scoped shows up.
Stuff like security can be injected in totally different manner than you would otherwise. There's often a classical paradox: Often the GUI layer needs to have intricate knowledge of the security permissions. Quite often the services layer also needs this, but often at a different level of detail (usually less detailed than the gui). The classical approach would be to send it around as parameters, put it on a threadlocal or to ask a service. With spring you can just inject it straght where you need it and no-one else needs to know.
This actually changes application development as a whole. I had a real hard time adjusting to this, but after this pain I see it is truly a lot closer to how things should be (as opposed to how we've learned to do it).
So I think DI frameworks have the potential of changing the way you make programs, with much further reaching implications than just DI. It's not just a glorified way of calling new.
I agree with all the answers so far.
What I'd like to add, is that it creates a bit of overhead, so it isn't really suited for small applications.
Mid-size and larger applications benefit the most from using IoC.
You might also check out this question for more information on pros and cons: Castle Windsor Are There Any Downsides?
In most circumstances you would not even notice performance penalty since for "singleton" objects all the initialization is performed once only. I would also argue that IoC makes it different to understand the code: on the contrary, IoC-style development forces you to create small coherent classes, which are in turn easier to grok.
If you are writing a business application, using an inversion-of-control and dependency-injection container (in conjunction with other agile practices and tools) will help you out in terms of productivity and reliability.
Moreover, your application will probably spend a vast majority of its CPU time waiting for resources or waiting for human interaction and doing nothing useful. Your application should have plenty of horsepower to spare for a few microseconds of reflection.
It seeks to reduce their dependency with IOC by ensuring object instance management within the application. The framework, rather than the developer, is in charge of creating and managing dependencies in your project.
The framework calls and runs our code when we write a block of code, and the entire event of passing control back to the framework is known as the Inversion of Control.
It enables the execution of a method separate from its
implementation.
It enables you to switch between multiple implementations with ease.
increases the modularity of the software
Because dependencies are reduced, it is simple to test and write.
What is the most important features a IOC container should contain? You can easily create containers in 15 lines of code, but what should it include to be "useful" in a project?
This is a pretty wide open topic, and given to a lot of subjectivity, but I will try and answer from a very pragmatic point of view. Given the projects that I have worked on, and my experience with IoC, I would say that there are at least three biggies to look for in terms of usefulness.
Configuration - Any IoC that you use needs to have some central location that allows you to configure the behavior of that container. Whether that be a config file or a nice set of API calls that can be wrapped up in a global class somewhere, if the container isn't easily configurable then it is going to be a headache.
Lifetime Management - You really want a container that has the ability to allow for varied object lifetimes. You might want a certain object to always get a new IPersonCreator, but you only want one IPersonService in existence at any given time.
Automatic Dependency Injection - Ok, so Dependency Injection is the concept that IoC is built on top of, but you don't want to have to manage this yourself. The idea here is that if you ask for an IPersonCreator for the first time, it should resolve all it's dependencies, and their dependencies and so on automatically.
Overall what you need depends on the project, but there are several containers out there that will suit your needs just fine.
In descending order of importance:
Allow at least setter and constructor injection,
Separate configuration from code,
Allow different styles of configuration (XML or annotations),
These will require more than 15 lines of code, but those seem key to me.