안녕하세요…
구(.NetFrameowrk) 이하로 웹 개발을 주로 하다가 중지하고 스프링을 하고 있는 상황에서 다시 7.0에서 웹 개발을 하려고 합니다.
구(.NetFrameowrk) Asp.net에는 일반적으로 작성을 하다가, 신(.Net)에서는 DI를 자바만큼은 아니지만 많이 기본적으로 사용하는 구조 인 것으로 파악하였습니다.
문제는 예를 들어서 자바에서는 기본적으로 A → B → C → D 순서대로 참조 되었다고 할 경우, A가 B만을 참조하면 C,D 를 참조하지 않고 DI를 하더라도 타입 찾기가 문제가 없어 자유롭게 프로그래밍 할 수 있습니다.
그러나 닷넷에서는 C,D 를 참조하지 않으면 탐 찾기 문제가 해결 되지 않아 A에 B,C,D가 모두 참조되어야 하는 하는 구조죠.
모두 참조한다고 해서 문제가 있는 것은 아니지만 이전 개발 습관 때문인지 그냥 왠지 위화감이 드네요.
코드로 사례를 공유 주시면 도움이 되는 답변을 드릴 수 있을 듯 합니다.
일단,
아닙니다. A가 B만 생성자 매개변수 등으로 참조하면 되는데요. 다른 어떤 사례가 있을까요?
잘이해가 안가지만 DI를 하는데 참조 한다는 개념이 틀린것 같습니다.
스프링을 거의 안해봤지만 스프링과 DI 구조는 비슷했던것 같고
제 경험으로 DI는 프로그램 구동시에 사전 Resist 등록해서 사용합니다.
이걸 해당 클래스 실행될때 의존성을 주입 하는 방식이고요
A->B->C 순서대로 참조 ??
AClass 에서 BClass 의존성을 가지고 있는데 Cclass가 A의 의존성을 받으면
A,B 모두 사용 가능하다는 개념인가요?
제 의견으로는 애초에 이건 잘못된 설계 같습니다 Solid 원칙하의
A클래스의 주입된 의존성은 해당 Class 에서만 활용 가능하고
Scope 의 따른 생명주기를 관리해야 한다고 봅니다.
제가 질문을 잘 이햬했는지 모르지만 A->B->C 이런식으로
동작은 가능하나 좋은 패턴은 아닌것 같습니다.
약간 다른 이야기 입니다.
ASP.NET CORE DI는 Spring Annotaion Injection 과 달리 직접 등록해야 하는 구조 입니다.
즉, ASP.NET CORE에서는 Injection Annotation이 없습니다.
ASP.NET CORE도 Injection은 여러 방향으로 지정할 수 있습니다.
다만, Interface 주입의 경우에만 문제가 없고 Class 주입의 경우 Overflow 에러가 발생할 수 있습니다.
다른분들 말씀처럼 asp.net core라고해서 spring와 비교해서 di에 제약이 있지는 않습니다.
다만 autowired 같은 암시적인 매핑방식을 지원하지 않는 대신 명시적으로 관계와 생명주기를 설정해줘야 된다는 차이가 있을 것 같습니다.
좀더 복잡한 사례들 예를 들면 네임스페이스 전체를 등록하는 등이 필요하다면 scrutor와 같은 패키지로 구성해 보실수 있습니다. GitHub - khellang/Scrutor: Assembly scanning and decoration extensions for Microsoft.Extensions.DependencyInjection
사례를 공유해주면 asp.net core의 환경에 맞는 설정 방식을 논의해볼수 있겠네요.
이어서 예를 든다면 같은 말인지 모르겠지만 자바에서 A에서 D에 선언되어 있는 무언가를 사용하려고 할 경우에 A에서 D를 참조하지 않아도 됩니다. 닷넷 에서는 참조를 해야만 직접 사용 가능하죠. 사실 이게 제 질문의 핵심이고 이것 때문에 DI 전략(DI 적용방법)이 어떠한지가 질문입니다.
코드로 설명하기에는 저의 표현이 부족하네요.
그 부분은 숙지하고 있는 내용입니다. 프로젝트 참조 이야기를 한거예요
아마 구 닷넷을 말씀하시는거 아닐까요?
잘 기억안나는데 닷넷 5.0인가?? 이 쯤부터 개선된걸로 알고있어요
종속성 연결 문제는 현재 없습니다. 저도 가급적 중복된 종속성은 지우고 있습니다.
그런데, 그것보다 더 중요한 프레임워크 간에 비호환 문제는 있습니다.
구 닷넷이 어디까지를 말씀하시는 것인지는 잘 모르겠으나, 현재는
체제로 나뉘어 있습니다. 아마 “.Net Framework” 의 초기 버전을 사용하셨던 것 같네요.
이렇게 나뉜 이유는 마이크로소프트가 윈도우 전용을 포기하고, 크로스 플랫폼에 집중하기로 전략을 변경했기 때문입니다. 윈도우 전용 닷넷은 더 이상 버전업을 하지 않고, 크로스 플랫폼만 버전업을 하여, 현재 .Net 7.0 이 정식으로, .Net 8.0 이 프리뷰로 배포되고 있습니다.
여기서 문제가 되는 것은, 특정 프레임워크만을 위한 라이브러리를 그와 다른 프레임워크에서 사용할 경우 문제가 발생할 가능성이 있습니다.
그래서, 닷넷 용 라이브러리의 메뉴얼을 볼 때, 지원 프레임워크가 무엇인지 항상 먼저 살펴봐야 합니다. 예를 들어, 어떤 라이브러리의 메뉴얼 하단에, 아래와 같이 적혀 있으면,
이 라이브러리는 .Net Core 와 .Net Framework 용 앱에는 사용을 하지 못합니다.
사실, 컴파일러가 명확하게 지원이 안된다는 것을 말해주는 경우도 있고,
말해주지 않았는데도 문제가 없는 경우도 있고,
말해주지 않고 문제가 있는 경우도 있고 그렇습니다.
그런데, 닷넷의 모든 프레임워크에서 사용가능한 라이브러리 작성을 위해 .NetStadard 라는 기준이 있습니다. 그러나, 여기에서도 주의할 게 있습니다.
이 기준의 가장 마지막 버전은 .NetStandard 2.1 이고, 그 직전 버전은 .NetStandard 2.0 입니다.
.NetStandard 2.0 은 그야말로 모든 프레임워크이 준수하지만, 2.1은 윈도우 전용인 .Net Framework는 준수하지 않습니다.
즉, 어떤 라이브러리가 .NetStandard 2.0 용으로 작성되었다면 호환성 문제를 검토하지 않아도 됩니다.
개인적으로는 이렇게 쪼개진 프레임워크들이 닷넷이 인기가 없는 가장 큰 요인이지 않을까합니다.
초보자의 경우, .Net Framework 용 윈폼 프로젝트를 생성해 놓고, 정작 학습은 .Net 용 윈폼 문서를 참조한다던가… 하는 그런 웃픈…
와 이게 되는군요. 제가 한 질문의 근본 문제인데 이게 되는군요…
답변 감사합니다.
스프링과 동일한 패턴으로 가능하겠네요.
다른 분들도 답변 감사드립니다.
이 말씀이 제가 질문한 문제에 대한 답변으로 종속성 문제가 없다는 거군요.
예. 기타 주절주절이 쓴 것은 프레임 호환성 문제를 종속성 문제로 오인할까봐 적은 것입니다.