asp.net에서 Dependency Injection Framework를 사용할 때 조심해야 할 것이 있습니까?

Question

스레딩 문제와 유사합니까? 병목 현상? 메모리 문제?

Answer 1

프레임 워크에 따라 다르지만 일반적으로 아니오라고 말합니다. 하나의 스레드에서 IoC를 구성한 다음 다른 모든 스레드가 IoC에서 읽는 중입니다. 병목 현상이나 메모리 사용량이 걱정된다면 스스로 롤업 할 수 있지만 잘 알려진 대부분의 솔루션에는 이러한 문제가 없습니다.

편집 : 더 많은 정보를 제공하고 내 대답을 명확히하기 위해이 내용을 업데이트 할 것이라고 생각했습니다.

이것은 내 관점이지만 DI 컨테이너의 주요 목적은 유연성과 테스트 가능성입니다. 유연한 관점에서 비즈니스 로직의 구체적인 구현에 대한 참조가 없습니다. 당신이 DI 또는 일부 공장없이 로직의 스케줄링 서비스를 필요한 경우 예를 들어, 다음과 같은 것을 할 필요가있을 것이다 :

:

SchedulingService schedulingService = new SchedulingService(); 

하지만 DI 컨테이너 또는 공장을, 당신은 뭔가를 할 것입니다

ISchedulingService schedulingService = IoC.GetInstance<ISchedulingService>(); 

그리고 구체적인 유형이 아닌 인터페이스 또는 기본 클래스로 프로그래밍하고 있습니다. 미리 정의 된 것을 새로 추가하고 있습니다. 즉, 컴파일 한 후 수정 된 버전을 해당 서비스에 삽입 할 수 있습니다. 이것은 테스트 가능성 인 두 번째 포인트로 연결됩니다. 정말 좋은 점은 비즈니스 로직 클래스는 위의 두 줄 중 하나를 사용하지 않는다는 것입니다. 즉, 이미 알고있는 것처럼 마치 의존성의 메서드 나 속성을 호출 할 수 있습니다. 이것이 성취되는 방법은 시공시의 개체에 대한 의존성을 주입이다

다음 조롱 또는 검사시에 위조 될 수

public UpdateDeployment(ISchedulingServer Scheduler) 
{ 
    _scheduler = Scheduler; 
} 

. 그러나 비즈니스 로직에 당신은 DI 컨테이너에서 종속성을 잡고 비즈니스 오브젝트에 대한 오버로드 기본 생성자를 호출하고 위의 그 생성자 호출 수 : 내가 무엇을했는지 연구에서 말했다 모두와 지금

public UpdateDeployment() : this (IoC.GetInstance<ISchedulingService>()) {} 

DI 컨테이너는 구성을 돕기 위해 주위를 둘러싼 일부 논리가있는 해시 테이블입니다 (실제로 해시 테이블의 해시 테이블이지만 구현 세부 사항입니다). 이것에 대한 자세한 정보와 명확성을 위해 모든 주요 DI 컨테이너가 지원하는 인터페이스를 정의하는 CommonServiceLocator project on CodePlex을 살펴보십시오. 그런 관점에서 보면 메모리 사용 공간과 사이클 시간은 짧아야하지만 사용 방법에 대해 생각해야합니다.

내가 작업 한 프로젝트에서 나는 DI 컨테이너를 두 가지 주요 이유로 사용했다. 첫 번째는 구성 정보입니다. 하나의 예가 연결 문자열입니다. 나는 당신이 web.config에 넣을 수 있다는 것을 알고 있지만, 이것은 A) 전체 웹 스택을 가지고 있어야하고 B) 단위 테스트와 통합 테스트 사이에서 파일을 수정해야하기 때문에 비즈니스 로직 테스트를 제한합니다 . 필자가 작업 한 프로젝트에서 global.asa에 구성된 DI 컨테이너에서 연결 문자열을 주입했습니다.이 컨테이너는 기본적으로 다른 답변에서 설명한 것처럼 싱글 톤을 만듭니다.이것은 참조 유형에도 적용됩니다 (문자열은 참조 유형이지만 많은 사람들이 그 값을 사용하거나 값 유형을 지원한다고 생각합니다). 비즈니스 로직이 상태를 변경하지 않도록해야합니다. . 즉, 속성에 대해서만 getter를 사용하거나 종속성 자체에 부작용이없는 메서드를 호출해야합니다.

두 번째 이유는 서비스 객체를 제공하는 DI를 사용했기 때문입니다. 위의 논리에서와 마찬가지로 SchedulingService는 내가 작업중인 도메인의 논리 덤프입니다. 비즈니스 로직이 사용할 수있는 데이터를 조작하거나 제공하는 서비스를 제공하지만 변경되지는 않습니다. 자체 변경은 시공시에 처리되거나 DI 컨테이너 (참조 카운팅 및 잠금에 대해 걱정할 필요가 있음)에서 처리됩니다. 컨테이너 내부의 데이터가 비즈니스 논리 관점에서 불변이므로 모든 스레딩 문제를 해결합니다.

다른 응용 프로그램에 액세스하는 비즈니스 논리 구성 요소를 사용하는 많은 클라이언트가 액세스하는 ASP 응용 프로그램 또는 응용 프로그램에서 DI는 메모리 풋 프린트 크기를 도울 수 있지만 손상시킬 수도 있습니다. 예를 들어 모든 요청에 ​​대해 인스턴스화해야하는 서비스가 있지만 해당 서비스가 변경 불가능한 경우 개체 X의 메모리 사용 공간을 동시 세션 수로 지정합니다. 하지만 매우 드물게 호출되는 서비스가있는 경우 응용 프로그램을 시작할 때 할당 된 메모리를 갖게되며 사용 대기 중입니다. 내가 작업 한 코드에서 두 번째 이상을 처음 보았습니다.

희망이 있습니다.

Answer 2

중요한 점은 정확한 개체 수명 (싱글 톤 대 prototype - 올바른 기술 용어가 무엇인지 모르는 경우)을 정의하는 것입니다. 그렇지 않으면 문제가되는 스레딩 문제가 발생할 수 있습니다. 병목 현상과 메모리 문제는 DI 프레임 워크와 관련이 없으며 적어도 DI 프레임 워크와 관련된 것은 없었습니다.

Answer 3

이 모든 것들이 걱정이지만 DI 사용 여부와 상관없이 사실입니다.

싱글 톤을 객체에 삽입하는 경우 중 하나 인 공유 상태가 스레드로부터 안전한지 확인하는 것이 중요합니다. 내가 작업 한 프로젝트에서 웹 계층에 유효성 검사 클래스를 주입했습니다. 누군가는 스레드 안전성을 고려하지 않고 매번 데이터베이스로 돌아가는 대신 오브젝트에 값을 캐시하기로 결정했습니다. UI에 잘못된 상태가 표시되어 데이터 멤버가 삭제되면 해결되는 문제가있었습니다.