iOS 앱에서 의존성 삽입 사용에 대한 토론

Question

저는 각 고객별로 필요에 따라 다른 바이너리가 필요한 iOS 앱을 만들고 있습니다. 고객은 모든 색상, 아이콘 및 텍스트를 변경하고자 할 수 있습니다. 우리는 흰색 라벨링 과정을 통해 그렇게 할 수 있습니다. 그러나 여기서 문제는 로그인 화면을 제거하고 로그인하도록 선택 사항을 지정하는 것과 같이 다른 행동을 요구할 때입니다.

필자는 의존성 삽입을 사용할 수 있고 필요한 경우 각 고객마다 다른 처리기를 사용할 수 있다고 생각했습니다. 예를 들어 LoginHandler1과 LoginHandler2를 ILoginHandler를 구현하고 UIViewController에서 상속받을 수 있습니다.

그러나 의존성 삽입을 사용하면 비용이 많이 들며 정상적인 인스턴스화와 비교할 때 해결이 비용이 많이 들기 때문에 응용 프로그램의 속도가 느려집니다.

다른 방법은 앱에서 이러한 모든 동작을 정의하고 plist 파일에서 이러한 동작을 사용/사용 중지하는 것입니다. like "로그인 선택 사항입니까? 예/아니오"

어떤 제안이 있습니까?

감사합니다.

Answer 1

구성 루트에 전체 개체 그래프를 만들어야합니다. 오브젝트 생성 및 생성자 삽입은 생성자가 실제 작업을 수행하지 않는 한 많은 시간을 소비해서는 안됩니다.

즉, 응용 프로그램 시작시 전체 개체 그래프를 만드는 데 시간이 오래 걸리는 경우가 있습니다. 이 경우 을 사용하여 나중의 까지 값 비싼 초기화를 지연하면서 컴포지션 루트에 개체를 만들 수 있습니다.

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/

다른 방법은 응용 프로그램의 모든 행동을 정의하고 사용 가능/A PLIST 파일을 해제하는 것입니다. like "는 로그인 옵션입니까? 예/아니오"

"우아함"은 떨어지지 만이 솔루션은 매우 유용합니다. 특히 프로젝트가 클래스 및 VC의 수면에서별로 중요하지 않은 경우에 특히 유용합니다.앱 코드가 이미 배치되어 있고 주요 디자인 변경을 도입하면 많은 리팩토링을 요구하는 경우 구현하는 것이 가장 쉬운 방법이기도합니다.

항상 작업을 바탕으로 조치를 취하십시오. 소프트웨어 설계 문제에 대한 단일 솔루션이있는 경우는 거의 없습니다.