Gomsu
1
서비스 등록을 위해 매번 builder.Services.AddXXX<>() 를 반복하는 것이 불편해서 Attribute 기반 의존성 자동 주입 라이브러리 (AttributeAutoDI)를 만들어 봤습니다 ! …
dotnet add package AttributeAutoDI --version 1.0.1
주요 기능
[Singleton]
public class MyService : IMyService { }
애트리뷰트를 인식하고 통해 라이브러리가 등록을 대신 해줍니다
builder.Services.AddSingleton<IMyService, MyService>();
이외에도 주요기능은 다음과 같습니다
[Singleton], [Scoped], [Transient] 클래스 의존성 자동 등록[Primary] 지정 시 다중 구현체 중 기본값 자동 지정[Named] 지정 후 파라미터에 [Named("...")]로 명시적 주입[Options()] 지정 시 IOptions 자동 바인딩 ![PreConfiguration] , [PostConfiguration] 클래스 하위의 , [Execute] 메서드를 통해서 설정 메서드 실행
더 자세한 내용이 궁금하시다면 Github, Nuget 참고해주시길 바랍니다 !!
많이 부족하지만 도움이 되었으면 합니다 ㅎㅎ…
피드백 많이 주시면 정말 감사하겠습니다 !..
6 Likes
al6uiz
2
물론 편리해 보이기는 합니다 ㅎㅎ
하지만 "객체가 자신의 의존 구성을 알고 있다"는 말은, 클래스 내부에서 어떤식으로 구현체가 주입될지를 미리 알고 있거나 결정하고 있다는 뜻입니다.
이는 본래 의존성 주입(DI) 이 지향하는 목적성과 정면으로 대치됩니다. DI의 핵심은 외부에서 객체의 의존성을 조립해 주는 것이지, 객체가 스스로 그 정보를 결정하고 있어서는 안 될 것입니다. 
3 Likes
Gomsu
3
스프링을 주로 했어서 여기서 편리한 기능들을 가져왔던건데
DI 관점에 대해서는 생각을 못했네요 !
말씀 감사합니다 !!
1 Like
Gomsu
5
스프링의 선언적 DI 스타일에 익숙해져있어서요 ㅎ ㅎ
하지만 닷넷에서 추구하는 방향과 다르고 + 라이브러리 의존적 이 지점에서 우려하는 의견을 많이 받고 있습니다
1 Like
rkttu
6
참고로 닷넷에서는 Native AOT 사용까지 고려했을 때 리플렉션은 "안 쓰는 방향"으로 많이 이야기합니다. 그래서 구현하신 어트리뷰트 기반의 주입은 Future-proof한 방향은 아니라는 점도 고려하시면 좋을 것 같습니다.
Source Generator 같이 컴파일 타임에서 모든 사항을 결정하는 형태로 만들어지는 것이 권장되는 배경도 그 때문이라고 보시면 좋을 것 같습니다. 
4 Likes
Gomsu
7
Source Generator로 구현하는것이 어떠냐고 얘기하시는 분들이 꽤 있었는데 그런 히스토리가 추가적으로 있엇군요 !…
말씀 감사합니다 !!
3 Likes