팩토리 구현시 상태 처리

팩토리 구현이 여러 개이고 각 객체마다 새 객체를 만드는 데 다른 상태 정보가 필요한 경우 어떤 패턴을 사용합니까?팩토리 구현시 상태 처리

예 : IModelParameters은 : 복소 계산 IModelParameterFactory 모든 입력 및 출력을 포함 얻고 IModelParameter 객체를 저장하는 방법이있다.

문제는 하나의 팩토리 구현이 검색에 필요한 상태 (예 : UserID)가있는 데이터베이스에서 매개 변수를 가져 오는 중일 수 있으며, 다른 하나는 파일에서 입력을 가져 오는 경우 일 수 있습니다. UserID가 있지만 파일 이름이 필요합니다.

이 경우 더 잘 작동하는 다른 패턴이 있습니까? 일부 의존성 주입 도구/라이브러리를 살펴본 결과 상황을 해결할 것으로 보이지 않는 것을 보았습니다.

출처

2013-05-20 bpeikes

요구 사항을 수업에 넣으려고 했습니까?

모든 팩토리 구현에는 고유 한 requeriments가 있지만 모든 requeriments 클래스는 기본 requeriment 클래스 (또는 requreiments 인터페이스를 임프레션)에서 파생됩니다. 이렇게하면 모든 팩터 리 구현에 대해 동일한 인터페이스를 가질 수 있으므로 모든 팩토리 구현시 올바른 requeriments 클래스로 형변환하면됩니다.

예, 캐스트는 오류가 발생하기 쉽고 오류가 발생하기 쉽지만이 방법은 공장에서 확장 가능한 인터페이스를 제공합니다.

출처

2013-05-20 19:00:18 Manu343726

일부 코드를 보지 않고 말하기는 어렵지만 리포지토리 패턴을 구현하는 것이 좋습니다. 리포지터리 (repository)의 구현은, 팩토리가 그 오브젝트를 구축하기 위해서 (때문에) 사용한 데이터의 취득을 담당합니다. 당신은 당신의 공장에 저장소 인터페이스를 주입 수 :

public class ModelParameterFactory : IModelParameterFactory 
{ 
    private readonly IModelParameterRepository Repository; 

    public ModelParameterFactory(IModelParameterRepository repository) 
    { 
     Repository = repository; 
    } 

    ...interface methods use the injected repository... 
}

그런 다음 당신이 가진 것하는 DatabaseModelParameterRepository과 FileModelParameterRepository을 말한다. 오히려, 그것은 ModelParameterFactory에 IModelParameterRepositoryFactory를 주입 더 적합 할 수 있습니다,이 시점에서

public class ModelParameterRepositoryFactory : IModelParameterRepositoryFactory 
{ 
    public ModelParameterRepositoryFactory(...inputs needed to determine which repository to use...) 
    { 
     ...assign... 
    } 
    ...determine which repository is required and return it... 
}

:하지만 그건 또 다른 공장을 요구한다, 그래서 당신은 또한, 당신은 주입해야 그 어떤 주위에 논리를 가지고 같은데요 IModelParameterRepository를 삽입하는 것보다. 당신이 DI 컨테이너 사용 여부

public class ModelParameterFactory : IModelParameterFactory 
{ 
    private readonly IModelParameterRepositoryFactory RepositoryFactory; 

    public ModelParameterFactory(IModelParameterRepositoryFactory repositoryFactory) 
    { 
     RepositoryFactory = repositoryFactory; 
    } 

    ...interface methods get repository from the factory... 
}

, 사용하고있는 공장 호출 코드 또는 DI 구성에 반대 이제, 관련 공장 구현으로 이동 사용할 저장소에 관한 모든 논리.

이 디자인은 너무 복잡하지는 않지만 그럼에도 불구하고 ModelParameterFactory 및 ModelParameters가 너무 일반적인 것인지 궁금해 할 수 있습니다. 당신은 그것들을 별개의보다 구체적인 수업으로 괴롭히는 것이 유익 할 것입니다. 결과는 더 간단하고 표현력이 풍부한 디자인이 될 것입니다. 그러나 위의 경우가 아니라면 위의 내용이 도움이 될 것입니다.

출처

2013-05-20 20:14:51

제 생각에 정적 객체, 전역 변수, 캐시 또는 세션과 같이 메모리에 저장하는 상태입니다. 일반적으로 DI에서는 이러한 상태가 유지되지 않지만 매개 변수로 전달됩니다. 예 :

public IEnumerable<Records> GetRecordByUserId(string userId){ /*code*/ }

userId가 리포지토리에서 대신 유지되고 있습니다.

그러나 쿼리를 수행 할 때마다 전달하는 대신 구성 방식으로 만들려면 래퍼 클래스로 주입 할 수 있다고 생각합니다. 자세한 내용은 내 question을 참조하십시오. 그러나 저장소에서이 디자인을 권장하지는 않지만 서비스 수준에서는 권장합니다.

출처

2013-05-21 02:15:55 Fendy

팩토리 구현시 상태 처리

답변

관련 문제