문제

표준 접근 방식을 따르는 3 층 .NET 서비스 앱이 있습니다.

Frontend -> Object Model / Business Logic -> Data Access

나는 그 과정에서 의존성 주입에 대해 배우려고 노력하고 있으며 지금까지 (Autofac 사용) 훌륭하다는 것을 알았습니다. 3 계층 각각은 각각의 객체를 만들어야하며 때로는 추가 구성/등이 있습니다. DI 컨테이너가 이것을 해결하는 데 이상적인 일인 것 같습니다. 그러나 나는 다른 시스템과 관련하여 어디에 살아야하는지 보는 몇 가지 문제가 있습니다.

현재 DI 컨테이너를 구성하는 프론트 엔드 수업이 있습니다. 기본적으로 큰 코드의 말입니다 container.Register<SomeType>() 등등.

문제는 3 계층 모두에 대한 컨테이너를 구성하고 있으므로 데이터 액세스 계층에 대한 상당히 침습적 인 지식이 있어야한다는 것입니다. 이러한 지식으로 내 프론트 엔드에 코드가 있으면 앱을 계층으로 분리하는 요점은이 정확한 상황을 피하는 것이기 때문에 머리 속의 경보 종을 제거합니다.
이것은 또한 내 데이터 액세스 계층이 SQL Server가 멍청한 비트가 아니라 많은 복잡한 COM 인터 로프 및 P/호출로 구성되어 있기 때문에 DI에 상당히 영향을 미칩니다. 구성.

나는 그것을 분해 할 생각을 주었다 - 아마도 계층 당 하나의 컨테이너가 있거나, 각 계층에 "설정"클래스가 있는데,이 컨테이너와 대화하여 자체 비트를 등록하기 위해 "설정"클래스가 있는데 해결하는 것보다 더 많은 문제가 ...

DI를 멀티 티어 앱과 함께 사용하는 경험을 공유 할 수 있다면 정말 감사하겠습니다.

감사합니다, 오리온.

도움이 되었습니까?

해결책

이것은 3 개의 계층 (물리적 분리)이 있는지 또는 모든 논리적 레이어가 함께 배치되어 있는지에 따라 다릅니다. 프론트 엔드가 BL과 분리되어 웹 서비스 또는 WCF를 통해 통신하는 경우 프론트 엔드와 백엔드에는 별도의 프로세스 나 별도의 기계로 실행되기 때문에 자체 컨테이너가 필요합니다. 컨테이너는 자체 구성 요소와 '다음'레이어의 인터페이스 만 등록합니다.

반면에 모든 레이어가 동일한 프로세스에서 실행되면 하나의 컨테이너 만 있어야합니다. 컨테이너는 웹 앱의 Global.asax와 같은 응용 프로그램의 시작점에서 초기화되고 호스팅됩니다.

컨테이너 호스트가 시스템의 모든 다른 부분에 대해 알고있는 컨테이너 호스트의 문제는 클래스를 하나씩 등록하지 않고 대신 모든 유형을 어셈블리에 등록함으로써 해결할 수 있습니다. 이렇게하면 컨테이너를 구성하기 위해 솔루션의 모든 어셈블리에 대한 강력한 참조가 필요하지 않습니다. Castle Winsdor와 함께 수행 할 수있는 방법의 예 :

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll"));
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top