싱글톤 패턴을 대체하기 위해 고민하던 와중에 DI패턴이라는것을 발견했고
처음엔 젠젝트를 써봤다가
젠젝트는 이제 업뎃도 안되니까 VContainer를 쓰라는 글을 봐서 이걸 설치했는데

내가 쓰는법을 제대로 모르는건지 아니면 원래 VContainer라는게 이런건지 모르겠지만

이걸 제대로 쓰기위한 과정이 너무 병신같다

아래는 라이프스코프 코드임.


원래같으면 팝업매니저는 싱글톤이었겠지

public class GlobalLifetimeScope : LifetimeScope

{

    protected override void Configure(IContainerBuilder builder)

    {


        builder.R_egister<PopupManager>(Lifetime.Singleton);
혹은

        builder.R_egisterComponentInHierarchy<PopupManager>();

    }
(Regi_ster 금지어임)


    protected override void Awake()

    {

        base.Awake();


        DontDestroyOnLoad(gameObject);

    }

}

TryShowUI라는 곳에 팝업매니저를 주입시켰음

public class TryShowUI : MonoBehaviour

{

    [Inject] private readonly PopupManager popupManager;

}

근데 막상 써보려니까 팝업매니저가 null이더라?


왜 이러나 알아보니
젠젝트처럼 Inject로 주입이 호출된다고 해서 무작정 해주는게 아니고
VContainer자체가 주입할 대상 주입당하는 대상 모두 알고 있어야 된다더라?

따라서 TryShowUI에 [Inject]PopupManager를 쓸거면 PopupManager를 관리하는 라이프 스코프,
즉 GlobalLifetimeScope에 TryShowUI도 코르도 추가적인 등록이 필요하다고 함


의존성 관리 명확화의 원칙때문에 이렇게 만들어 놓은거라던데
팀원이 100명이면서 와우 뺨치는 개발규모가 아닌 이상 솔직히 개소리같음.

그리고 클래스 명에서만 봐도 알 수 있듯이 전역적으로 쓰일 걸 관리하려고 만든거였는데
PopupManager를 주입해서 쓰고싶으면 그것도 등록해야 한다? 일단 존나게 병신같다,


보통 싱글톤같은 애들은 굉장히 다양한곳에서 쓰이는 경우가 대부분인데
VContainer에서는 그 모든것들을 코드로 일일히 의존관계를 등록해줘야 한다는 말이잖아?

심지어 코드관계에서만 끝나는게 아니라
실제 프로젝트의 작동 흐름까지 따져보면
이게 프리팹일수도 있는거고
씬에 배치되어있다가 씬이 넘어가면 파괴될 수 있을 가능성도 존재하면서

다시 그 씬에 재진입시 생성될 수 있는데

이런 모든 케이스까지 다 감안하면서 의존관계를 명확히 하자고 코드를 짜야된다는게 맞는건가? 싶음


일단 지금까지 느낀건 뭐 이런 병신같은 구조가 다 있지? 싶고
이론적으로는 의존관계가 명확해지고 암묵적인 결합을 피하기때문에 존나 명확한 설계로 이어진다 라고는 하지만
막상 써보면 실전성은 개나 줘버린 개 좆같은 구조라

플젝이 VContainer에 맞춤화되고 최적화된 구조가 아닌 이상
쓰는게 오히려 독이 된다고 보는데 내 의견이 맞는걸까?

이건 뭐 불편함의 정도가 너무 심해서 과장 안보태고 생산성이 70 ~ 80%는 저하되는 느낌?
개발 자체가 거대한 벽에 가로막히는 느낌임