Внедрение зависимостей в JavaScript

class Repository {
   static required = {
      store: "Storage"
   }

   ...
}

Затем с помощью Proxy-Api мы можем добавить ловушку для вызовов конструктора внедряемых классов, в данном случае Repository- сорт:

class Repository {
    static required = {
      store: "Storage"
    }
   

   constructor({store}) {
       this.store = store;
   }
   
   ...
}


const constructorHandler = {

    construct (target, argumentsList, newTarget) {
        if (target.required) {
            // container holds a reference to the ioc-container
            container.inject(argumentsList, target.require); 
        }      

        return new target(...argumentsList);
    }

};


Repository = new Proxy(Repository, constructorHandler)

Обработчик делегирует IoC-Container до создания экземпляра целевого класса: затем IoC-Container проверяет список аргументов и ищет любые отсутствующие свойства в ранее заключенном объекте-аргументе, который используется для настройки экземпляра. Обозначаемое свойством required, имя переменной экземпляра должно совпадать с именем объекта конфигурации, содержащего свойство, необходимое конструктору:

// IoC-container will not inject anything, since the instance gets configured
// with a "store"-property
new Repository({store: new Storage(), uri: "/resourceUri"});


// since the "store"-property is missing, the IoC-container will
// inject a concrete of "Storage" according to the available bindings
new Repository({uri: "/resourceUri"});

Создание привязок

Привязки — это точка истины для нашего приложения, поскольку мы полагаемся на сборщики и распознаватели, которые настраиваются заранее и заботятся о сборке ассоциаций во время выполнения. Привязки сопоставляют конкретные подтипы с типами, что означает: они привязывают типизированную переменную к конкретной реализации Тип, чтобы наш IoC-Container знал, что применять и где применять (подразумевается когда с помощью конструктора инжектора). Запрошенный специфический реализует интерфейс или расширяет (абстрактный) класс, а LSP дает нам свободу предоставлять произвольные реализации этого заданного Типа.

Если для каждого объекта o1 типа S существует объект o2 типа T, такой что для всех программ P, определенных в терминах T, поведение P не изменяется при замене o2 на o1, то S является подтипом T. Барбара Лисков, Абстракция данных и иерархия

Так как мы слабо типизированы, наш Dependency Resolver (представьте его как своего рода Builder,) должен убедиться, что наши особенности действительно являются экземплярами требуемого типа.

Нахождение общего языка

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

У нас есть класс A, который использует экземпляр класса B:

Код для

«A имеет зависимость от типа B, и эта зависимость отражена в переменной экземпляра A b»

может выглядеть так:

// Pseudo code

abstract class B {
    abstract calculate();
}


class A {

    constructor (B b)
    {
      this.b = b;
    }


    calculation()
    {
        this.b.calculate();
    }
} 

Очевидно, что источники, которые полагаются на A, не будут работать без [экземпляра A].b — как только calculation() делегирует b.calculate()и b равно undefined, будет выдано исключение.

Мы ищем формальное (но простое) определение, которое можно использовать с JavaScript для настройки этих зависимостей: Мы согласны с форматом JSON, так как он допускает пары ключ/значение, тогда как ключи имеют тип string и их значения могут быть любыми из string, integer, boolean, NULL, object и array — мы будем использовать string и object.

Уточним задачу для разрешения зависимостей A:

when A
  requires B
  give new instance of B

Это довольно простой термин, который позже будет преобразован в назначение с помощью Dependency Resolver. На данный момент это так, как это перенесено в JSON (не обращайте внимания на пояснительные комментарии):

 {
    /* when */
    "A": {
      /* "needs": "give" */ 
      "B" : "InstanceOfB" 
    }   
}

Пример использования: внедрение методов аутентификации

С coon.core.ioc как частью приложения coon.js, вот типичный вызов coon.core.ioc.Container.bind():

// Some class names have been shortened in favor of
// readability.
coon.core.ioc.Container.bind({
        "conjoon.dev.cn_mailsim": {
            "conjoon.SimletAdapter": "conjoon.BasicAuthSimletAdapter"
        },
        "conjoon.cn_mail": {
            "coon.core.data.request.Configurator": {
                "$ref": "#/$defs/RequestConfiguratorSingleton"
            }
        },        
        "$defs": {
            "RequestConfiguratorSingleton": {
                "xclass": "conjoon.cn_imapuser.data.request.Configurator",
                "singleton": true
            }
        }

});

Эта конфигурация представляет привязки пакета extjs-app-imapuser-, пакета npm, обеспечивающего аутентификацию пользователя для conjoon extjs-app-webmail, который почтовый клиент, написанный на JavaScript.

extjs-app-webmail взаимодействует с бэкендом, который не зависит от используемой аутентификации — его архитектура позволяет защищать конечные точки с помощью произвольных методов аутентификации: это может быть базовая аутентификация доступа. , или API может использовать защиту, основанную на аутентификации на основе токенов. Вот почему запрашивающий клиент — в данном случае extjs-app-webmail — должен быть настроен с использованием надлежащей техники безопасности, понятной серверной части. Это делается с помощью конфигураторов запросов, которые подключаются к (некоторым/всем/никаким) исходящим запросам и добавляют аутентификационную информацию, если это требуется серверной части, например. поле заголовка Authorization, содержащее Bearer-, Basic- или другую информацию.

Объяснение привязок

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

conjoon.dev.cn_mailsim.A, conjoon.dev.cn_mailsim.B, conjoon.dev.cn_mailsim.C, …

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

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

  "conjoon.cn_mail": {
      "coon.core.data.request.Configurator": {
         "$ref": "#/$defs/RequestConfiguratorSingleton"
     }
  }

На основе спецификации схемы JSON $ref использует URI для ссылки на другой раздел документа, в который он встроен, что позволяет определить многоразовую сложную конфигурацию в одном месте, а затем повторно использовать этот конфигурации по всему документу, ссылаясь на него.

(Resolved)$ref в приведенном выше примере утверждает, что

when any class of conjoon.cn_mail
  requires coon.core.data.request.Configurator
  give Singleton of conjoon.cn_imapuser.data.request.Configurator
       

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

Разрешение зависимостей — отлов фабрик

Система классов Sencha Ext JS почти исключительно использует фабрики при создании экземпляров. Это полезно для динамической загрузки классов: его микрозагрузчик позаботится о сопоставлении имен классов с существующей структурой каталогов проекта, но загрузка происходит синхронно (в худшем случае, если класс не был предварительно загружен). Использование Sencha Ext JS без собственной системы классов практически невозможно. В некоторых случаях это неприятный сюрприз для пользователей, начинающих с Ext JS в 2022 году.

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

Wrapper-Proxy устанавливается, как только вызывается coon.core.ioc.Container.bind():

 installProxies () {
        const me = this;

        Ext.Factory = new Proxy(
            Ext.Factory, 
            Ext.create("coon.core.ioc.sencha.resolver.FactoryHandler")
        );

        Ext.create = new Proxy(
            Ext.create, 
            Ext.create("coon.core.ioc.sencha.resolver.CreateHandler")
        );
    },

Есть два обработчика прокси, которые служат двум разным целям. Давайте посмотрим на них:

Обработчик для Ext.create

CreateHandler – это метод, перехватывающий вызовы Ext.create. Он проверяет, является ли аргумент, переданный в Ext.create(),

• a String: в этом случае предполагается, что это имя класса, для которого должен быть создан экземпляр.
• Объект: Обычно это указывает на то, что клиент отправляет конфигурацию, содержащую xtype или xclass, предоставляющую дополнительные сведения о классе, который служит шаблоном. Все свойства, содержащиеся в объекте, обычно передаются в конструктор целевого класса, кроме xtype/ xclass

{
    "xtype": "alias-of-class",
    // or "xclass": "fqn.of.class"
    "cArg1": "foo",
    "cArg2": "bar"  
}

Как показано на Рис. 9, после успешного разрешения целевого класса с учетом внутренних особенностей Ext JS обработчик запускает событие classresolved вместе с информацией об имени класса и прототипе JavaScript. em> разрешенного класса.

if (cls) {
    const className = Ext.ClassManager.getName(cls);
    me.fireEvent("classresolved", me, className, cls);
}