의존성 주입을위한 Google Guice 대 PicoContainer

우리 팀은 의존성 주입 프레임 워크를 연구하고 있으며 Google-Guice와 PicoContainer를 사용할지 결정하려고합니다.

프레임 워크에서 몇 가지를 찾고 있습니다.

1. 작은 코드 풋 프린트-작은 코드 풋 프린트가 의미하는 것은 우리 코드베이스의 모든 곳에 의존성 주입 코드가 흩어져있는 것을 원하지 않는다는 것입니다. 향후 리팩토링이 필요한 경우 가능한 한 쉽게 수행 할 수 있기를 바랍니다.
2. 성능-개체를 만들고 주입 할 때 각 프레임 워크에 얼마나 많은 오버 헤드가 있습니까?
3. 사용 용이성-큰 학습 곡선이 있습니까? 간단한 작업을 위해 많은 코드를 작성해야합니까? 가능한 한 적은 구성을 원합니다.
4. 커뮤니티 규모-더 큰 커뮤니티는 일반적으로 프로젝트가 계속 유지된다는 것을 의미합니다. 우리는 프레임 워크를 사용하고 싶지 않고 우리 자신의 버그를 수정해야합니다.) 또한 우리가 겪는 모든 질문은 프레임 워크의 개발자 / 사용자 커뮤니티에서 답변 할 수 있습니다.

두 프레임 워크를 나열된 기준과 비교하면 크게 감사 할 것입니다. 둘을 비교하는 데 도움이되는 개인적인 경험도 매우 도움이 될 것입니다.

면책 조항 : 저는 의존성 주입에 익숙하지 않기 때문에이 토론과 관련이없는 질문을했다면 제 멍청함을 용서하십시오.

고려중인 종속성 주입 프레임 워크 목록에 Spring을 포함시킬 수 있습니다. 다음은 질문에 대한 몇 가지 답변입니다.

프레임 워크에 연결

Pico -Pico는 setter 주입을 권장하지 않는 경향이 있지만 그 외에는 수업에서 Pico에 대해 알 필요가 없습니다. 알아야 할 것은 배선뿐입니다 (모든 DI 프레임 워크에 적용됨).

Guice -Guice는 이제 표준 JSR 330 주석을 지원 하므로 더 이상 코드에 Guice 특정 주석이 필요하지 않습니다. Spring은 또한 이러한 표준 주석을 지원합니다. Guice 사람들이 사용하는 주장은 Guice 주석 프로세서가 실행되지 않으면 다른 프레임 워크를 사용하기로 결정한 경우 영향을 미치지 않아야한다는 것입니다.

Spring -Spring은 코드에서 Spring 프레임 워크에 대한 언급을 피하는 것을 목표로합니다. 그들은 다른 많은 도우미 / 유틸리티 등을 가지고 있기 때문에 Spring 코드에 의존하려는 유혹은 꽤 강합니다.

공연

Pico - Pico 의 속도 특성에 너무 익숙하지 않습니다.

Guice -Guice는 빠르도록 설계되었으며 참조에 언급 된 비교에는 몇 가지 숫자가 있습니다. 확실히 속도가 주요 고려 사항이라면 Guice를 사용하거나 손으로 배선하는 것이 고려되어야합니다.

봄 -봄은 느릴 수 있습니다. 더 빠르게 만들기위한 작업이 있었고 JavaConfig 라이브러리를 사용하면 속도가 빨라질 것입니다.

사용의 용이성

Pico- 구성이 간단합니다. Pico는 몇 가지 자동 배선 결정을 내릴 수 있습니다. 매우 큰 프로젝트로 확장되는 방법이 명확하지 않습니다.

Guice- 구성이 간단합니다. 주석을 추가하고 AbstractModule에서 상속하여 함께 묶습니다. 구성이 최소한으로 유지되므로 대규모 프로젝트에 맞게 확장됩니다.

Spring- 상대적으로 구성하기 쉽지만 대부분의 예제는 구성 방법으로 Spring XML을 사용합니다. Spring XML 파일은 시간이 지남에 따라 매우 크고 복잡해질 수 있으며로드하는 데 시간이 걸립니다. 이를 극복하기 위해 Spring과 수동 크랭크 종속성 주입을 혼합하여 사용하는 것을 고려하십시오.

커뮤니티 규모

Pico- 소형

Guice- 중간

봄 -대형

경험

Pico - Pico에 대한 경험은 많지 않았지만 널리 사용되는 프레임 워크가 아니므로 리소스를 찾기가 더 어려울 것입니다.

Guice -Guice는 인기있는 프레임 워크이며 개발 과정에서 많이 다시 시작하는 대규모 프로젝트가있는 경우 속도에 중점을 두는 것이 좋습니다. 구성의 분산 된 특성에 대한 우려가 있습니다. 즉, 전체 응용 프로그램이 어떻게 결합되는지 확인하기가 쉽지 않습니다. 이 점에서 AOP와 비슷합니다.

봄 -봄은 일반적으로 기본 선택입니다. 즉, XML이 번거로워지고 결과적으로 속도가 느려지 게됩니다. 나는 종종 손으로 만든 Dependency Injection과 Spring의 조합을 사용합니다. 실제로 XML 기반 구성이 필요한 경우 Spring XML이 매우 좋습니다. Spring은 또한 다른 프레임 워크를 더 많이 의존성 주입에 친숙하게 만드는데 많은 노력을 기울였습니다. 이것은 그렇게 할 때 종종 모범 사례를 사용하기 때문에 유용 할 수 있습니다 (JMS, ORM, OXM, MVC 등).

참고 문헌

• 피코
• Guice
• 봄
• 봄 / Guice / Pico 비교
• 또 다른 Spring / Guice 성능 비교

jamie.mccrindle이 제시 한 대답은 실제로 꽤 좋지만 우수한 대안 (Pico와 Guice 모두)을 사용할 수 있다는 것이 꽤 분명 할 때 Spring이 기본 선택 인 이유를 혼란스럽게합니다. IMO Spring의 인기는 절정에 이르렀고 현재는 (Spring 악 대차를 타고 싶어하는 다른 모든 "me too"Spring 하위 프로젝트와 함께) 생성 된 과대 광고에 따라 살아가고 있습니다.

Spring의 유일한 진정한 이점은 커뮤니티 규모 (솔직히 크기와 복잡성으로 인해 필요함)이지만 Pico와 Guice는 솔루션이 훨씬 깨끗하고 조직적이며 우아하기 때문에 거대한 커뮤니티 가 필요 하지 않습니다 . Pico는 Guice보다 더 유연 해 보입니다 (Pico에서 주석을 사용할 수 있는지 여부에 관계없이 매우 효율적입니다). (편집 : 매우 유연하다고 말하고 효율적이지 않다는 의미입니다.)

Pico의 작은 크기와 종속성 부족은 과소 평가되어서는 안되는 중요한 승리입니다. 지금 Spring을 사용하려면 몇 개의 메그를 다운로드해야합니까? 그것은 모든 의존성을 가진 거대한 jar 파일의 엉망진창입니다. 직관적으로 생각하면 이러한 효율적이고 "작은"솔루션은 Spring과 같은 것보다 확장 성과 성능이 더 우수해야합니다. Spring의 부풀림이 정말 확장 성을 향상시킬까요? 이 기괴한 세계인가? 나는 그것이 증명되고 설명 될 때까지 Spring이 "더 확장 가능하다"는 가정을하지 않을 것이다.

때로는 좋은 것을 만들고 (Pico / Guice) 끝없는 새 버전으로 부풀어 오르고 부엌 싱크대 기능을 추가하는 대신 손을 끄는 것이 실제로 효과가 있습니다 ...

참고 : 이것은 답변 이라기보다 댓글 / 폭언에 가깝습니다.

PicoContainer는 훌륭합니다. 그들이 웹 사이트를 고치기 만한다면 나는 그것으로 다시 전환 할 것입니다. 지금은 정말 혼란 스럽습니다.

• http://picocontainer.com 은 가장 최근이지만 많은 페이지에 서식 문제가 있으며 일부 페이지는 전혀 작동하지 않습니다. 페이지가 이전 콘텐츠에서 자동으로 변환 된 것 같습니다.
• http://picocontainer.codehaus.org/ 버전 2.10.2에서 시간이 멈춘 것처럼 보입니다.- 페이지에 "이봐, 당신은 오래된 웹 사이트를보고 있습니다!"와 같은 말을한다면 정말 좋을 것입니다 .
• http://docs.codehaus.org/display/PICO/Home-v 1.x를 문서화 한 confluence wiki이지만 페이지 어디에도 나와 있지 않습니다!

지금은 Guice 2.x가 더 크고 기능도 적지 만 사용하고 있습니다. 문서를 찾는 것이 훨씬 쉬웠고 사용자 그룹이 매우 활동적입니다. 그러나 Guice 3의 방향이 어떤 표시라면 Guice가 부 풀기 시작하는 것처럼 보입니다. Spring이 초기에 한 것처럼.

업데이트 : Pico Container 사람들에게 댓글을 게시했으며 웹 사이트를 일부 개선했습니다. 이제 훨씬 나아졌습니다!

오래된 질문이지만 오늘 은 Android 앱 프로젝트에서 Dagger ( https://github.com/square/dagger )를 고려할 수 있습니다 . Dagger는 컴파일 시간에 코드 생성을 수행합니다. 따라서 시작 시간이 단축되고 실행 시간에 메모리 사용량이 줄어 듭니다.

최소한의 DI 컨테이너를 원한다면 Feather를 확인할 수 있습니다 . Vanilla JSR-330 DI 기능 만 가능하지만 설치 공간 (16K, 종속성 없음) 및 성능면에서 상당히 우수합니다. 안드로이드에서 작동합니다.

PicoContainer가 단순하고 종속성이 부족하기 때문에 좋아하지만. Java EE 표준의 일부이므로 CDI를 대신 사용하는 것이 좋으므로 공급 업체에 종속되지 않습니다.

침입 성 측면에서 가장 큰 문제는 컨테이너의 요구 사항과 상대적으로 빈 META-INF / beans.xml 파일 (jar이 CDI를 사용하고 있음을 나타내는 데 필요함) 및 주석 사용 (표준이지만 )

내 프로젝트에 사용하는 경량 CDI 컨테이너는 Apache Open Web Beans입니다. 이렇게 보이는 간단한 앱 (Pico와 달리)을 만드는 방법을 알아내는 데는 시간이 걸렸습니다.

public static void main(final String[] args) {
    final ContainerLifecycle lifecycle = WebBeansContext.currentInstance()
            .getService(ContainerLifecycle.class);
    lifecycle.startApplication(null);

    final BeanManager beanManager = lifecycle.getBeanManager();
    // replace Tester with your start up class
    final Bean<?> bean = beanManager.getBeans(Tester.class).iterator()
            .next();

    final Tester b = (Tester) lifecycle.getBeanManager().getReference(bean,
            Tester.class, beanManager.createCreationalContext(bean));
    b.doInit();
}