Java 기반 서비스에 대한 Google 프로토콜 버퍼를 평가하고 있지만 언어와 무관 한 패턴을 기대하고 있습니다. 두 가지 질문이 있습니다.
첫 번째는 광범위한 일반적인 질문입니다.
사람들이 사용하는 패턴은 무엇입니까? 상기 패턴은 클래스 구성 (예를 들어,. 프로토 파일 당 메시지, 패키징 및 분배) 및 메시지 정의 (예를 들어, 반복 된 필드 대 반복 된 캡슐화 된 필드 *) 등과 관련된다.
Google Protobuf 도움말 페이지와 공개 블로그에는 이런 종류의 정보가 거의 없지만 XML과 같은 기존 프로토콜에 대한 수많은 정보가 있습니다.
또한 다음 두 가지 패턴에 대한 구체적인 질문이 있습니다.
.proto 파일로 메시지를 표현하고 별도의 jar 파일로 패키지하여 서비스 소비자를 대상으로 전달하십시오. 기본적으로 내가 생각하는 기본 접근 방식입니다.
적어도 두 가지 방법을 지원하는 계약을 구현하는 각 메시지 주위에 수작업으로 포장 된 래퍼 (하위 클래스가 아님)를 포함하십시오 (T는 래퍼 클래스, V는 메시지 클래스 (제네릭을 사용하지만 간략 함을 위해 간단한 구문 사용)). :
public V toProtobufMessage() { V.Builder builder = V.newBuilder(); for (Item item : getItemList()) { builder.addItem(item); } return builder.setAmountPayable(getAmountPayable()). setShippingAddress(getShippingAddress()). build(); } public static T fromProtobufMessage(V message_) { return new T(message_.getShippingAddress(), message_.getItemList(), message_.getAmountPayable()); }
내가 의해 도입 된 복잡성을 멀리 숨길 수 I (2)를 참조 장점 중 하나는 V.newBuilder().addField().build()과 같은 몇 가지 의미있는 방법을 추가 isOpenForTrade()또는 isAddressInFreeDeliveryZone()등 내 래퍼에. (2)에서 볼 수있는 두 번째 장점은 클라이언트가 변경 불가능한 객체 (래퍼 클래스에서 강제 할 수있는 것)를 처리한다는 것입니다.
(2)의 단점 중 하나는 코드를 복제하고 래퍼 클래스를 .proto 파일과 동기화해야한다는 것입니다.
누구든지 두 가지 접근법 중 하나에 대해 더 나은 기술이나 비평을 가지고 있습니까?
* 반복 된 필드를 캡슐화함으로써 다음과 같은 메시지를 의미합니다.
message ItemList {
repeated item = 1;
}
message CustomerInvoice {
required ShippingAddress address = 1;
required ItemList = 2;
required double amountPayable = 3;
}
이와 같은 메시지 대신 :
message CustomerInvoice {
required ShippingAddress address = 1;
repeated Item item = 2;
required double amountPayable = 3;
}
나는 후자를 좋아하지만 그것에 대한 논쟁을 기뻐합니다.