МОК - введение нескольких зависимостей - PullRequest
0 голосов
/ 13 мая 2009

Рассмотрим ниже:

public class DependencyA {}
public class DependencyB {}
public class DependencyC {}
public class DependencyD {}

public class Service1
{
    public Service1(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}
public class Service2
{
    public Service2(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}
public class Service3
{
    public Service3(DependencyA a, DependencyB b, DependencyC c, DependencyD d) { ... }
}

Я обнаружил, что многие из моих служб зависят от нескольких общих компонентов, и намереваюсь реализовать решение «перехватить все», как показано ниже (все подключено через Windsor), чтобы сохранить повторение кода в конструкторах Service.

public class DependencyContainer
{
    public DependencyA A { get; set; }
    public DependencyB B { get; set; }
    public DependencyC C { get; set; }
    public DependencyD D { get; set; }
}

public class Service1
{
    public Service1 (DependencyContainer container) { ... }
}

В качестве альтернативы я мог бы создать класс ServiceBase.

public class ServiceBase
{
    public DependancyA A { get; set; }
    public DependancyB B { get; set; }
    public DependancyC C { get; set; }
    public DependancyD D { get; set; }
}

public class Service1 : ServiceBase {}

Реальный вопрос в том, подчеркивает ли это более широкую проблему дизайна в сервисах?

Возможно, я захожу слишком далеко, но это все подлинные зависимости.

Если так, то как мне обойти это? Если нет, является ли предлагаемое решение верным способом достижения этой цели?

Ответы [ 2 ]

1 голос
/ 13 мая 2009

Наличие слишком большого количества зависимостей от ваших сервисов может показать, что ваш сервис делает слишком много вещей. Другими словами, это, вероятно, нарушает принцип единой ответственности.

1 голос
/ 13 мая 2009

Трудно говорить об этой проблеме без более широкого контекста, но вы можете иметь дело со слишком мелкозернистыми зависимостями. Четыре зависимости принадлежат друг другу? Имеют ли они смысл как единое целое?

Если это так, ваш подход очень верен.

Если нет, вы можете ударить стену в своей архитектуре. Вы могли разделить свой домен таким образом, чтобы обязанности, которые должны быть наложены на одну или несколько (неявно существующих) сущностей, были присоединены к другим сущностям. В этом случае вы должны заглянуть в свой домен и попытаться идентифицировать эти повторяющиеся неявные сущности, сделать их явными и перенести поведение в них. Это, однако, гораздо более сложная проблема, которая очень специфична для вашего домена и приложения.

И это не имеет ничего общего с IoC

...