엔티티 또는 도메인 모델의 확장성에 IoC를 사용하는 것이 옳은가요?

Question

나는 여기에서 토론 할 가치가 있다고 생각하는 딜레마를 발견했습니다.

IoC로 해결되는 별도의 DAL에서 일부 데이터를 가져 오는 일련의 도메인 개체가 있습니다 (개체 개체라고도 부를 수 있음).

나는 시스템을 매우 확장 가능하게 만드는 것에 대해 생각하고 있었으며, IOC에 의해 이러한 엔티티를 해결하는 것이 옳은지 방황하고 있습니다.

멍청한 예를 들어 보겠습니다.

의 내가 나는 다음과 같은 인터페이스를 가지고있는 웹 사이트가 있다고 가정 해 봅시다 :

public interface IArticleData 
{ 
    int ID { get; } 
    string Text { get; set; } 
} 

개념이다는 DAL은 DAL 쉽게되고, 그 후에 이러한 인터페이스, 또한 일반적인 IDataProvider<TData> inteface을을 구현하는 교체 가능.

public class Article 
{ 
    private IArticleData Data { get; set; } 

    public int ID 
    { 
     get { return Data.ID; } 
    } 

    public int Text 
    { 
     get { return Data.Text; } 
     set { Data.Text = value; } 
    } 

    private Article(IArticleData data) 
    { 
     Data = data; 
    } 

    public static FindByID(int id) 
    { 
     IDataProvider<IArticleData> provider = IoC.Resolve<IDataProvider<IArticleData>>(); 
     return new Article(provider.FindByID(id)); 
    } 
} 

이 (예, IDataProvider<IArticleData>에있을 것입니다) 실제 DAL 구현에 관계없이 전체 시스템을 만드는 : 그리고 그것을 사용하는 다음 클래스가있다.

그런 다음이 기능이 실제로 충분하지 않은 상황을 상상해 보겠습니다. 위의 예에서, 나는 그것을 할 수있는 옵션이없는,하지만 난 할 경우는 인터페이스 구현 :

public interface IArticle 
{ 
    int ID { get; } 
    string Text { get; set; } 
} 

public class Article : IArticle 
{ 
    ... 
} 

을 그리고, 저는 제 클래스에 모든 종속성을 제거하고 임시로 해결 시작 IoC가있는 IArticle 구성 요소. 예를 들어, 성

:

public class MyArticle : Article 
{ 
    public string MyProperty { ..... } 
} 

그리고이해야 할 모든이에 구성을 변경할 수 있습니다 : 나는 그것을 확장 할 수있는 경우이 후 <component id="ArticleEntity" service="IArticle" type="Article" lifestyle="transient" />

, 그이 간단한 것 : <component id="ArticleEntity" service="IArticle" type="Article" lifestyle="transient" />

문제의 시스템을 사용하는 사람이라면 구성의 라인을 다시 작성하는 것처럼 모든 클래스를 바꿀 수 있습니다. 새로운 개체는 이전 개체와 동일한 기능을 구현하기 때문에 다른 모든 개체도 올바르게 작동합니다.

그건 그렇고, 이것은 "분리의 우려"철학에 대한 좋은 해결책 인 것 같습니다.

제 질문은 이것이 올바른 것입니까? 진지한 생각을 한 후에는 더 나은 방법을 찾아 낼 수 없었습니다. 나는 또한 MEF를 고려했다. 그러나 플러그인을 만드는 것에 중점을 두는 것 같지만 이처럼 시스템의 완성 된 부분을 대체하거나 확장하지는 않는다. How should I handle my Entity/Domain Objects using IoC/Dependency Injection? 및 IoC, Where do you put the container?

그리고 나는 또한 내가에 설명 된 문제에 떨어지는을 드릴 수 : 주제에 대한 질문 (그리고 다른 소스), 가장 주목할만한 이들이다 그래서 많은 읽을

다음 페이지 : http://martinfowler.com/bliki/AnemicDomainModel.html 및 http://hendryluk.wordpress.com/2008/05/10/should-domain-entity-be-managed-by-ioc/

그리고 한 가지 더 :이 전체 시스템의 테스트 용이성을 증가시킬 것입니다, 안 그래?

당신은 어떻게 생각하십니까?

편집 : 는 또 다른 옵션이 단체의 팩토리 패턴을 생성하는 것입니다,하지만 IoC.Resolve<IArticle> 난 당신이 일을과 복잡함을 할 수있다 생각하는 방법은 간단

Answer 1

IoC.Resolve<IArticleFactory>().CreateInstance()보다. I Article을 구현 한 다른 유형으로 Article을 대체해야 할 필요가 있습니까?

IoC 컨테이너는 하위 수준 구성 요소에 종속 된 상위 수준 구성 요소가 있고 하위 구성 요소가 일부 구성 요소를 수행하기 때문에 상위 구성 요소가 해당 구성 요소의 추상화에 종속되도록하려는 경우에 가장 적합합니다. 내부적으로 높은 수준의 구성 요소를 테스트하는 것을 어렵게하는 연산 데이터베이스 액세스. 또는 하위 수준의 구성 요소는 애플리케이션의 다른 전략과 상호 교환 할 수있는 특정 전략을 나타낼 수 있습니다. 공급 업체별 데이터베이스 API로 작업하는 세부 사항을 추상화하는 데이터베이스 게이트웨이. 제로서

간단한, POCO 스타일 클래스, 그것은 당신이 IoC 컨테이너 불구하고 그것의 인스턴스를 생성 어떤 혜택을 얻을 것 같지도입니다.

기본적 사실,하지만 좀 더 비즈니스 로직을 필요로 할 때 경우가 경우 교체 할 수 있다면, 그것은 편리 올 것