ASP.NET 코어 의존 주입(구조 함수 주입,속성 주입 등)
10168 단어 C#
구조 함수 주입
구조 함수 주입 은 서비스 구축 에 있어 서 서비스 의존 을 정의 하고 가 져 오 는 데 자주 사용 된다.예 를 들 면:
public class ProductService
{
private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository)
{
_productRepository = productRepository;
}
public void Delete(int id)
{
_productRepository.Delete(id);
}
}
ProductService 는 IProductRepository 를 구조 함수 에 의존 한 다음 Delete 방법 내부 에서 이 의존 도 를 사용 합 니 다.
실천 지침:
속성 주입
ASP.NET Core 의 표준 의존 주입 용 기 는 속성 주입 을 지원 하지 않 습 니 다.하지만 다른 용 기 를 사용 하여 속성 주입 을 지원 할 수 있 습 니 다.예 를 들 면:
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Logging.Abstractions;
namespace MyApp
{
public class ProductService
{
public ILogger Logger { get; set; }
private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository)
{
_productRepository = productRepository;
Logger = NullLogger.Instance;
}
public void Delete(int id)
{
_productRepository.Delete(id);
Logger.LogInformation(
$"Deleted a product with id = {id}");
}
}
}
ProductService 는 공개 setter 가 있 는 Logger 속성 을 정의 합 니 다.
주입 용기 에 의존 하면 Logger 속성 을 설정 할 수 있 습 니 다.사용 가능 하 다 면(DI 용기 에 등록 되 어 있 습 니 다).
실천 지침:
서비스 포 지 셔 닝 머 신
서비스 포 지 셔 닝 모드 는 의존 관 계 를 얻 는 또 다른 방식 이다.예 를 들 면:
public class ProductService
{
private readonly IProductRepository _productRepository;
private readonly ILogger _logger;
public ProductService(IServiceProvider serviceProvider)
{
_productRepository = serviceProvider
.GetRequiredService ();
_logger = serviceProvider
.GetService>() ??
NullLogger.Instance;
}
public void Delete(int id)
{
_productRepository.Delete(id);
_logger.LogInformation($"Deleted a product with id = {id}");
}
}
ProductService 가 주입 되 었 습 니 다. IServiceProvider 의존 도 를 분석 하고 사용 합 니 다.요청 한 의존 도가 등록 되 지 않 으 면 GetRequired Service 에 이상 이 발생 합 니 다.이 경우 GetService 는 null 로 만 돌아 간 다 는 얘 기다.
구조 함수 내부 에서 서 비 스 를 분석 할 때 서비스의 방출 에 따라 방출 됩 니 다.따라서 구조 함수 내부 에서 해 석 된 서비스의 방출 문제(구조 함수 주입 과 속성 주입)에 관심 을 가 질 필요 가 없다.
실천 지침
서비스 수명 주기
다음은 서비스 가 ASP.NET Core 의존 주입 에서 의 수명 주기 입 니 다.
DI 용 기 는 해 석 된 모든 서 비 스 를 지속 적 으로 추적 합 니 다.서비스의 생명주기 가 종 료 될 때,그것들 은 방출 되 고 소 멸 될 것 이다.
하면,만약,만약... IDisposable 인터페이스,Dispose 방법 은 서비스 가 풀 릴 때 자동 으로 호출 됩 니 다.
실천 지침:
방법 체 에서 서 비 스 를 분석 하 다.
어떤 경우 에는 서비스의 어떤 방법 에서 다른 서 비 스 를 분석 해 야 할 수도 있 습 니 다.이 경우 사용 후 이 서 비 스 를 풀 어 주 십시오.이것 을 보장 하 는 가장 좋 은 방법 은 서비스 역할 영역 을 만 드 는 것 이다.예 를 들 면:
public class PriceCalculator
{
private readonly IServiceProvider _serviceProvider;
public PriceCalculator(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public float Calculate(Product product, int count,
Type taxStrategyServiceType)
{
using (var scope = _serviceProvider.CreateScope())
{
var taxStrategy = (ITaxStrategy)scope.ServiceProvider
.GetRequiredService(taxStrategyServiceType);
var price = product.Price * count;
return price + taxStrategy.CalculateTax(price);
}
}
}
PriceCalculator 는 구조 함수 에 IServiceProvider 를 주입 하고 필드 에 값 을 부여 합 니 다.그리고 PriceCalculator 는 Calculate 방법 내부 에 하위 서비스 역할 영역 을 만 들 었 습 니 다.이 역할 영역 사용 scope.Service Provider 는 주입 한 대신 서 비 스 를 분석 합 니 다.serviceProvider 인 스 턴 스.따라서 using 구문 이 끝나 면 이 역할 영역 에서 분 석 된 모든 서 비 스 는 자동 으로 방출 되 고 소각 된다.
실천 지침:
하면,만약,만약... IServiceProvider 는 매개 변수 로 서 서 서 비 스 를 직접 분석 할 수 있 으 며 서비스의 방출 과 소각 에 관심 을 가 질 필요 가 없습니다.서비스 역할 영역 을 만 들 고 관리 하 는 것 은 방법 을 호출 하 는 코드 의 역할 입 니 다.이 원칙 을 따 르 면 너의 코드 를 더욱 깨끗하게 할 수 있다.
단일 서 비 스 는 일반적으로 응용 프로그램의 상 태 를 유지 하 는 데 사용 된다.캐 시 는 응용 프로그램 상태의 좋 은 예 입 니 다.예 를 들 면:
public class FileService
{
private readonly ConcurrentDictionary _cache;
public FileService()
{
_cache = new ConcurrentDictionary();
}
public byte[] GetFileContent(string filePath)
{
return _cache.GetOrAdd(filePath, _ =>
{
return File.ReadAllBytes(filePath);
});
}
}
FileService 는 디스크 읽 기 를 줄 이기 위해 파일 내용 을 간단하게 캐 시 했 습 니 다.이 서 비 스 는 하나의 예 로 등록 되 어야 합 니 다.그렇지 않 으 면 캐 시가 예상 한 대로 작 동 하지 않 을 것 입 니 다.
실천 지침:
Scoped 서비스
Scoped 라 이 프 사이클 의 서 비 스 는 모든 웹 요청 데 이 터 를 저장 하 는 좋 은 방법 으로 보 입 니 다.ASP.NET Core 는 모든 웹 에 서비스 역할 영역 을 만 들 기 를 요청 하기 때 문 입 니 다.따라서 서 비 스 를 Scoped 로 등록 하면 웹 요청 기간 에 공유 할 수 있 습 니 다.예 를 들 면:
public class RequestItemsService
{
private readonly Dictionary _items;
public RequestItemsService()
{
_items = new Dictionary();
}
public void Set(string name, object value)
{
_items[name] = value;
}
public object Get(string name)
{
return _items[name];
}
}
Requestitems 서 비 스 를 Scoped 로 등록 하고 서로 다른 서비스 에 주입 하면 다른 서비스 에서 추 가 된 항목 을 얻 을 수 있 습 니 다.같은 RequestItems Service 의 인 스 턴 스 를 공유 하기 때 문 입 니 다.이것 이 바로 우리 가 Scoped 서비스 에 대한 기대 이다.
하지만!!!사실 이 항상 그런 것 은 아니다. 하위 서비스 역할 도 메 인 을 만 들 고 하위 역할 도 메 인 에서 RequestItems 서 비 스 를 분석 하면 RequestItems Service 의 새로운 인 스 턴 스 를 얻 을 수 있 으 며 원 하 는 대로 작업 하지 않 습 니 다.따라서 Scoped 서 비 스 는 항상 모든 웹 이 하나의 인 스 턴 스 를 요청 하 는 것 을 의미 하 는 것 은 아니다.
당신 은 이렇게 뚜렷 한 실 수 를 하지 않 을 것 이 라 고 생각 할 수 있 습 니 다.그러나 이것 은 잘못 이 아니 라 상황 이 이렇게 간단 하지 않 을 수도 있다.만약 당신 의 서비스 간 에 큰 의존 관계 가 있다 면,당신 은 누군가가 하위 역할 영역 을 만 들 고 다른 주 입 된 서비스 에서 서 비 스 를 분 석 했 는 지 모 르 겠 습 니 다....................................................
실천 지침:
주입 에 의존 하 는 것 은 처음에는 사용 하기 쉬 워 보이 지만 엄격 한 원칙 을 따 르 지 않 으 면 잠재 적 인 다 중 스 레 드 문제 와 메모리 누 출 문제 가 있 을 수 있다.내 가 공유 하 는 이 실천 지침 들 은 내 가 ABP 프레임 워 크 를 개발 하 는 동안 의 개인 적 인 경험 을 바탕 으로 한다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
WebView2를 Visual Studio 2017 Express에서 사용할 수 있을 때까지Evergreen .Net Framework SDK 4.8 VisualStudio2017에서 NuGet을 사용하기 때문에 패키지 관리 방법을 packages.config 대신 PackageReference를 사용해야...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.