의존성 주입 프레임 워크는 의존성 위험을 야기합니까?

의존성 주입을 사용하기 위해 기존 시스템을 리팩토링했으며 그 작업이 순조롭게 진행되었습니다.

얼마 후 많은 사내 라이브러리가 내가 사용한 DI 프레임 워크에 의존한다는 것을 알았습니다. 결과적으로 전체 프로젝트는 이제이 타사 프레임 워크에 의존합니다.

나는 모든 의존성을 공유 라이브러리에 의존 시켜서 모든 의존성을 분리하는 데 아이러니를 보았습니다.

첫 번째 반응은 종속성 프레임 워크를 중심으로 래퍼 라이브러리를 만드는 것이 었습니다. 따라서 필요한 경우이 프레임 워크를 교체 할 수 있습니다. 관련된 작업을 추정 한 후 결과 API가 기존 프레임 워크와 유사하므로 교체가 더 어려워 짐을 깨달았습니다. 그래서 나는 그 생각을 버렸다.

내 관심사는 내가 사용하는 DI 프레임 워크가 더 이상 사용되지 않거나 교체해야한다는 것입니다.

DI로 작업 할 때 프로젝트와 DI 프레임 워크 간의 연결을 줄이는 개발 패턴이 있습니까?

DI 프레임 워크를 사용하면 코드가 해당 항목에 종속되도록 만들 수 있습니다. 실제로 이것은 다른 모든 프레임 워크 또는 기초 라이브러리, 특히 해당 lib가 코드의 어느 곳에서나 사용되는 일부 일반적인 기능으로 프로젝트를 지원할 때 모든 사실에 적용되기 때문에 너무 놀랍습니다. 예를 들어, 특정 UI 프레임 워크 또는 웹 프레임 워크를 사용하기로 결정한 경우 해당 라이브러리를 기반으로 특정 양의 코드를 빌드하자마자이 결정을 변경하기가 어렵습니다. 특정 (비표준) String클래스 를 사용하기로 결정한 경우 나중에 해당 결정을 쉽게 변경할 수 없습니다. 이러한 결정은 구조적인 결정으로, 특정 프로그래밍 언어를 선택하는 것과 같으며 100K 줄 이상의 코드를 작성한 후에 해당 결정을 변경하려고합니다.

모든 코드가 특정 프레임 워크에 의존하는 것은 예상 한대로하고 올바르게 유지 관리하는 한 문제가되지 않을 수 있습니다. 그러나 그렇지 않은 경우 문제가 될 수 있습니다. 이러한 상황을 처리하는 방법에는 몇 가지 전략이 있습니다.

• 몇 년 동안 업데이트 및 새 릴리스를 제공 할 수 있다고 생각하는 공급 업체의 프레임 워크를 선택하십시오.

• 충분한 코드 라인 (및 적절한 라이센스)을 가진 오픈 소스 프레임 워크를 선택하십시오. 따라서 공급 업체가 시장에서 사라지면 자체적으로 유지 관리를 수행 할 수 있습니다

• 자신의 프레임 워크를 작성하십시오

• 공급 업체가 제공되는 한 상황에 따라 생활하고 실제로 사라지면 다른 프레임 워크를 선택하고 새로운 프레임 워크를 사용하여 기존 프레임 워크를 에뮬레이트하는 어댑터를 작성하십시오.

래퍼 라이브러리를 미리 만드는 아이디어는 전혀 새로운 것이 아니지만, 실제로 작동하는지 여부는 알지 못합니다. 미래에 어떤 상황이 발생할지 알 수없는 미래 상황에 대해 가정해야 할 것입니다. "새로운"프레임 워크는 다음과 같습니다. 반면에, 몇 년 전에 위에서 언급 한 어댑터 전략을 적용하여 ~ 120K 줄의 코드로 C ++ 프로젝트에서 완전한 UI 프레임 워크를 성공적으로 교환했습니다.

일반적인 생성자 주입에는 프레임 워크가 전혀 필요하지 않습니다. 잃어버린 유일한 것은 구성 파일에서 종속성을 중앙 집중화하는 기능입니다.

DI 컨테이너는 개체 그래프가 매우 크고 복잡 할 때 사용되는 "엔터프라이즈 소프트웨어"패턴입니다. 응용 프로그램의 95 %가 필요하지 않은 것 같습니다.

DI 프레임 워크가 곧 곧 폐기 될 수 있다고 생각하지 않습니다. 쓸모 없게하려면 어떻게해야합니까?

• 새롭고 똑똑한 패턴의 발명품일까요? 그러나 코드에서 훨씬 더 큰 변화가 필요할 것입니다.
• 언어가 바뀌었을까요? 더 나쁘다.

나는 현재의 DI가 충분히 성숙했으며 거기에서 많은 일이 일어나고 있다는 것을 알지 못한다고 말하고 싶습니다. 언어를 지정하지 않았으므로 Guice에 대해 말하면 눈에 거슬리지 않으며 표준 Java 주석과 함께 작동합니다 (표준화되지 않은 것에 대해서는 자체적으로 사용하지만 거의 필요하지 않습니다). 오픈 소스이며 널리 사용되며 Apache 라이센스가 있습니다. 무엇이 문제 일 수 있습니까?

DI 프레임 워크를 변경하는 것이 다른 라이브러리를 변경하는 것보다 훨씬 쉬울 것이라고 확신합니다 (예 : UI 변경은 훨씬 더 많은 작업을 의미 함).