2014-02-07 2 views
1

나는 대조 역설과 그 개념에 대해 잘 알고있다. 모두 이해가되지만, 지식은 단순한 모델과 시나리오를 제공하는 기사와 서적에서 나옵니다.대조 역전 - 대규모 사례

필자의 경우,이 아키텍처의 견고한 경험을 가진 사람은 아무도 없으므로 설계를 검증 할 방법이 없습니다. IoC가 올바르게 수행 된 시스템의 좋은 예가 있습니까?

또한 내 경우에는 인터페이스와 모델을 호출자와 구현 자 (부팅시 종속성 주입)에서 가져 오는 별도의 어셈블리로 선언하는 경향이 있습니다. 그러나 이것은 많은 프로젝트를 이끌어 내며, 때때로 디커플링을 위해서만 2 ~ 3 개의 클래스를 구현하는 어셈블리를 갖는 것을 정당화하기가 어렵습니다. 네임 스페이스만으로 비슷한 수준의 격리를 달성 할 수 있을지 궁금해합니다.

답변

1

IoC는 어떠한 방식으로도 많은 어셈블리가 필요하지 않습니다. 버전 지정 또는 기타 외부적인 이유로 필요하거나 필요하다고 느끼는 사람이 많거나 많을 수 있습니다.

두 가지 극한값 (모든 어셈블리에 대해 여러 클래스, 모두에 대해 하나의 어셈블리)을 포함하여 모든 옵션에 대해 좋은 인수가 있으므로 선택해야합니다.

고려할 사항 :

  • 당신이 (예 : 일분에서) 빨리 마무리 작업을하는 코드의 조각에 대한 + 단위 테스트를 구축 할 수 있습니다 - 작은 어셈블리 및 별도의 프로젝트를 더주의 깊게
  • 을 고려하지 않을 경우 외부 API를 제공합니까? 그렇다면 "안정적인 인터페이스"어셈블리 집합과 "자주 변경되는 구현/세부 정보"어셈블리를 분리하는 것을 고려하십시오.
  • 는 팀이 객체의 밀접한 결합하거나 규칙을 방지하기 위해 어셈블리 사이의 코드의 물리적 분리를 필요로하지 않습니다 (이하 프로젝트를 쉽게 관리 할 수 ​​있습니다)
  • 도구는 당신이 프로젝트
  • 수/크기에 의해 영향을 어떻게 사용하고 있는지 충분하다