일반적인 IoC 컨테이너는 크로스플랫폼 환경에서는 좋지않다..?

“나는 일반적으로 IoC/DI에 대한 많은 조언이 ‘크로스 플랫폼 모바일 애플리케이션’ 영역에서 꽤 나쁘다고 생각합니다. 많은 아이디어가 모바일 또는 데스크톱 앱이 아닌 웹 앱용으로 작성되었다는 점을 기억해야 하기 때문입니다…
예를 들어, 대중적인 IoC 컨테이너의 대다수는 기본적으로 메모리 사용량이나 시작 시간을 완전히 무시하면서 웜 캐시의 해결 속도에만 관심을 갖습니다. 이것은 중요하지 않기 때문에 서버 애플리케이션에 100% 문제가 없습니다. 하지만 모바일 앱의 경우? 시작 시간이 엄청납니다.
Splat의 서비스 위치는 RxUI에 대한 여러 문제를 해결합니다.
서비스 위치는 빠르며 설정에 대한 오버헤드가 거의 없습니다. Func를 다르게 작성하는 것만으로 여러 가지 일반적인 객체 수명 모델(즉, ‘매번 새로 생성’, ‘싱글톤’, ‘게으른’)을 캡슐화합니다. 코드이지만 PCL 코드에서 사용하십시오.”
아나이스 베츠 @ Stackoverflow

기계 번역이라 내용이 조금 이상하긴 하지만, IoC 컨테이너를 사용하면서 한번도 생각해보지 않았던 부분인데요.
정말 서버 프로그래밍이나 콘솔앱 같은 네이티브앱의 특성을 타지 않는 프로세스에서만 IoC컨테이너가 적합하고, 네이티브 특성을 타는 어플리케이션에서는 IoC 컨테이너가 좋지 못한 것일까요?

물론 네이티브 언어로 작성된 곳에서의 네이티브 IoC 컨테이너라면 해당 플랫폼의 것을 사용할테니 괜찮겠지만, 자마린이나 MAUI에서의 Generic Host 사용을 한다거나, 아니면 다른 크로스 플랫폼 플랫폼에서도 좋지 않을지 궁금하네요.

좋아요 4

링크의 설명은
Splat을 써야 하는가 하는 제목의 글이고

글에서 주장하는 것은 보통의 IoC를 통한 DI는 앱 초기시 모든 객체를 로드 시켜서 메모리 효율성과 로드 시간을 고려하지 않고 있기 때문에 Splat을 써야 한다고 주장하는것 같습니다.
(제네릭 호스트는 타입으로 관리되기에 저런 메모리 효율문제는 없을거 같긴 합니다.)

이 말은 IoC/DI 사용 자체가 나쁘다는 말이 아니고

Splat을 사용하면 위에서 설명했던 부분까지 모두 고려되어 더 좋은 IoC/DI 성능을 낼 수 있다 라고 해석해야 맞는거 같습니다.

타 플랫폼에서도 IoC를 구현할때 지연로드 처리 등을 고려해서 구현한다면 동일하지 않을까 싶습니다.

좋아요 5