4장에서 알아볼 많은 기능은 스프링에 국한된 기능이므로 다른 IoC는 대부분 이런 기능을 지원하지 않습니다. 물론 많은 IoC 컨테이너가 빈의 라이프사이클 관리 기능을 제공하지만, 대부분은 스프링과 다른 인터페이스를 사용합니다. 개발하려는 애플리케이션이 다른 IoC 컨테이너에서 동작해야 하는 이식성(Portability)이 매우 중요하다면 애플리케이션이 스프링과 결합하는 일부 기능은 사용을 피해야 합니다.

하지만 애플리케이션을 여러 IoC 컨테이너에 문제없이 이식할 수 있어야 한다는 제약사항이 생기면 스프링이 제공하는 풍부한 기능을 사용하지 못하게 된다는 점을 잊지 말아야 합니다. 스프링을 사용하겠다고 전략적인 선택을 한 이상 스프링이 제공하는 기능을 최대한 활용하는 것이 바람직합니다.

그러므로 구체적인 이유 없이 이식성을 요구사항으로 넣지 않도록 주의해야 합니다. 일반적으로 애플리케이션을 사용할 일반 사용자는 해당 프로그램이 세 개의 서로 다른 IoC 컨테이너에서 돌아갈 수 있는지 여부는 신경 쓰지 않습니다. 그저 애플리케이션이 잘 돌아가기만 하면 됩니다. 경험에 미뤄 볼 때 선택한 기술에서 사용할 수 있는 최소 공통 기능만을 사용해 애플리케이션을 구축하는 것은 종종 잘못 판단한 것으로 드러났습니다. 이런 제약사항은 애플리케이션 개발 시작부터 불리하게 작용합니다. 이렇게까지 검토했는데도 애플리케이션에 IoC 컨테이너 간 이식성이 필요하다면 이를 잘못된 것으로 바라보면 안 됩니다. 이런 상황이라면 이식성은 애플리케이션이 반드시 충족해야 할 요구사항이기 때문입니다. <Expert One-on-One: EJB 없이 개발하기>(Wrox, 2004) 책에서 Rod Johnson과 Jürgen Höller는 이와 같은 요구사항을 실체 없는 요구사항으로 보고 이런 요구사항을 자세히 설명한 뒤 어떻게 이런 요구사항이 프로젝트에 영향을 미치는지 상세히 설명하고 있습니다.