내장된 ASP.NET Core DI Container보다 타사 DI Container를 사용하는 이유는 무엇입니까?

내장된 ASP.NET Core DI Container보다 타사 DI Container를 사용하는 이유는 무엇입니까?

현재 DI 주제인 종속성 주입에 대한 문서가 부족합니다.(Ninject, Autofac, StructureMap)과 같은 기존 솔루션에 비해 내장 DI를 사용할 경우의 장단점은 무엇입니까?그리고 (있는 경우) 기본 종속성 주입의 현재 제한 사항은 무엇입니까?

느슨한 결합을 실행하고 솔리드 원칙을 따르는 합리적인 크기의 애플리케이션의 제품 개발에는 .NET Core의 DI 컨테이너(MS.DI)가 적합하지 않습니다. 다음과 같은 이유가 있습니다.

• 구성을 확인하는 데 도움이 되지 않으므로 일반적인 잘못된 구성에서 발생하는 문제를 진단하기가 매우 어렵습니다.합리적인 크기의 애플리케이션에서는 이러한 실수를 직접 발견하기가 매우 어렵습니다.UPDATE: 에 MS.DI 버전 3이라는 기능이 되었습니다.ValidateOnBuild모든 등록의 모든 종속성을 충족할 수 있는지 확인하는 것이 유일합니다.
• 절취기나 장식기를 사용하여 횡단 관심사를 유지 관리할 수 없습니다.따라서 적절한 크기의 애플리케이션을 유지 관리하는 데 비용이 더 많이 듭니다.업데이트:그 공백을 메우려고 노력하는 여러 타사 라이브러리가 있지만 MS.DI의 한계로 인해 그 공백을 완전히 메울 수 없습니다(예: 오픈 제네릭 등록 장식, 장식된 인스턴스의 폐기 보장 등).
• MS.DI는 오픈 제네릭 추상화를 오픈 제네릭 구현에 매핑하는 것을 지원하지만, 그 구현은 다소 순진하며 유형 제약, 더 복잡한 제네릭 유형 매핑 및 분산이 있는 제네릭 유형과 함께 작동할 수 없습니다.
• 자동 배선을 사용하는 동안(예: 두 개의 구성 요소가 있는 경우) 특정 소비자에게만 등록이 주입되는 방식으로는 조건부/상황별 등록을 수행할 수 없습니다.Service1그리고.Service2 다 둘다 는의하존에 합니다.ILogger당신은 아마도 주사를 놓는 것이 좋을 것입니다.Service1와 함께NullLogger그리고.Service2와 함께FileLogger아니면 당신이 원하는Service1사를맞을 Logger<Service1>그리고.Service2와 함께Logger<Service2>.

이러한 제한이 존재하는 주된 이유는 보다 성숙한 DI 컨테이너가 프레임워크와 통합할 수 있기를 바라며 특히 프레임워크 자체에 DI 기능을 제공하는 것이 내장 컨테이너의 목표이기 때문입니다.즉, 최소 공통 분모(LCD) 역할을 하려고 합니다.LCD 기능 때문에 애플리케이션 개발에 실용적인(LCD라는 약속을 어기지 않고는) 본격적인 DI Container로 성장할 수 없습니다.

새롭고 간단한 프로젝트로 시작한다면 Pure DI를 적용하는 것이 제 조언입니다.즉, 컨테이너를 사용하지 않고 DI 컨테이너를 만들지 않고 컴포지션 루트 내의 구성 요소를 수동으로 연결할 수 있습니다.대신 사용자 정의 I 컨트롤러 활성화 프로그램을 연결하여 유형을 해결합니다.나중에 자동 배선, 자동 등록 및 가로채기와 같은 기능이 컴포지션 루트의 유지 관리성을 향상시킬 경우 요구 사항에 맞는 설정된 DI 라이브러리 중 하나로 전환합니다.

여기서 설명합니다.

• 일시적 - 매번 새 인스턴스가 생성됩니다.
• 범위 - 현재 범위 내에 단일 인스턴스가 생성됩니다.현재 범위에서 싱글턴과 동등합니다.
• Singleton - 단일 인스턴스가 생성되고 단일 인스턴스처럼 작동합니다.
• 인스턴스 - 특정 인스턴스가 항상 제공됩니다.사용자가 초기 생성에 대한 책임이 있습니다.

알파 버전에는 다음과 같은 제한이 있었습니다.

• 생성자 주입만 지원합니다.
• 하나의 공용 생성자만 있는 유형을 확인할 수 있습니다.
• 스레드 범위별 또는 자동 검색과 같은 고급 기능을 지원하지 않습니다.

만약 당신이 정말 복잡한 제품을 쓰고 있지 않다면, 기본 DI 컨테이너로 충분할 것입니다.다른 경우에는 이미 언급한 고급 기능이 있는 라이브러리를 사용해 볼 수 있습니다.

기본적인 것부터 시작하여 사용할 수 없는 것이 발생할 경우 구현을 변경하는 것이 좋습니다.

추가적으로, 누가 이 등록들 사이의 차이점이 무엇인지 이해하는 것을 도와줄 수 있습니까?

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IService, Service>();
    services.AddScoped<IService, Service>();
    services.AddSingleton<IService, Service>();
    services.AddInstance(service);
}

https://stackoverflow.com/revisions/30681477/8

• 일시적 - 검색할 때마다 인스턴스화됨
• 범위 - http 요청당 한 번씩 인스턴스화되며 http 요청의 수명 동안 사용할 수 있습니다.
• 싱글톤 - 한 번 인스턴스화되며 애플리케이션의 전체 수명 동안 사용할 수 있습니다.
• 인스턴스 - 인스턴스를 만드는 프레임워크 대신 객체 인스턴스를 제공하는 경우를 제외하고 싱글턴과 동일합니다.

출처: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles, http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency-injection-in-6-steps/

범위가 지정된 이유를 좀 더 설명하려면 다음 코드를 고려하십시오.

// app startup
var services = new ServiceCollection();
services.AddScoped<IService, Service>();
var startupServices = services.BuildServiceProvider();
// request init
var requestServices = statupServices.CreateScope().ServiceProvider;

그래서 ASP.NET HttpContext에 있습니다.Request Services는 요청 시작 시 CreateScope가 호출되는 위와 유사한 방식으로 생성됩니다.그러나 ASP.NET 외부의 컨텍스트에서 사용할 수 있으며, 이 경우 스코프가 요청별로 다른 의미를 가질 수 있습니다.

첫 번째 질문에 답하려면: ASP.NET 문서가 업데이트된 것 같습니다. 이제 각 등록 유형이 무엇인지 명확하게 설명합니다.

ASP.NET 서비스는 다음 수명으로 구성할 수 있습니다.

일시적

요청할 때마다 임시 수명 서비스가 생성됩니다.이 수명은 경량 상태 비저장 서비스에 가장 적합합니다.

범위

범위가 지정된 수명 서비스는 요청당 한 번씩 생성됩니다.

싱글턴

Singleton 수명 서비스는 처음 요청될 때 생성되며 이후의 모든 요청은 동일한 인스턴스를 사용합니다.애플리케이션에 싱글톤 동작이 필요한 경우 싱글톤 설계 패턴을 구현하고 클래스에서 개체의 수명을 직접 관리하는 대신 서비스 컨테이너가 서비스 수명을 관리하도록 허용하는 것이 좋습니다.

인스턴스 [사전 RTM만 해당!]

인스턴스를 서비스 컨테이너에 직접 추가하도록 선택할 수 있습니다.이렇게 하면 이 인스턴스가 이후의 모든 요청에 사용됩니다(이 기술은 Singleton 범위 인스턴스를 만듭니다).인스턴스 서비스와 Singleton 서비스의 주요 차이점 중 하나는 서비스 구성에서 인스턴스 서비스가 생성되는 반면 Singleton 서비스는 처음 요청할 때 느리게 로드된다는 것입니다.

---

RTM에서 업데이트됨

Asp에서 이를 확인합니다.NetCore RTM 문서 인스턴스가 제거되었습니다.인스턴스는 기본적으로 Singleton과 동일하지만 초기화 시맨틱이 다릅니다(Singleton은 게으르게 로드되었습니다).그러나 현재 AddInstance API는 없으며 이미 생성된 인스턴스를 취할 수 있는 AddSignleton만 있습니다.

언급URL : https://stackoverflow.com/questions/30681477/why-would-one-use-a-third-party-di-container-over-the-built-in-asp-net-core-di-c