세 메커니즘 중 어느 것을 사용하더라도 스프링은 생성 이후와 소멸 이전 이벤트를 동일하게 통지합니다. 인터페이스 기반 메커니즘은 스프링 프레임워크 전반에서 광범위하게 사용됩니다. 따라서 스프링 컴포넌트를 사용할 때 개발자가 별도로 컴포넌트의 초기화나 소멸을 신경 쓰지 않아도 됩니다. 하지만 개발자가 빈을 작성할 때 메서드 기반 메커니즘이나 애너테이션 기반 메커니즘을 이용하는 것이 더 바람직한데, 이렇게 하면 스프링에 특화된 어떤 인터페이스도 구현할 필요가 없기 때문입니다. 많은 책에서 중요하다고 강조한 이식성 관련 요구사항이 사실 그렇게 중요하지는 않다고 앞서 언급하긴 했지만, 그렇다고 해서 이식성을 달성할 좋은 대안이 있는데도 이식성을 포기하라는 뜻은 아닙니다. 그보다는 스프링이 제공하는 데이터베이스 관련 기능이나 웹 기능을 사용하는 것처럼 다른 방식으로 애플리케이션을 스프링과 결합시키고 있다면, 인터페이스 메서드를 사용해 라이프사이클 콜백 메서드를 지정하고 빈의 초기화 및 소멸 이벤트 설정은 신경 쓰지 않아도 됩니다. 또한, 라이프사이클 통지가 필요한 동일 타입 빈을 대량으로 정의해야 할 때 XML 구성 파일을 사용하면 모든 빈의 라이프사이클 콜백 메서드를 일일이 지정해야 하지만, 인터페이스 메커니즘을 사용하면 별도 설정 작업이 필요하지 않습니다. 한편 JSR-250에 정의된 애너테이션을 적용하는 방법도 선택할 수 있습니다. JSR-250은 JCP(Java Community Process)에 정의된 표준이기 때문입니다. JSR-250 애너테이션을 적용하면 애플리케이션이 스프링에 정의된 애너테이션에 종속되지 않습니다. 애플리케이션을 실행할 IoC 컨테이너가 JSR-250 표준을 따르는지만 확인하면 됩니다.

결국 라이프사이클 통지를 받을 때 어떤 메커니즘을 사용할지는 애플리케이션 요구사항에 달려 있습니다. 이식성을 신경 쓰거나 특정 종류의 빈 한두 개만을 정의한다면 메서드 기반 메커니즘을 사용합니다. 애너테이션 기반 구성을 사용하면서 사용 중인 IoC 컨테이너가 JSR-250을 지원하면 애너테이션 메커니즘을 사용합니다. 이식성에 크게 구애받지 않거나 라이프사이클 통지가 필요한 동일 타입 빈을 다수 정의해야 한다면 인터페이스 기반 메커니즘이 가장 좋은 방법입니다. 만약 빈을 다른 여러 스프링 기반 프로젝트에서 사용하려면 가능한 한 별도 구성 작업이 필요 없도록 빈 자체에 모든 것을 담고자 할 것이며 이때는 두말할 것 없이 인터페이스 기반 메커니즘을 사용하는 게 좋습니다.