Правильно ли я понимаю DI / IoC? [закрыто]

Закрыто . Этот вопрос должен быть более сфокусированным . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он фокусировался только на одной проблеме, отредактировав это сообщение .

Закрыто 2 года назад .

В настоящее время я пытаюсь изучить преимущества использования контейнера IoC и познакомиться с DI. Я начал использовать StructureMap, поскольку он кажется довольно упрощенным, но все же мощным.

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

public class OrderService : IOrderService
{
    private IOrderRepository _repository;
    private ITaxCalculator _taxCalculator;
    private IShippingCalculator _shippingCalculator;

    public OrderService(IOrderRepository repository, 
        ITaxCalculator taxCalculator, 
        IShippingCalculator shippingCalculator)
    {
        this._repository = repository;
        this._shippingCalculator = shippingCalculator;
        this._taxCalculator = taxCalculator;
    }

    public IOrder Find(int id) { return this._repository.Find(id); }
}

public class OrderRepository : IOrderRepository
{
    public IOrder Find(int id) { // ... }
}

public class StandardShippingCalculator : IShippingCalculator
{
    // ...
}

public class StandardTaxCalculator : ITaxCalculator
{
    private ITaxSpecification _specification;

    public StandardTaxCalculator(ITaxSpecification specification)
    {
        this._specification = specification;
    }
}

Прежде всего, принцип инверсии зависимостей гласит, что, поскольку OrderService является модулем «высокого уровня», он не должен зависеть от деталей реализации что-нибудь более низкого уровня, он должен просто иметь ссылки на эти классы и иметь возможность просить их сделать свое дело, не зная , что он делает, а код потребления должен отвечать за создание и передачу ему этих предварительно сконфигурированных модулей. Это правильно? Следовательно, DI сохраняет эти классы слабо связанными, так что им не нужно знать точный способ вызова метода для этой зависимости, просто то, что он будет вызываться и делать все, что ему нужно - OrderService не заботится о том, запрашивает ли репозиторий XML, использует NHibernate, EF или даже необработанные наборы данных; он просто знает, что может позвонить в Репозиторий, сказать ему найти Заказ с ID 42, и репозиторий будет знать, что делать.

Я также понимаю, что контейнер IoC, в данном случае StructureMap, дает преимущество, так как не заставляет нас создавать все эти зависимости вручную и передавать их. Например, метод Main тривиального приложения, использующего приведенный выше код, может иметь:

static void Main(string[] args)
{
    IOrderService service = new OrderService(
        new OrderRepository(), new StandardShippingService(), 
        new StandardTaxService(new StandardTaxSpecification()));

    IOrder order = service.Find(42);

    // Do something with order...
}

, что отвратительно уродливо со всеми новости для настройки; даже если я создал переменные, это все равно некрасиво. Использование контейнера IoC позволяет мне избежать всего этого, и в случае StructureMap он будет выглядеть следующим образом:

static void Main(string[] args)
{
    ObjectFactory.Initialize(x =>
    {
        x.For().Use();
        x.For().Use();
        x.For().Use();
        x.For()
                        .Use();
        x.For().Use();
        x.For()
                        .Use();
    });

    IOrderService service =
                ObjectFactory.GetInstance();
    IOrder order = service.Find(42);
    // do stuff with order...
}

Что намного чище, проще в обслуживании и позволяет мне просто выделить конкретный класс, скажем, для Mock если бы я писал модульный тест. Короче говоря, преимущество состоит в том, что он еще больше отделяет все от того, где мне даже не нужно заботиться (в вызывающем коде, то есть) от того, от чего зависит конкретный класс, я могу просто создать его, используя контейнер, и позволить ему сделать Это' s, и убедитесь, что код потребления знает только то, что ему нужно - например, в реальном приложении, если контроллер вызывает службу, ему не нужно знать о репозиториях, калькуляторах или спецификациях, все, что ему нужно знать, это использовать OrderService, чтобы что-то сделать с Order.

Это правильно? В этой заметке есть несколько вещей, в которых я еще не уверен:

Если вы решите использовать контейнер IoC, предназначен ли он для использования везде в приложении, только там, где у вас есть много инвертированных зависимостей, которые нужно разрешить, или только у потребителя? Например, в OrderRepository, если я использую конкретную реализацию и создаю новый заказ; будет ли этот класс использовать StructureMap для получения заказа? Это может быть несколько глупый вопрос, но все примеры DI / IoC I ' Мы видели, как сосредоточены только на его использовании в клиенте-потребителе (например, на веб-странице), и никогда не касались его использования где-либо еще. Похоже, что это подход «все или ничего»: если вы собираетесь использовать контейнер IoC, его используют везде; по сути, вы заменяете любой вызов new SomeObject (); на, в данном случае, ObjectFactory.GetInstance ();
Считается ли хорошо или плохо иметь каждый класс ( где это возможно, конечно) происходят из интерфейса, независимо от того, нужно ли использовать DI / IoC или что-то вроде насмешки над ним? Я видел много примеров кода, в которых каждый отдельный класс, не являющийся встроенным, имеет интерфейс, стоящий за ним, и хотя я вижу преимущества и возможную перспективу в будущем, я полагаю, что следование TDD или BDD может быть здесь фактором, поскольку использование этих методологий обычно говорит вам, нужен ли вам интерфейс для класса, но я видел и поговорили со многими людьми, которые, TDD или нет, считают, что вы никогда не должны определять тип объекта как конкретный класс; он должен всегда быть интерфейсом или абстрактным классом в качестве базового типа. Похоже, дело в запахе кода "ненужной сложности", не говоря уже о нарушении YAGNI.

задан Steven 5 January 2011 в 19:46

0 ответов

Другие вопросы по тегам:

.net dependency-injection inversion-of-control solid-principles

Правильно ли я понимаю DI / IoC? [закрыто]

0 ответов

Похожие вопросы: