This project is read-only.

Questions and Answers

Q: What are the common configuration tasks for configuring an IoC container according to this project?
A: We have found by usage that there are five common tasks we want to perform over and over again;

  • Register Instance (with or without a key)
  • Register Type (with or without a key)
  • Marking a registration as Singleton
  • Selecting a constructor for injection
  • Selecting properties for injection

Q: What about Method Injection?
A: Currently the CSM does not support Method Injection but first it can easily be extended to do so and second if you want that feature and feel it is part of the classic basic set of features for any IoC container; please let the project owners know about your request.

Q: If you extend the API to match a specific function in your IoC container; aren't you then tying yourself right back to that container?
A: First of all you don't tie yourself with a hard reference if you use this API and extend it. Second this project recognizes the same sound principle that was discussed in the creation of the CSL; Once you've selected an IoC container you really don't have all that much use for an abstraction API. The fact that you could change container as easily as swapping a small API implementation does not mean that you ever will. If you really want to replace an IoC container for a project it is not something that will take a whole lot of time for almost any project. It is only a “nice to have” side effect to the abstraction API that you can swap containers. Not even in the fact that you get away from a hard reference to a specific library is the real benefit in using an abstraction. The real two benefits when using an abstraction for configuring your IoC container is first that you expose to the developers of your project an easy to use tool that is just the right one for the job and second the fact that the configuration code they do write will be type safe. Giving the development team the full API of an IoC implementation is quite often not what they really need and can easily be miss used. Abstracting away a big API is a good thing and should be common practice for many scenarios.

Q: In what ways can you configure an IoC Container?
A: There are three main ways you normally configure your IoC:

  • Using a configuration (xml) file
  • Using attributes on your classes, constructors and properties
  • Using an API

Each approach has pros and cons and are employed for different reasons. See also below.

Q: What are the pros and cons for using a configuration file for configuring IoC?
A: There is one great advantage when using a configuration file and that is the fact that you can re-configure your IoC after the fact. What this means is that you can change how your system hangs together without having to re-compile and change your code. It is a scenario used when adding in third party components in your application after it’s been installed. However there are also other ways to do this. Unless you have this very specific requirement that you cannot change your code and want to configure injection without re-installing then this approach is not recommended. Why not? Well all other characteristics of using a config file for IoC are negative! A config file has to be maintained separate from the code that it configures. Usually a config file is in the form of xml making it rather verbose when it comes to the number of characters actually used to describe the IoC configuration. The configuration is also usually read at system start which requires the opening, reading and interpreting of a file from disk. This is takes time. If startup time is a critical factor for your project then this approach is very likely not the one you want. A configuration file can be maliciously modified to change and harm your system. A configuration file furthermore usually does not offer design or compile time support and is not type safe. It is easy to make mistakes in your configuration that do not show up until you run and hopefully test the system. Some refactoring apps are able to detect refactoring in config files and support a better design time experience but mostly this is an error prone hassle.

Q: What are the pros and cons for using attributes for configuring IoC?
A: Using attributes is an easy way to get started and an easy way to overview in your code what constructors, properties etc. are used for Dependency Injection. This is a good place to start if you have never used and IoC container before. You can quite easily move from attributes to using a configuration API later if you like. There are a few disadvantages of using attributes to configure your IoC; First your code is not POCO - meaning it is not Plain Old Clr Objects. Your code has attributes on it. Some feel that this clutters your code with Cross-cutting concerns: The code itself is not really concerned with how it fits together with other code. Your code is only supposed to concern itself with what it is supposed to accomplish. Second the attributes also lead to having a reference from your code to the framework that is the IoC. This means that your code is dependent on a specific version somebody else's code. This in itself can lead to a tangled mess of references from code to other code to other code and so on. Third this means you tie your code to a particular IoC implementation. Some consider this bad. Fourth there is also the issue of starting up your project and reading the configuration information that is now in the meta-data of your code in the form of attributes. You have to read through all the code and inspect all the meta-data in order to configure your IoC. Some people consider this a lot of extra work. It is a fact that it is not as fast as using a configuration API.

Q: What are the pros and cons for using an API for configuring IoC?
A: Using a configuration API has the most advantages. It is fast - as fast as running your code on your CPU. It is POCO. It can remove the reference to the IoC container (and it’s potentially big and difficult to use API) from your code. When done right as with this API it can be type safe. The disadvantages are not that many to this approach. Mostly the problem can become that you have to call the configuring code somehow; The  that configures your IoC container that is. There are solutions for this problem but it can become messy, hard to overview and kind of ‘magical’. All in all the API approach to configure an IoC with an API as compared to configuration (xml) file or using attributes makes using an API easily the most bad ass! ;~)

Q: Should I use this library for my applications?
A: The CSL project in answering the same question and states “Typically, the answer to this question is no”. That argument is sound for service location but a bit less so for service configuration. To be clear; Typically, the answer to this question is yes. ;~) If you are looking to use an API to configure IoC; Go for it! The API for a regular IoC container can be a rather large thing which makes it hard on your development team to use which can lead to confusion and miss-use. Abstracting away all the noise and only exposing a common minimal API for performing the exact tasks your team needs is a much more apt tool for most of your needs. Extend the API to fit your needs to 100%.

Q: What about ServiceLocator.Current?

A: The CSL defines a global static hook for hanging your instance of the IServiceLocator contract upon. It has been the experience of trying to use that hook that it is in fact not a good idea at all. The only thing that can come from that is code that is less testable and tests that potentially interfere with one another. Thus this project; the CSM, does not define a static hook for it’s version of the IServiceLocator. If you want one and think it’s a good idea; just go ahead and create one of your own.

Last edited Sep 5, 2010 at 8:03 PM by NoopMan, version 4


No comments yet.