2014-02-28 3 views
1

데이터베이스에서 보류중인 레코드 수가 n 인 응용 프로그램을 개발하고 레코드를 처리합니다. 처리중인 상태는 "PROCESSING"이며 레코드를 "ERROR"또는 "SUCCESS"로 표시합니다. 모든 레코드가 성공적으로 처리되면 상태를 데이터베이스에서 "SUCCESS"로 업데이트해야합니다. 일부 레코드를 처리하지 못한 경우이를 "오류"로 업데이트하고 오류 로그 표에 오류의 원인을 삽입하고 나머지는 성공으로 업데이트해야합니다. State Design Pattern을 사용하여 이것을 구현하려고 생각했습니다.상태 디자인 패턴 구현 쿼리

내 질문 - 한 번에 하나의 레코드를 처리하는 경우 State 디자인 패턴을 사용하여 구현하는 것이 이치에 맞다고 이해합니다. 대량 레코드를 처리하는 경우 State 패턴을 사용하여 구현하는 것이 합리적일까요? 그렇지 않은 경우 대안이 있습니까?

+1

동일한 레코드로 모든 레코드가 동일하게 처리됩니까? 당신이 설명하는 것은 상태 패턴이 아니라 상태를 저장하는 것입니다. – Wain

+0

예, 모든 레코드에 대해 프로세스가 동일합니다. 일부 레코드가 오류로 확인되면 성공을위한 SP가 아닌 다른 SP를 호출해야합니다. 또한, 나는 "PROCESSINGERROR"오류 레코드 처리를 다시 시도하는 상태가 있습니다. 상태 패턴을 사용하려고 생각한 이유는 각 상태에서 어떤 일이 일어나는지를 쉽게 판단 할 수 있기 때문입니다. 그게 적절한 디자인 감각을 만들어 주나요? – user1399653

답변

1

실제로 이것은 상태 패턴의 경우에는 좋지 않습니다. State는 객체가 상태에 따라 다르게 행동하는 것을 용이하게합니다. 상태를 적용하려면 프로토콜을 구현하지만 객체의 상태에 따라 객체를 다르게 구현해야합니다. 사용하는 예제 The Gang of Four는 소켓 클래스 용입니다. 최근에 State를 사용했는데 장치가 사용 중이면 그렇지 않은 것보다 특정 기본 기능을 다르게 처리하려고했습니다. 따라서이 경우 동일한 인터페이스를 구현하는 두 개의 상태 핸들러를 구현하고 장치가 사용 또는 사용 중지되었다는 이벤트가 도착하면 스왑합니다.

귀하의 경우, 주어진 개체의 상태를 모델링해야합니다. 리 액티브 프로그래밍 (Reactive Programming)의 등장으로 컴백을 만드는 상태 머신에 대해 조금 읽어야합니다.

발견 된 this gentle introduction 매우 양호합니다.