IoC 컨테이너를 사용할 때 인터페이스 분리를 ​​관리하는 방법은 무엇입니까?

Question

가능한 중복 :
StructureMap singleton usage (A class implementing two interface)

나는 현재 작은 시스템을 설계하고 있는데 내가 현재 IOC의로 structureMap을 사용하고 있습니다. 방금 인터페이스 분리의 요지가 생겼어. 지금 궁금해.

특정 비즈니스 객체가 있으면 구현할 수있는 인터페이스가 3 개 ... 코드의 구성 및 instatiation에서 어떻게 처리해야합니까?

간단한 시나리오에서는 EmployeeServiceObject라는 서비스 계층 클래스에 대해 두 개의 인터페이스가 있다고 가정합니다. IGenericEntity 및 IEmployeeServiceObject입니다.

GenericEntity는 클래스에 CRUD 기능을 제공하고 IEmployeeServiceObject는 비즈니스 쿼리/작업에 대한 결과 집합을 제공합니다.

Facade/Service Layer 메서드에서 EmployeeServiceObject 클래스를 사용해야하고 실제로 두 인터페이스의 기능을 사용해야합니다. 어떻게 처리해야합니까?

처음에는 올바른 작업은 IoC의 구성을 설정하여 IEmployeeServiceObject를 EmployeeServiceObject에 매핑하고 개체에 대한 팩토리를 요청한 다음 CRUD 기능을 사용해야 할 때 IGenericEntity로 캐스팅했지만, 모르겠다. 또한 구체적인 클래스가 실제로 ioc 컨테이너 구성에서 설정되지 않은 인터페이스를 구현한다는 사실을 공식적으로 밝히지 않기 때문에 옳지 않은 것처럼 보입니다.

그리고 나는 분명히 동일한 구체적인 클래스의 두 인스턴스를 생성하지만 다른 인터페이스를 요청하는 것은 더욱 악해진다는 것을 알고 있습니다.

어떻게 처리해야합니까? 그렇다면

public interface IGenericEntity { /**/ } 

public interface IEmployeeServiceObject { /**/ } 

public class EmployeeServiceObject : IEmployeeServiceObject, IGenericEntity 

이 EmployeeServiceObject이 두 인터페이스를 구현한다는 사실이 구현 세부입니다 : 내가 제대로 질문을 이해한다면

Answer 1

나는 중복으로 내 질문을 닫는 방법을 찾지 못했지만 ... 정확히 내가 어떻게 다른 stackoverflow 질문에 필요한 일을 발견.

Windsor에서 Forward 메서드로 언급 한 Mark는 StructureMap에도 존재하며 올바른 방법 일 것입니다.

StructureMap singleton usage (A class implementing two interface)

Answer 2

, 당신은 (C# 코드)에 다음과 같은 시나리오를 가지고있다. 각 인터페이스를 별도로 구현하는 다른 구현이있을 수 있습니다. ISP에의

요점은 각 인터페이스 모델을 별도의 우려, 당신은 자주 당신이 IGenericEntity 및 IEmployeeServiceObject 모두 당신이 두 개의 인터페이스로 분리가 의미인지 질문해야해야하는 상황에 처할 수 그래서 만약.

그렇지 않으면 캐스팅 시도시 Liskov Substitution Principle이 깨질 수 있으므로 각 인터페이스를 별도로 요청해야합니다.

당신이 진정으로 모두를 필요로하는 경우에, 당신은 모두 요청해야합니다 : 두 인터페이스를 구현하는 당신은 하나 개의 클래스 (EployeeServiceObject)를 가지고있는 경우

public class Foo 
{ 
    public Foo(IGenericEntity ge, IEmployeeServiceObject eso) { /**/ } 

    // ... 
} 

을, 당신은 DI 컨테이너를 이야기해야합니다 이것이 사실입니다. 이 시점에서 우리는 콘테이너 특정 세부 사항의 지역으로 이동하고있다, 그래서 어떻게하면 당신은 각 콘테이너에 따라 다르다.

예를 들어, Windsor에는 한 인터페이스의 요청이 다른 유형으로 전달되도록 지정하는 Forward 메소드가 있습니다. 그것은 당신에게 어떻게 용기에 중요한 단서를 제공 할 수 있기 때문에 당신이 가난한 사람의 DI와 종속성 계층 구조를 구성 할 방법을 이해하는 좋은 일이 항상 간단

var eso = new EmployeeServiceObject(); 
var f = new Foo(eso, eso); 

로

는 가난한 사람의 DI 그것은이다 똑같은 것을 이해할 것입니다.

Answer 3

DI/IoC 구현을 해결하기 전에 API를 설명하고자합니다. 나는 당신의 고통 점이 당신을 더 나은 디자인으로 이끌려고 노력하고 있다고 생각합니다.

EmployeeServiceObject가 너무 많은 책임이있는 것으로 보입니다. 개체를 만드는 동안 Single Responsibility Principle을 고려하십시오. 설명에서 EmployeeServiceObject는 모두 외관/서비스 계층 및 CRUD 계층입니다. CRUD 작업을위한 인터페이스 (IGenericEntity)를 할당하면 CRUD 구현을 외관 (IEmployeeServiceObject)의 소비자에게 노출하게됩니다.

당신이 설명한이 상황과 유형, (나는 또한 더 정확하게 자신의 목적 설명하기 위해 당신의 유형 이름을 재고 할 ) 다른 접근 방법을 고려하시기 바랍니다 감안할 때 :

public interface IEmployeeServiceObject 
{ 
    // Service methods 
    decimal GetSalary(string employeeId); 
} 

public class EmployeeServiceObject : IEmployeeServiceObject 
{ 
    private IGenericEntity<Employee> _entity; 

    public EmployeeServiceObject(IGenericEntity<Employee> entity) 
    { 
     _entity=entity; 
    } 

    public decimal GetSalary(string employeeId) 
    { 
     return _entity.Get(employeeId).Salary; 
    } 
} 

public interface IGenericEntity<T> 
{ 
    // CRUD Methods including... 
    T Get(string id); 
} 

public class GenericEntity<T> : IGenericEntity<T> 
{ 
    T Get(string id){...} 
} 

IEmployeeServiceObject/EmployeeServiceObject 등록을하고 IGenericEntity/GenericEntity가 선택한 컨테이너와 쌍을 이룹니다. (StructureMap은 규칙에 따라 이러한 형식을 등록 할 수 있습니다.)

컨테이너에서 IEmployeeServiceObject를 요청하면 컨테이너는 GenericEntity를 제공하기 전에 GenericEntity를 EmployeeServiceObject의 생성자에 삽입합니다.

이렇게하면 설명한 캐스팅/등록 문제를 피할 수 있습니다. 컨테이너가 최적 이하의 방식으로 작동하도록 할 필요가 없습니다. 또한 귀하의 정면은 고객이 필요로하는 것을 드러내고 CRUD 작업을 다른 클래스 (고객에게 노출 될 필요가 없음)로 연기합니다.