결제 모듈을 만들고 싶습니다.이 모듈은 사용자가 제품을 지불 할 수있는 양식을 가지게 될 것입니다. 결제가 완료된 후 결제 정보를 여러 개의 db 테이블에 저장하려고합니다. 나는이 모듈을 다른 회사에서 사용하고자한다. 각 회사는 퍼시 스턴트 데이터를 다르게 처리한다. 하나의 테이블에 데이터를 두 개 또는 트리 테이블에 저장한다. 내 생각은 퍼블리셔 (지불 클래스)가 관찰자 패턴을 구현할 수있다. 지불 정보를 테이블 클래스 (구독자)에 푸시하면이 테이블에 데이터가 저장 될 수 있습니다.사용할 올바른 패턴
올바른 패턴을 사용할 수 있습니까? 어떤 제안? 내가 제대로 이해하면
감사
, 당신은 지불 공급자로부터 응답의 블랙 박스 구현을해야하고 한 번에이 모듈은 하나 개의 회사에 의해 사용될 수 있습니다. 당신의 아이디어는 참 멋지게 보입니다. 나를 통한 제안은 명령 설계 패턴을 사용하는 것일 수 있습니다. 각 유형의 응답 : ERROR, DECLINED PAYMENT, 사용자 지불에 의한 취소, 성공적인 지불 등. 각 회사는 각자의 구현을 갖습니다. 그리고 각각의 구체적인 명령은 다른 지불 상태를 구현합니다. SuccessfulPayment와 마찬가지로 CanceledPayment ... 인터페이스 ICOmmand를 구현합니다. 이러한 특정 구현은 회사에 남아있을 수 있습니다. 당신에게 필요한 유일한 것은 결제 회사의 응답에 대한 회사의 구체적인 처리 결과입니다. 예를 들어 자신의 비즈니스 로직에서 처리를 계속하기 위해 ICommand 인터페이스를 사용할 것입니다.
시므온 감사합니다. 네가 제안하는대로 작동한다고 생각합니다. 그 패턴에 관해 읽을 필요가 있습니다. – gastoncs
테이블 게이트웨이 패턴을 사용하고 있는데, 보는 방법은 FORM (메시지)에서 TABLE 클래스 (클라이언트)로 데이터를 설정하는 것입니다. 이 패턴은 데이터를 처리하는 방법을 알고있는 클라이언트 쪽에서 메서드를 호출하지만 폼에서 데이터를 테이블 클래스로 푸시 (push) 할 수있는 방법을 보았습니다. 예를 들어 클라이언트 개체가 이미 데이터를 보았습니다. – gastoncs