Unity autowiring: to use or not to use?

Question

seems like with the new unity version has been added support for autowiring.

How many of you are familiar with it and strngly suggest me to use or not use it? Seems to me that the use of it limit my control on the DI especially for what regard the unit tests, am I thinking wrong?

Answer 1

I'm assuming that this question is about Auto-Registration, since Unity has had Auto-Wiring for years.

Since I wrote my When to use a DI Container article a couple of years ago, I've only become slightly more radical in my attitude towards DI Containers. In that article, I describe the benefits and trade-offs of using DI Containers, as opposed to Poor Man's DI (manually composing code).

My order of preference is now:

1. Manually write the code of the Composition Root (Poor Man's DI). This may seem like a lot of trouble, but gives you the best possible feedback, as well as it's easier to understand than using a DI Container.
2. Use Auto-Registration (AKA Convention over Configuration). While you lose compile-time feedback, the mechanism might actually pull your code towards a greater deal of consistency, because as long as you follow the conventions, things 'just work'. However, this requires that the team is comfortable with the Auto-Registration API of the chosen DI Container, which, in my experience, isn't likely to be the case.
3. Only use Explicit Register if you have a very compelling reason to do so (and no: not thoroughly understanding DI is not a good reason). These days, I almost never do this, so it's difficult for me to come up with some good cases, but advanced lifetime management may be one motivation.

It's been 1½ years since I last used a DI Container in any production code.

In summary, and in an effort to answer the specific question about Unity:

• Seriously consider not using Unity at all (or any other DI Container).
• If you must use Unity, use the Auto-Registration feature. Otherwise, you're likely to get more trouble than benefits from it.

Caveat: I'm writing this as a general response, based on my experience with DI and various DI Containers, including Explicit Registration and Auto-Registration. While I have some knowledge about previous versions of Unity, I don't know anything about the Auto-Registration features of the new version of Unity.

Answer 2

I've built a container which automatically register your services. All you need to do is to tag them with an attribute.

this is not autowiring per se, but that's part of my point. Unity have from the start been able to build classes which has not been registered in the container. And that's imho a big weekness as the class might be used with dependencies that it shouldnt use or that it will have a different lifetime than intended.

My choice to use an attribute was to be able to make sure that all services can be resolved and built. When you call the builder.Build() method my container will throw an exception if something can't be resolved.

Hence you will directly at the startup see if something is missing, rather then later at runtime.

So autowiring might seem good, but as you say: You'll loose control only to discover it later during runtime if something is missing.