컴파일 타임 IOC

컴파일 타임에 IOC를 수행하는 프로젝트를 시작한 사람이 있습니까 (Roslyn 또는 Linq MethodInfo emit 사용)?

IOC 컨테이너에 대한 나의 경험은 지금까지 몇 가지 작은 문제를 제외하고 훌륭했습니다.

많은 분해능 로직이 여기에서 발생하므로 많은 IOC 컨테이너가 느리게 시작됩니다.
컴파일이 더 이상 생성자를 호출 할 수 없기 때문에 해결이 가능한지 종종 확인하기가 어렵습니다.
IOC 컨테이너는 종종 런타임에 작은 오버 헤드를 추가합니다 (일부는 작지 않은 경우가 많음).

이상적인 해결책은 IOC 대신 Factory 클래스를 추가하는 빌드 단계에 컴파일 단계를 추가하는 것 같습니다.

아무도 전에 이것을 한 적이 있습니까? 그렇지 않다면 왜 안됩니까?

c# meta-programming inversion-of-control

— 기예
소스

답변:

이렇게하는 것은 그렇게 문제가되지 않아야합니다. 동일한 IoC 로직을 실행하고 클래스를 인스턴스화하는 대신 인스턴스화하는 코드를 생성합니다.

그러나 이렇게하면 IoC의 큰 장점 중 하나가 제거됩니다. 전체 응용 프로그램을 다시 컴파일하지 않고도 구성 요소의 구성 방식을 변경할 수 있습니다. 구성을 바꾸는 것만으로 응용 프로그램이 다른 서비스 또는 데이터 소스를 사용하도록 할 수 있습니다. 그리고이 기능을 최대한 활용하는 애플리케이션은 아직 보지 못했지만 여전히 IoC 성공의 주요 부분입니다.

— 크게 기쁘게
소스

예, 가능하다는 것을 알고 있습니다. 그러나 나는 그것을하는 IoC 컨테이너를 아직 보지 못했습니다. 또한 현재 추세는 코드 (유창한 API)에 등록하는 것으로 보입니다. 그것을 감안할 때, 나는 IoC 컨테이너를 작성하는 것을 고려하고 있습니다.

— ArTs

히로 ( github.com/philiplaureano/Hiro )가 컴파일 타임에 그 일을 할 수도 있다는 것을 기억 합니다.

— lzcd

"하지만 이렇게하면 IoC의 큰 장점 하나를 제거 할 수 있습니다. 전체 응용 프로그램을 다시 컴파일하지 않고도 구성 요소의 구성 방식을 변경할 수 있습니다." 이것을 전체 응용 프로그램에 적용하는 것은 지나친 것 같습니다. 애플리케이션의 모든 부분을 플러그인으로 전환합니다. 또한 두 기술 모두 공존 할 수 있어야합니다. 컴파일 타임에 일부 컴포넌트를 런타임에 연결할 수없는 이유는 없습니다.

— Doval

나는 그것이 어떻게 큰 이점인지 알지 못한다. 런타임시 어떤 컨텍스트에서 구성 요소를 완전히 대체합니까? 몇 가지 구성 사용 사례가 있습니까?

— andyczerwonka

Java / Android 용 Dagger가이를 수행합니다. 대부분의 런타임 오류를 컴파일 오류로 변환하는 것을 포함하여 거의 완전한 컴파일 타임 코드 생성 경험을 제공하기 위해 Guice와 같은 런타임 마술을 희생합니다.

.NET에서도 멋질 것입니다.

— 오리 프
소스