Обсуждение использования инъекции зависимостей в приложении iOS

Question

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

Я думал, что мы можем использовать инъекции зависимостей и при необходимости использовать разные обработчики для каждого клиента. Например, мы можем иметь LoginHandler1 и LoginHandler2, реализуя ILoginHandler и наследуя от UIViewController.

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

Другой способ - определить все эти поведения в приложении и включить/отключить их в файле plist. например, «является логин необязательным? да/нет»

Любые предложения?

Благодаря

Answer 1

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

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

Mark Seemann описывает этот подход более подробно здесь: Compose object graphs with confidence.

Answer 2

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

Вы считали правильным. Гибкость - одна из основных причин, по которой люди используют DI.

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

Это действительно не так уж и дорого. Вы сами пробовали? Если объект, о котором идет речь (т. Е. Вводимый объект), очень дорог для создания экземпляра, у вас нет реальной причины держаться подальше от DI и Inversion Of Control. Кроме того, как отмечал выше @Lilshieste, создание объектного графика спереди (см. AppDelegate), вероятно, сделает эту проблему еще более проблематичной.

Хороший способ сделать это описано здесь: http://cocoapatterns.com/passing-data-between-view-controllers/ и здесь http://cocoapatterns.com/ios-view-controller-transitions-mediator-pattern/

Другой способ заключается в определении всех этих моделей поведения в приложение и включить/отключить их в файле PLIST. например, «является необязательным для входа» да/нет »

Хотя это« элегантно », это решение довольно полезно, особенно если проект не очень большой по количеству классов и VC.Это также самый простой способ реализовать, если код приложения уже выложен и введение основных изменений дизайна потребует много рефакторинга.

Всегда предпринимайте действия на основе поставленной задачи, редко бывает когда-либо решение проблемы с программным обеспечением.