Является ли это хорошим примером "анти-паттерна инъекций Bastard"? - PullRequest
17 голосов
/ 06 декабря 2011

Я вижу, что ведущие разработчики пишут подобный код и после прочтения книги Марка Симанна «Внедрение зависимостей в .NET» Мне интересно, является ли конкретное «новое» «чужим», то есть «Вредные инъекции»??

public class SessionInitServiceManager
{
    protected readonly ICESTraceManager _traceManager;
    protected readonly ILogger _logger;
    protected readonly IAggregateCalls _aggregator;
    protected readonly IMultiCoreRepository _repository;

    public SessionInitServiceManager(ICESTraceManager traceManager,
                                     ILogger logger,
                                     IAggregateCalls aggregator,
                                     IMultiCoreRepository repository)
    {
        _traceManager = traceManager;
        _logger = logger;
        _aggregator = aggregator;
        _repository = repository;
    }

    public SessionInitServiceManager() : this(new CESTraceManager(),
                                              new Logger("BusinessServices.authenticateUser"),
                                              new Aggregator(),
                                              new RepositoryFactory().BuildMultiCoreRepository()) { }

Ответы [ 2 ]

9 голосов
/ 06 декабря 2011

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

То, как это не было бы Bastard Injection, было быэти классы живут в одном модуле.То, что делает это настолько плохим, заключается в том, что вы перетаскиваете зависимости, и теперь ваш класс тесно связан с этими классами.Если я решу использовать свою собственную версию ведения журнала, мне придется взять с собой DLL для ведения журнала и т. Д., Даже если я не использую, сводя на нет преимущества модульного проектирования приложений.

0 голосов
/ 15 февраля 2012

Я случайно позаимствовал эту книгу, инъекцию зависимостей в .NET, у друга. Я вижу, что вы говорите. Я действительно считаю, что это "инъекция ублюдка". Это жестокий термин, но я полагаю, что в конце концов в ColdFusion (кашель) есть тег "CFABORT" как часть языка.

Также я заметил хорошую статью в блоге Как не делать инъекцию зависимостей - статический или одноэлементный контейнер .

По сути, прежде чем мы начнем, давайте что-нибудь уберем с пути:

Внедрение зависимостей! = Использование контейнера IoC "

Вот кикер: «Это рождение статического контейнера. Вместо того, чтобы изменять конструктор контроллера для получения зависимости, мы просто меняем строку, в которой создается экземпляр сервиса, чтобы разрешить его, используя вместо этого контейнер . "

 public class HomeController
 {
    private readonly IExampleService _service;

    public HomeController()
    {
      _service = Container.Instance.Resolve<IExampleService>();
    }

    public ActionResult Index()
    {
      return View(_service.GetSomething());
    }
 }
...