Dagger1 vs Dagger2

Dagger1과 Dagger2

• Dagger 

• 완전 static하고 컴파일 시에 DI를 수행하는 프레임 워크다. Square에서 만들었으나 현재는 Google에 의해 관리되고 있다.

• DI를 간편하게 도와주는 도구이다.

• Java Standard (JSR-330 - DI for) java annotations을 사용한다. ( @inject, @module etc ) 

• 컴파일 시에 DI를 모두 수행한다. 결국 Build 컴파일이 되었다면 문제가 없다는 뜻. module은 null을 return하지 않기 때문 보장된다.

• Dagger1

  • 2012년 Square에서 만들어졌다. 당시 Java의 DI에 널리 쓰였던 Guice 의 성능이 마음에 들지 않았고, Guice보다 더욱 유연하고 좋은 성능을 가진 Dagger1을 만들게 되었다.
  • Dagger는 사용자가 주입(inject)하기 원하는 모든 의존성들(dependencies)에 대한 provider method를 포함하는 모듈들을 정의하고, 이를 object graph에 로드한 뒤 필요에 의해 그 내용물들을 타깃에 주입하는 방식으로 동작한다.
  • 하지만 Dagger1은 안드로이드 개발자들이 프로젝트 생성 처음에 import하는 library임에도 절대 해결될 수 없는 구조적 문제가 있었다. 다음 문제들은 "뭐가 됐든, 대거2에서 고치겠음" 이라고 표시되었다고 한다.
    1. 런타임 중 Graph 구성 — 성능 저하가 특히 사용 요청시 마다 발생하였다.
    2. Reflection — generated code를 따르기 어렵게 만들고 ProGuard 설정은 악몽이었다고한다.
    3. 보기 힘든 generated code — 특히, factory에서 비슷하게 직접 작성한 것과 비교하였을 경우.
  • 2016년 9월 15일 기준으로 deprecated 되었다. 더 이상 개발되지 않으므로 Dagger2로 마이그레이션하는 것을 권장 하고 있다.

• Dagger2

  • Square의 기존 개발자들과 Google의 핵심 라이브러리 팀(Guava 를 만든 팀이다)이 Dagger2를 개발하고야 만다.
  • 뭐가 됐든, 대거2에서 고친 것은 다음과 같다.
    1. reflection 제거 — 평상시 처럼 메서드 콜을 하면 된다. ProGuard도 별도의 설정이 필요하지 않다.
    2. 런타임 중 graph 구성이 없다 - 약 13%정도 빨라졌다고 한다.
    3. 추적 가능 - 더 나은 generated code와 reflection 제거가 코드를 더욱 읽기 쉽게 만든다.
  • 장점만 있는 것은 아니다.
    1. inject() 메소드가 주입 대상과 강한 연결성을 띄게 되었다. 이 것은 Debugging 할 때는 좋지만, base class들로부터 주입하는 일반적인 관행을 복잡하게 만든다.
    2. 컴포넌트 implementation을 할 때 프로젝트를 rebuild 해야하고, 주입과 관련된 컴파일 에러가 클래스를 사라지게 만든다.(생성되지 않음)
    3. Override를 지원하지 않는다. Override를 사용하거나 DI를 사용하거나 둘 중 하나만 선택하여야 한다.

참고한 사이트

https://google.github.io/dagger/

https://blog.gouline.net/dagger-2-even-sharper-less-square-b52101863542

https://stackoverflow.com/questions/31354975/java-dependency-injection-dagger-1-vs-dagger-2-which-is-better