IoC 컨테이너가 팩토리 사용을 대체합니까?

StackOverflow https://stackoverflow.com/questions/282406

문제

이제 막 IoC 컨테이너를 시작하는 단계이므로 이것이 어리석은 질문이라면 사과드립니다.

앱에 다음과 같은 코드가 있습니다

internal static class StaticDataHandlerFactory
    {
        public static IStaticDataHandler CreateHandler(StaticDataUpdate staticDataUpdate)
        {
            if (staticDataUpdate.Item is StaticDataUpdateOffice)
            {
                return new OfficeUpdateHandler();
            }

            if (staticDataUpdate.Item is StaticDataUpdateEmployee)
            {
                return new EmployeeUpdateHandler();   
            }

            if (staticDataUpdate.Item == null)
            {
                throw new NotImplementedException(
                    string.Format("No static data provided"));
            }
            else
            {
                throw new NotImplementedException(
                    string.Format("Unimplemented static data type of {0}", staticDataUpdate.Item.GetType().FullName));
            }
        }
    }

기본적으로 입력 데이터를 처리하기 위한 올바른 전략을 반환하는 간단한 팩토리입니다.

IoC 컨테이너를 사용하면 이와 같은 코드를 제거할 수 있나요?즉 말하자면 :입력 매개변수의 유형에 따라 로드할 구체적인 구현을 동적으로 선택할 수 있습니까?

아니면 내가 여기서 너무 벗어나 있는 걸까?

도움이 되었습니까?

해결책

실제로 일부 코드를 제어 시스템 반전으로 대체하는 것이 가능하지만 그것이 좋은 생각인지는 확실하지 않습니다.종속성 주입은 객체의 동적 생성이 아닌 시스템 구성에 가장 적합한 경향이 있습니다.다르게 말하면 컨테이너 자체는 거대한 전역 변수이므로 코드의 대부분에 나타나야 합니다.

여담이지만 코드는 다음을 위반하는 것으로 보입니다. 데메테르의 법칙.매개변수는 "StaticDataUpdate"가 아닌 "StaticDataUpdateItem" 유형이어야 하는 것으로 보입니다.이를 관찰하면 이 코드를 StaticDataUpdateItem에 대한 메서드 호출로 다시 작성해야 한다는 강력한 주장이 있습니다.

나는 IoC를 상당히 많이 사용했지만 동적 객체 생성은 여전히 ​​추상 팩토리 패턴을 사용하여 처리하는 것이 더 좋습니다.간단히 말해서, 핸들을 생성하기 위해 항목 자체에 메소드를 추가하는 아이디어가 마음에 들지 않으면 코드를 그대로 두는 것이 가장 좋습니다.

다른 팁

당신은 코스에서 전혀 멀지 않습니다;내가 이해하는 바에 따르면 당신은 꽤 가깝습니다.

이런 종류의 작업을 가장 일반적으로 구성하는 방법은 단순히 종속성 주입을 사용하여 반환되는 UpdateHandler를 지정하도록 허용하여 Factory 클래스를 IoC 컨테이너로 바꾸는 것입니다.따라서 StaticDataUpdateOffice가 OfficeUpdateHandler를 반환한다는 것을 지정하는 논리를 코드에 포함하는 대신 StaticDataUpdateOffice가 (새로 지정된) 무엇이든 반환하도록 간단하게 코드를 바꿀 수 있습니다. m_officeUpdateHandler 변수에는 다음이 포함됩니다.프레임워크에서 다음 값을 설정하는 한 m_officeUpdateHandler 팩토리를 호출하기 전에 가도 좋습니다.그리고 값을 변경할 수 있습니다. m_officeUpdateHandler 요구사항이 변경됨에 따라 런타임에 원하는 모든 것에 적용할 수 있습니다.

이 종속성 주입을 사용하면 제어 반전 프로세스를 제어할 수 있습니다.핸들러를 반환하는 간단한 팩토리를 가질 수 있고, 적절하게 다른 위치로 반환되는 핸들러를 제어하는 ​​논리를 추상화할 수 있습니다.

메모:이런 종류의 일에 대한 나의 경험은 Spring에 대한 나의 (매우 긍정적인) 경험에 의해 매우 강력하게 주도되며, 이것이 귀하의 질문(및 답변)에 대한 나의 해석에 영향을 미칠 수 있습니다.

짧은 대답은 예입니다. 이것 블로그 게시물 Windsor를 사용하여 런타임에 구현을 선택하는 매끄러운 방법을 보여줍니다. 저자 인 Ayende는 정교합니다 여기 그리고 여기.

나는 아직 이것을 시도하지 않았지만 곧 기대합니다.

나는 여기서 다른 답변에 동의합니다. 그렇습니다. 그렇게 할 수 있습니다. 그러나 왜 제네릭을 사용하지 않습니까?

public static IStaticDataHandler CreateHandler<T>( params object[] args )
{...

ARGS를 CTOR 인수로 전달할 수있는 경우 (예 : 활성화기).

나는 아직 이해가되는 단어를 아직 읽지 않았습니다.

IOC는 구성에 더 가깝습니까?

역동적 인 객체 생성은 무엇입니까? 제네릭? 이것은 모두 주제를 벗어난 것입니다.

1) IOC는 '전문화/상속에 대한 구성'복음을 구현하는 것과 비교할 때 좋은 시간 절약 일뿐입니다.

따라서 IOC를 사용하기위한 규칙 #1은 '계약 구현에 대한 바인딩에 대한 구속력'을 따르는 긴 생성자를 다루는 데 정말로 지겨워야한다는 것입니다.

또 다른 방법으로, 이것은 같은 이유로 템플릿 패턴의 대안으로서의 전략 패턴입니다 (캡슐화 ...) ... 그러나 모든 추가 인터페이스/초록 유형을 만들기 위해 더 많은 작업이 있으며 더 많은 작업을 수행합니다. 모든 iserviceprovicerthis 및 iresolverthat와 함께 매번 ... 다음과 같은 코드 계약을 지루하게 충족시키는 데 지치지 않는다면.

Iinterestingservice 흥미로운 = ... 그러나 인스턴스를 얻습니다 ..

이렇게 약 3 줄을 추가하십시오 ..

그 다음에

iAmazementservice Service = New AmazementService (흥미로운, Thesecondstrategy, Thethird 등 ...)

나이가 듭니다. 따라서 IOC는 Solid Design을 사용하여 코딩하기에 충분히 똑똑한 사람이 더 잘 알기 때문에 의문의 여지가 없습니다. 물어 보는 사람들은 모든 잘못된 답변을 가지고 있습니다.

따라서 실제로 위의 것을 만나면 절대적으로. IOC 컨테이너는 처리 할 수있는만큼의 '창조적'작업을 수행하기 위해 고리에 있습니다. 그리고 New가 New에 대한 가장 일반적인 창조적 인상은 Mr. Factory입니다.

데이먼

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top