Внедрение зависимостей «вложенность» в родственных методах - PullRequest
0 голосов
/ 06 сентября 2011

Мы используем DI и Unity для работы с различными зависимостями (как правило, классы базы данных и репозитория, преобразователи dto в сущности и т. Д.) Прямо сейчас мы пытаемся создать меньшие функции, которые выполняют задачи, которые пытаются быть независимыми друг от друга, чтобы повысить тестируемость, а также избежать методов, которые имеют много разных обязанностей, чтобы избежать связывания

У меня один вопрос: как использовать DI, когда у нас есть методы, основанные на других внутренних методах, когда вложение не является тривиальным. Например, рассмотрим следующий пример (просто концепция, а не реальный рабочий код):

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;
}

Хорошо, пока пример показывает, что у нас есть 3 функции, которые теоретически можно вызывать самостоятельно. в ThingProcessor есть некоторая введенная зависимость, и если она пуста, она пытается ее разрешить. Тем не менее, это как-то простой пример, но я вижу то, что мне не очень нравится. Например, я вызываю ThingProcessor с нулевым значением в первом параметре. Итак, я могу сказать, хорошо, я изменяю сигнатуру LineProcessor для ее внедрения, чтобы он передавал ее другой функции, которая нуждается в этом. Однако ему это действительно не нужно, это не его зависимость, а функция, которую он вызывает. Так что здесь я не знаю, какой подход является более правильным, если я показываю, или мне следует передавать взаимосвязанные зависимости по слоям. Если я сделаю это в последнюю очередь, то самая внешняя функция будет беспорядочной, потому что у нее будет длинный список зависимостей, которые будут переданы всем, кто находится под ней. Однако «нулевой подход» мне не очень нравится, поэтому я уверен, что где-то что-то не так, и, вероятно, есть лучший способ спроектировать это. Какой лучший подход ??? Помните, что все функции должны использоваться независимо (вызываться самостоятельно), поэтому, например, в какой-то момент я могу вызвать только ThingProcessor, а в другой - только LineProcessor.

ОБНОВЛЕНИЕ:

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;
}

Ответы [ 2 ]

3 голосов
/ 06 сентября 2011

Подход, который мы используем, - это внедрение в конструктор, после чего мы сохраняем зависимость в закрытом поле члена.Контейнер связывает зависимости;поэтому количество классов и параметров конструктора не имеет большого значения.

Это работает для услуг.Если зависимости между вызовами имеют осмысленное состояние, вам придется передавать их каждому вызову.Но в этом случае я бы задал вопрос, действительно ли методы должны быть открытыми методами в своих собственных классах.

Вы хотите получить дизайн, который исключает указатель службы и действительно внедряет Зависимости.

0 голосов
/ 06 сентября 2011

Помогает ли шаблон нулевого объекта?

http://en.wikipedia.org/wiki/Null_Object_pattern

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...