Рекомендации МОК: как лучше всего управлять графом зависимостей? - PullRequest
2 голосов
/ 19 февраля 2010

Я делаю проект MVC со структурной картой в качестве контейнера IOC. Мы работаем с TDD, и я хочу настроить свои зависимости так, чтобы с ними было легко работать, и чтобы их было легко тестировать.

Как мне лучше настроить график зависимостей для приведенного ниже вымышленного иллюстрированного графика?

  • ApplicationController
    • Контроллер
      • AuthenticationService
        • UserRepository

Вы вводите пользовательский репозиторий на контроллер и дальше от службы аутентификации? А что, если график глубже - вы не получите много зависимостей, начиная с контроллера?

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

Если я позволю контейнеру разрешить экземпляр где-то посередине графика, мне придется настроить контейнер для тестирования? Это хорошо, или лучше избегать?

Есть ли другой способ, которого я не вижу?

Ответы [ 2 ]

5 голосов
/ 19 февраля 2010

Ваш график зависимостей выглядит нормально. Как показано, каждый класс имеет только одну зависимость

  • ApplicationController зависит от контроллера
  • Контроллер зависит от службы аутентификации
  • AuthenticationService зависит от UserRepository

Я понимаю, что это упрощенное представление, и что ваша реальная производственная архитектура будет намного более сложной, но хорошая вещь в DI (и Constructor Injection в частности) заключается в том, что он допускает нарушения Принцип единой ответственности такой очевидный.

Когда класс начинает получать слишком много зависимостей, это признак того, что вы должны преобразовать агрегированную службу .

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

Вам никогда не придется разрешать экземпляр в середине графика. Решение - это то, что вы делаете в корне композиции , и (теоретически) только один раз.

Когда дело доходит до модульного тестирования, вам вообще не нужно использовать DI-контейнер .

0 голосов
/ 19 февраля 2010

Не уверен, как ваш applicationController относится к вашему контроллеру, но в целом ваш контроллер будет зависеть от вашей службы, а ваша служба будет зависеть от хранилища.

, например

public MyXyzController
{
  public MyXyzController(IAuthenticationService authenticationService){...}
}

public class AuthenticationService : IAuthenticationService
{
  public AuthenticationService(IUserRepository userRepository){...}
}

Таким образом, ваш контейнер IOC автоматически разрешает все зависимости, когда вы запрашиваете (то есть разрешаете) контроллер.

...