The singleton feature is nice but I rarely use singletons so that doesn’t help either :). And again, controlling object creation in code gives you a lot more control over the service’s lifecycle…

Regarding interface-based development I wasn’t asking a question but rather offering advice. The problem of interfaces with single implementations being YAGNI can easily be solved by only allowing service’s with two or more implementations. But I guess this should probably wait for another discussion.

class A
{
B _b;
public A(B b) { _b = b; }
}

class B
{
C _c;
public B(C c) { _c = c; }
}

class C { … }

To create an A, you have to chain up these dependencies:

A myA = new A(new B(new C()));

And remember, we’ve only added a single layer of dependencies… this is still an overly simplistic scenario that you wouldn’t see in most real-world applications. More realistic services have multiple dependencies, circular relationships, etc, which are very difficult to manage by hand. It’s not that you can’t do it, it’s that it’s much, much more difficult without a framework to help.

This also means that whatever code you’re creating A in needs to know of the existence of not only the dependencies of A (in this case, B) — but also the dependencies of A’s dependencies (in this case, C). That means that A is now coupled to C, and so is any code that consumes A. This can quickly expand exponentially in larger systems. You could easily get to the situation where every service in your system must be aware of every other service. Blech.

You’re also ignoring another major benefit of DI frameworks: the ability to control a service’s lifecycle. For example, with Ninject (and Windsor and Guice too), you can create a singleton simply by decorating your class definition with a [Singleton] attribute. To implement a singleton by hand, you either have to rely on something like a static Instance property, or a factory… neither of which is cleaner than a simple attribute. :)

I’m not sure I understand your question about interface-based development. Generally, I declare an actual interface to help me determine how a given service will interact with the rest of the application. That’s why I feel they’re useful even if you never end up defining more than one concrete implementation of the interface.

Can you provide a code sample to explain this statement? The way I see it an object should usually accept a type - which encapsulates its external dependencies - at construction. For example:

class A
{
B _b;
public A(B b)
{
_b = b;
}
}

Now the code that constructs A is simply required to have an instance of B available at the time of construction. This is simple OOP and I don’t see why it shouldn’t scale…

Regarding the issue of the interfaces, why not simply follow this rule:
Dependencies should always be interfaces with at least two concrete implementations.

If your dependencies are interfaces which have only one concrete implementation how can you tell you’ve got the correct separation between the client and the service?