IoC / DI для небольших .NET проектов

Question

Разделение проблем, обеспечиваемое платформами IoC / DI, невозможно переоценить для больших проектов, но есть ли место для таких методов в небольшом проекте?

Можете ли вы поделиться некоторыми практическими применениями IoCФреймворки / DI, которые вы сочли полезными при кодировании другого небольшого / среднего проекта.

Для определения:

"Маленький проект" содержит 100-1000 строк кода (balparkпросто чтобы дать представление), для кодирования требуется 1-3 дня, а срок действия получающегося приложения до того, как оно будет выброшено или выведено из эксплуатации, составляет в течение 1 недели - 5 лет после первоначального выпуска (здесь труднопровести черту между малым / средним / большим проектом).

Спасибо.

Answer 1

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

Я использовал этот подход на нескольких небольших проектах, и он работал очень хорошо. Конечно, это зависит от того, насколько сложны ваши зависимости - должны ли они быть фабриками, иметь различную область видимости и т. Д. - но если это просто «У меня есть эти три вещи, которые все зависят от службы аутентификации», то это довольно просто.

Answer 2

но есть ли место для таких методов в небольшом проекте?

Даже в небольших проектах вы должны использовать шаблон IoC, чтобы ослабить связь между слоями и сделать его тестируемым для модуля. Всегда работайте с абстракциями. Неважно, используете ли вы DI-фреймворк или нет. В небольших проектах вы можете просто выполнить сборку зависимостей вручную, на самом деле не нужен контейнер объектов для внедрения зависимостей, но когда вы подумаете, почему бы и нет?

Answer 3

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

var svc = new ShippingService(new ProductLocator(), 
                              new PricingService(), 
                              new InventoryService(), 
                              new TrackingRepository(new ConfigProvider()), 
                              new Logger(new EmailLogger(new ConfigProvider())));

Если вы можете с этим смириться, и лично я бы тоже, в одноразовом приложении, то, конечно, вам действительно не нужен DI-контейнер.Иди с тем, что делает тебя счастливым.Приветствия.

Редактировать :

На протяжении многих лет я считаю TinyIoC хорошим компромиссом для небольших проектов.

Answer 4

Я пишу много проектов одинакового размера, 30-40 в год.

Я использую DI, но создаю свой собственный фабричный класс с методом Resolve.

public T Resolve<T>()
    where T:class {
        if (typeof(T).IsAssignableFrom(typeof(Something)))
            return new Something(Resolve<ISomethingElse>()) as T;
        ...
}

Один ярлык Iпредположим, что я делаю большинство участников виртуальными, а не создаю отдельный интерфейс.

Answer 5

Я бы не связывал IoC с размером проекта так же, как:

• количество классов в проекте
• сложность их зависимости
• ожидаемое количество обслуживания и продления
• ожидаемое переключение разработчиков при расширении и обслуживании

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

Не перегружайте свой код

Следовательно, я бы предложил не использовать DI-контейнеры для начинающих, но определенно использует IoC в терминах интерфейсов и двойных конструкторов, таких как:

public class Example : IExample // for others that might depend on it
{
    private IDependant service;

    // default constructor used in your application
    public Example() : this(new DependentService())
    {
        // does nothing else
    }

    // constructor for testing purposes
    public Example(IDependant service)
    {
        this.service = service;
    }

    // IExample implementation
}

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

Небольшие проекты имеют тенденцию к росту

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

Answer 6

Вообще говоря, почему бы не использовать DI-контейнер для небольших проектов? Чем проще ваша кодовая база, тем проще использовать контейнер, мой совет - используйте его, который обеспечивает простой и гибкий интерфейс для регистрации зависимостей, или просто используйте linq, тогда вы в значительной степени получите очень маленькую площадь, которая подключит ваш все приложение:

public void OnStartup(args){
    var container = new IoCContainerOfChoice();

    Types.FromThisAssembly()
        .ForEach(type => container.Register(type, type.DefaultInterface());

    container.Resolve<ShellView>();
}

Это так просто, как должно быть для многих небольших проектов. Идея состоит в том, чтобы в одном проекте регистрировались все типы в интерфейсе по умолчанию (обычно я пишу метод расширения в «System.Type», чтобы выбрать либо именованный интерфейс, либо первый интерфейс, либо просто вернуть сам себя). ПРИМЕЧАНИЕ. Большинство современных контейнеров IoC имеют собственный интерфейс Fluent для обеспечения этой функциональности, это просто пример.

И, эй, смотрите, теперь вы настроены на будущее неожиданного роста, вы можете сэкономить кучу «новинок» и отделить ваше приложение, большое или маленькое.