컴파일 시간으로 구성된 종속성 반전 ASP.NET MVC 4 솔루션의 종속성 삽입

Question

필자는 종속성 반전 원칙을 따르고 구성된 종속성 주입 (DI) 컨테이너를 사용하는 MVC 4 웹 솔루션을 설계하는 방법을 연구했습니다. 유창하게 (즉, 컴파일 타임 타입 검사와 함께).

많은 예제들 ASP.NET MVC 4 Dependency Injection MVC 프레임 워크가 제공하는 진입 점에 DI를 구현하는 방법에 중점을 두었습니다. 결과적으로 계층화 된 접근법 (빨간색 화살표로 표시된 종속성)으로 끌리는 것을 느낍니다. 불행히도 상위 모듈이 저수준 모듈에 종속되는 기존 종속성 모델을 반복합니다. Dependency Inversion의 원칙에 따라 IService 인터페이스가 WebProject로 이동합니다. '지금 내가 할 수있는 (컨테이너를 부트 스트랩하는 방법의 문제로 날 떠나

: 가 CompositionRoot가 자신의 프로젝트로 이동 순환 참조를 방지하려면 : 불행하게도이 두 프로젝트 간의 순환 참조를 생성 직접 WebProject 내에서 그것을 참조하지 마십시오)?

약간의 도움으로 the best way to get the directory from which an assembly is executing에서 리플렉션을 통해 초기화 할 수 있습니다.

var assembly = System.Reflection.Assembly.LoadFile(Helper.AssemblyDirectory + "/DependencyInjectionProject.dll"); 
var type = assembly.GetType("DependencyInjectionProject.Bootstrapper"); 
IDependencyResolver resolver = (IDependencyResolver)type.GetMethod("Initialise").Invoke(null, null); 
DependencyResolver.SetResolver(resolver); 

건물을 쉽게 만들려면 DependencyInjectionProject의 빌드 대상을 WebProject bin 디렉토리로 설정했습니다. 나는 내 목표를 만났다. 거꾸로 된 종속성을 확인하고 컨테이너 구성을 검사 한 시간을 컴파일하지만 IIS Express에서 WebProject를 실행할 때 자주 발생하는 대상 충돌 때문에이 접근 방식에 만족하지 않습니다.

저는 이러한 요구 사항을 충족시키기위한 다른 경험과 접근법에 대해 매우 관심이 있습니다. 컴파일 시간 설정을 생략하고 텍스트 기반의 구성을 채택해야합니까? 내가 볼 수없는 순환 종속성의 함정을 피하는 레이어의 명확한 구조가 있습니까?

Answer 1

구성 루트는 DI 컨테이너와 다릅니다. 작성 루트는 실행 파일의 초기 엔트리 레벨이며 DI 컨테이너가 여기에 배치됩니다.

DI 컨테이너가 들어있는 이유 중 하나는 엔트리 레벨이 다른 클래스에서 호출되지 않기 때문입니다. 따라서 DI 컨테이너를 생성하면 DI 컨테이너가 초기 호출시 빌드되고 null 참조 예외를 방지합니다. 다른 이득이 있을지도 모르지만 나는 다만 그것을 모른다.

제가 보통 사용하는 적층 설계이며, 구성 (문헌 1)

서비스 (문헌 1 및 2)

DAL (참조

1. 도메인 모델 (엔티티)
2. 인터페이스 1, 2)
3. UI (기준 1,2,3,4)

이 DESI gn은 양호한 SOC를 선호해야하며 UI가 리포지토리에 직접 액세스하지 못하게 할 수 있습니다. dal은 서비스와 UI를 알지 못합니다. 이 서비스는 DAL 및 UI에 대해 알지 못합니다.

내가 알고있는 한 가지 단점은 UI가 서비스없이 DAL에 직접 액세스 할 수 있도록 허용한다는 것입니다.

나는 아직도이 디자인의 다른 죄수를 몰라.

Answer 2

IService를 웹 프로젝트로 옮기고 싶지 않을 것입니다. 순환 참조 (별도로 거래 차단기는 아니지만, VS는 사용자가 할 수 없지만 여러 가지 다른 방법으로 수행 할 수 있음)를 제외하고는 잘못된 디자인입니다.

낮은 레벨의 모듈에 따라 상위 모듈에 아무런 문제가 없습니다. 왜 이것이 문제라고 생각하는지 모르겠습니다. 종속성 역변환은 실제로 모듈 또는 어셈블리 종속성을 나타내지 않으며 인터페이스 종속성을 나타냅니다. (나는 인터페이스 키워드에 대해 구체적으로 말하지 않고 일반적으로 여기에서 말하고있다.) 실제로 DI를 별도의 어셈블리없이 만들 수 있습니다 ... 모두 같은 어셈블리에있을 수 있습니다.

그러나 구현을 개별 어셈블리로 분할하는 경우에는 특정 제한이 있습니다. 이는 주로 어셈블리 시스템의 구현 문제입니다.

모듈 종속성의 문제점은 실제로는 두 개의 모듈만으로는 나타나지 않습니다. 3 세 이상이되면 문제가됩니다.

나는 양파 아키텍처를 직접 사용하고 싶습니다. 이 방법에서는 인터페이스와 일반 형식 (예 : 엔터티)이 포함 된 별도의 어셈블리가 있습니다. 이 어셈블리에는 많은 코드가 없으며 대부분 정의에 불과합니다.

이상은 데이터 영역과 비즈니스 계층입니다. 이는 엔티티와 인터페이스에 대한 공통 어셈블리에 따라 다릅니다. 그런 다음 비즈니스 계층 (또는 비즈니스 계층의 정면 인 서비스 계층)과 공통 계층에 따라 UI 레이어가 생깁니다.

이 방법을 사용하면 UI가 DAL과 통신 할 수 없으며 그 반대의 경우도 마찬가지입니다. 비즈니스 계층은 DAL 및 UI와 대화합니다. 그리고 모든 것은 기능 코드가 거의없는 엔티티, DTO 및 인터페이스가있는 공통 인터페이스 어셈블리에 달려 있습니다. 따라서 공통점은 .NET .NET의 핵심 요소에 달려 있습니다.

UI <--------> Service/Business <--------> DAL 
    |     |      | 
    +----------> Common (IService) <----------+ 

없음 순환 참조, 모두가 그들이 원하는 유일한 회담이 누구에게 그들이 필요 무엇을 가져옵니다.