Name a simple Dependency Injection framework [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 6 years ago.

Improve this question

I would like to try using an DI/IoC framework for the first time in a small-ish but growing project, and I don't want to disturb the project much by introducing bulky dependencies. The project itself is partly intended to be used as a library in other projects, and I don't want to trouble users with managing extra dependencies. It's also a matter of taste--I feel the size of a component should be proportional to the amount of services that I actually need. I hate to开发者_JAVA百科 incorporate a bulky component with dependencies of its own, only to use a small part of it.

So, for .NET, is there a small DI/IoC framework that compiles to a single DLL with no dependencies other than standard libraries, that (if necessary) could be directly embedded in the assembly that uses it, and that emphasizes code-based/fluent (as opposed to XML) wiring? It must not require .NET framework 4.0.

---

I feel much the same as you do about IOC frameworks. I use IOC all the time, I just don't see the need for a Framework much.

Having said that, the one I'd use if I were to pick one up would be AutoFac

It's simple, easy to grasp, and feels lightweight.

---

I'd also suggest in addition to NInject that you look at Microsoft's DI Framework, Unity.

---

Any framework that you will introduce will eventually become a dependency of your app. Also, people have varied definitions of what lightweight is. Take a look at Unity, or StructureMap or Castle Windsor as they tend to be more popular. Scott Hanselman has a whole list, here. Take your pick.

---

Take a look at Ninject.

---

Try StructureMap.

The core StructureMap.dll is pretty small.

---

There are examples on the web about writing your own container, although they are very basic and would lack features provided by a more robust framework.

---

I work with a rather large system and we've manually injected everything. We make use of the abstract factory pattern to tidy up most of the injection/wiring and it's worked out fine.

DI Frameworks are plentiful. Before taking on an extra external dependency, take some time to consider if applying a different/new pattern would solve your problems.

edit: (possibly biased/unjust) Reasons I haven't used a DI framework:

• If you use a DI framework, you have to ship the DI framework with your software. This can be a show stopper for some, and others might have to argue the merits of the extra dependency.
• You still have to build constructors to take dependencies
• And you still have to tell (or at least hint) at the DI framework what to use. The only major difference is your using the DI factory rather than your own.

As for building that factory, most refactoring tools can do 90% of the work for you with very few keystrokes.