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개의 좋아요
물론 편리해 보이기는 합니다 ㅎㅎ
하지만 "객체가 자신의 의존 구성을 알고 있다"는 말은, 클래스 내부에서 어떤식으로 구현체가 주입될지를 미리 알고 있거나 결정하고 있다는 뜻입니다.
이는 본래 의존성 주입(DI) 이 지향하는 목적성과 정면으로 대치됩니다. DI의 핵심은 외부에서 객체의 의존성을 조립해 주는 것이지, 객체가 스스로 그 정보를 결정하고 있어서는 안 될 것입니다. 
3개의 좋아요
Gomsu
3
스프링을 주로 했어서 여기서 편리한 기능들을 가져왔던건데
DI 관점에 대해서는 생각을 못했네요 !
말씀 감사합니다 !!
1개의 좋아요
Gomsu
5
스프링의 선언적 DI 스타일에 익숙해져있어서요 ㅎ ㅎ
하지만 닷넷에서 추구하는 방향과 다르고 + 라이브러리 의존적 이 지점에서 우려하는 의견을 많이 받고 있습니다
1개의 좋아요
rkttu
6
참고로 닷넷에서는 Native AOT 사용까지 고려했을 때 리플렉션은 "안 쓰는 방향"으로 많이 이야기합니다. 그래서 구현하신 어트리뷰트 기반의 주입은 Future-proof한 방향은 아니라는 점도 고려하시면 좋을 것 같습니다.
Source Generator 같이 컴파일 타임에서 모든 사항을 결정하는 형태로 만들어지는 것이 권장되는 배경도 그 때문이라고 보시면 좋을 것 같습니다. 
4개의 좋아요
Gomsu
7
Source Generator로 구현하는것이 어떠냐고 얘기하시는 분들이 꽤 있었는데 그런 히스토리가 추가적으로 있엇군요 !…
말씀 감사합니다 !!
3개의 좋아요