Dependency Injection "nesting" in related methods

We're using DI and Unity to work with different dependencies (generally, database and repository classes, dto to entity mappers, etc) Right now we're trying to create smaller functions that perform tasks that try to be independend from each other, in order to increase testability and also to avoid methods that have lots of different responsibilities, to avoid coupling

One question that I have is, how should DI be used when we have methods that rely on other inner methods, when the nesting is not trivial. For example, consider the following example (just a concept, not real working code):

public ProcessedOrder ProcessOrders(Order inputOrder)
{
    foreach (var line in inputOrder.OrderLines)
    {
         var someData = LineProcessor(line);
    }
}

public SomeData LineProcessor(OrderLine line)
{
      /* do some stuff*/
      var OtherData = ThingProcessor(null,line.SomeStuff);
      var ret = new SomeData();
      // assign values, more stuff
      return ret;
}

public OtherData ThingProcessor(IDep1 someDependency, SomeStuff stuff)
{
      someDependency = someDependency ?? ServiceLocator.Resolve<IDep1>();
      var ret = someDependency.DoThings(stuff);
      return ret;
}

Ok, so far the example shows that we have 3 functions, that could theoretically be called on their own. there's some injected dependency in the ThingProcessor, and if it's null then it tries to resolve it. However, this is a somehow simple example, but I see something I don't like so much. For instance, I'm calling ThingProcessor with a null value in the first param. So I can say, ok, I modify the signature of LineProcessor to have it injected, so that he pass it in to the other fu开发者_StackOverflow社区nction that needs it. However, he really doesn't need it, it's not its dependency but the function that he's calling. So here I don't know what approach is the more correct one, if the one that i'm showing, or if I should pass the correlated dependencies across layers. If I do this last thing, then the outermost function will be a mess, because it'll have a long list of dependencies that it will feed to everyone that's below it. However, the "null approach" I don't like very much, so I'm pretty sure that something's wrong somewhere, and there's probably a better way to design this. What's the best approach??? Remember, all functions must be used independently (called on their own), so for example I may call just ThingProcessor at some point, or at another one only LineProcessor.

UPDATE :

public CommonPurposeFunctions(IDep1 dep1, IDep2 dep2 ....)
{  
      this.Dep1 = dep1;
      this.Dep2 = dep2;
      [...]

}

public ProcessedOrder ProcessOrders(Order inputOrder)
{
    foreach (var line in inputOrder.OrderLines)
    {
         var someData = LineProcessor(line);
    }
}

public SomeData LineProcessor(OrderLine line)
{
      /* do some stuff*/
      var OtherData = ThingProcessor(line.SomeStuff);
      var ret = new SomeData();
      var morethings = this.Dep2.DoMoreThings();
      // assign values, more stuff
      return ret;
}

public OtherData ThingProcessor(SomeStuff stuff)
{
      var ret = this.Dep1.DoThings(stuff);
      return ret;
}

The approach we use is constructor injection, then we store the dependency in a private member field. The container wires up the dependencies; so the number of classes and constructor parameters doesn't really matter.

This works for services. If the dependencies across calls have meaningful state, you will have to pass them in to each call. But, in that case, I'd question if the methods really need to be public methods in their own classes.

You want to end up with a design that eliminates the service locator and truly injects the dependencies.