.Net의 비 MVC 프로젝트에서 IoC를 설정하는 것이 가치가 있습니까?

Question

어디에서나 Windsor 또는 Spring.net에 대한 정보를 항상 MVC를 참조하여 찾습니다. 웹 양식 프로젝트 또는 wcf 용으로 구현하려고하는 점이 있습니까?

Answer 1

ASP.NET MVC 웹 응용 프로그램의 특성은 요청을 처리하는 방식 때문에 IoC에 매우 적합합니다. 웹 응용 프로그램의 시작 요청 요청 수명주기와 ASP.NET MVC가 이러한 작업을 처리하는 방식은 Krzysztof Koźmic이 The Three Calls Pattern이라고 부르는 내용과 Mark Seemann이 Register Resolve Release pattern이라고 부르는 내용과 직접적으로 관련이 있다고 말할 수 있습니다.

에 직접 패턴을 적용하지 않는 경우에도이 패턴을 따르는 방법이 있습니다. 윈폼 응용 프로그램, Windows 서비스 등

<shameless_plug>

난 당신의 코드가없는, 컨테이너가 호출 될 진정으로 IOC의 스타일을 허용 윈저의 기능입니다 성 윈저의 TypedFactoryFacility이 그것을 알고에 대해 a blog post를 작성한다.

입력 된 공장 시설로 인해 Windsor는 예를 들면 다음과 같은 인터페이스를 동적으로 구현할 수 있습니다. ISomeFactory, 아래에 컨테이너의 Resolve 메서드에 대한 호출을 위임하므로 코드가 ISomeFactory 인터페이스에만 의존 할 수 있습니다.

</shameless_plug 제어의 >

Answer 2

IoC는 프로젝트의 종류에 상관없이 유용합니다. 문제가 해결되면 (테스트 가능성 등 ...) 특정 프로젝트 종류에만 국한되지 않습니다.

Answer 3

예, 아키텍처에서 호출하거나 허용하는 경우 사용 된 UI 프레임 워크뿐만 아니라 전체 애플리케이션의 디자인에 달려 있습니다.

예를 들어, WebForms 프로젝트가 코드 숨김으로 모든 것을 던지고 Page_Load 등에서 데이터베이스에 직접 액세스하는 경우 IoC (또는 모든 종류의 리 팩터링)를 사용하는 것이 어려워 질 것입니다.

그러나 WebForm이 서비스에 액세스하거나 서비스에 액세스하거나 리포지토리 등을 사용하는 모델과 상호 작용하는 경우 해당 백엔드 개체에는 IoC와 같은 종류의 서비스 로케이터가 삽입 될 수 있습니다 뼈대. WebForms 클래스의 생성자에 연결하는 것은 쉽지 않을 수도 있습니다 (또는 내가 시도한 적이 없다고 생각합니다).하지만 필요에 따라 클래스 내에서 종속성을 해결할 수 있습니다 (예 : 지연 바인딩 된 클래스 속성).

Answer 4

IoC는 MVC와 전혀 관련이 없습니다. 두 가지 완전히 다른 디자인 패턴입니다.

응용 프로그램에서 IoC를 사용하는지 여부는 디자인에 따라 다릅니다. 야기? 그럼 잊어 버려. 테스트를 어렵게 만드는 클래스 간의 많은 의존성? 즉시 등록하십시오.

IoC 프레임 워크는 응용 프로그램을 구현하는 데 사용하는 디자인 패턴의 종류를 신경 쓰지 않습니다. 그래서 MVC 또는 귀하의 aspx 파일 안에 코드의 10k 라인, 그건 중요하지 않습니다.

Answer 5

반전 (일명, 의존성 삽입 (Dependency Injection) 또는 제 3 자 연결은) 느슨한 결합를 활성화하는 단지 방법입니다.

IoC 또는 서비스 위치 (which is an anti-pattern). ) 모든 응용 프로그램에서 느슨한 커플 링을 사용하려면 IoC가이를 수행하는 방법입니다 .

느슨한 결합 당신에게 혜택을 많이 제공 : (SOLID)

복잡성 감소를 결합

• 테스트 용이성
• 늦은을/더 나은 maintainab ility
• 확장 그것은 특정 아키텍처, 패턴 또는 응용 프로그램의 유형에 연결되지 않은

병렬 개발.