Мне нужно предложение Inpendency Injection в методе Constructor Injection?

Question

Я действительно заинтересован в некоторых архитектурных методах.Мне нравятся DI и IOC, но я не понимаю инъекции в конструктор;почему это так сложно.Я написал код ниже, который использует инжектор конструктора:

namespace DependencyInjection
{
    class Program
    {
        static void Main(string[] args)
        {
            ConstructorInjectionClass myCtx = new ConstructorInjectionClass(new PdfFormat());
            myCtx.Print();
            Console.Read();
        }
    }



    public interface IFormat
    {
        void Print();
    }

    public class PdfFormat : IFormat
    {

        public void Print()
        {
            Console.WriteLine("Pdf Format Print is completed...");
        }
    }


    // Constructor Injection

    public class ConstructorInjectionClass
    {
        private IFormat _format;

        public ConstructorInjectionClass(IFormat format)
        {
               _format = format;
        }

        public void Print()
        {
            _format.Print();
        }
    }

Я написал код ниже.Я думаю, что это просто.

    public interface IFormat
    {
        void Print();
    }

    public class PdfFormat : IFormat
    {

        public void Print()
        {
            Console.WriteLine("Pdf Format Print is completed...");
        }
    }

   public interface ISave
    {
        void Add();
    }

    public class Sql: ISave
    {

        public void Add()
        {
            Console.WriteLine("Adding to SQL is completed...");
        }
    }


    // Constructor Injection

    public class ConstructorInjectionClass
    {


        public ConstructorInjectionClass(IFormat format)
        {
               format.Print();
        }

         public ConstructorInjectionClass(ISave saver)
        {
              saver.Add();
        }

Почему я должен использовать инжектор конструктора?Преимущества или недостатки этих двух методов?

Answer 1

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

• Ваш первый пример - точечный.В вашем классе есть метод с именем Print, который зависит от другого класса для печати.Вместо того, чтобы создавать экземпляр этой зависимости, она требует, чтобы зависимость была указана в ее конструкторе.Это классический пример принципа обращения зависимостей .По сути: «Требуй, не создавай экземпляров».
• Ваш второй пример не совсем понятен.Что на самом деле делает ваш класс?Для чего это?У него есть два конструктора, которые выполняют действие над своими зависимостями, но почему?Больше нигде в классе нет зависимости от экземпляров этих типов.Так почему класс обертки стоит на первом месте?Это кажется более ... надуманным ... чем твой первый пример.Непонятно, что пытается реализовать архитектура кода, и, следовательно, поскольку она стоит не очень хорошо, использование внедрения в конструктор.

Answer 2

Первый пример - инжектор конструктора. Вы вводите класс с ответственностью за печать в класс.

Во втором примере вы создаете новый класс с одним из 2 аргументов и используете аргумент в конструкторе. Это плохо по нескольким причинам:

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

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

Первый вариант хорош, и если вы хотите добавить сохранение, вы должны добавить дополнительный аргумент в конструктор, чтобы получить интерфейс ISave, а также интерфейс IPrint и иметь метод Save, который будет делегат для ISave implmentation.

Внедрение зависимостей и программирование интерфейса облегчает последующее изменение функциональности. Например, вы могли бы легко сделать его выводом в файл (изменив передаваемый вами интерфейс IPrint или изменив его для сохранения в xml-файл или веб-сервис, изменив реализацию ISave, которую вы передаете. класс, слабо связанный с реализациями сохранения и печати

Я бы прочитал этот отличный ответ для получения дополнительной информации по DI / IOC

Answer 3

Допустим, вы хотите внедрить зависимости ... вы можете сделать это с помощью инжектора конструктора или с помощью установщиков свойств. Я думаю, что одним из преимуществ внедрения в конструктор является то, что МОК использует эту стратегию. Так что, если вы не уверены, что хотите перейти на IOC, но хотите использовать DI, то, вероятно, следует использовать инжектор конструктора, чтобы облегчить переход к последнему IOC ... проще ... если вам следует передумать ...