Inversion of control - no "new" in a low level constructor?

Question

When using IoC in a code base, should one always stick strictly to the pattern without exception?

That means there should be no "new" in any constructor, when the newed object has dependencies.

Or should one just go for convenience with that pattern.

Things like in the example should not be allowed?:

 public ToolbarViewModel(
      ICommand slowCommand,
      string text)
    {
       SlowCommand = new LongRunningCommandDecorator(slowCommand, text);
    }

Answer 1

Rule #1: there are exceptions to every rule.

The point of IoC is to make it easy to use a different implementation of a dependency. If there's no circumstance in which going to want to use a different implementation (including for unit testing), then just new up the object.

The most common case here is for your platform objects - you're never (see Rule #1) going to want to use a different implementation of string, so it would be a ridiculous amount of overkill to push an IStringFactory into your objects so you can do return stringFactory.create("Hello, World!") rather than return "Hello, World!".

Be practical, not dogmatic. If following a rule costs more than it gains, don't follow the rule.