우리는 프로토콜 버퍼를 통해 서로 통신하는 몇 가지 서비스를 개발 중입니다. 모든 서비스는 .NET에 작성됩니다. .NET에서 마이그레이션하지 않을 것으로 예상됩니다. 나는 다른 플랫폼에서 서비스와 동일한 메시지를 사용하는 것을 예견하지 않는다.단일 플랫폼 시스템에서 .proto 파일을 사용해야하는 충분한 이유가 있습니까?
메시지는 현재 .proto로 작성되어 있습니다. 코드 생성 단계는 필자에게 불필요한 것처럼 보입니다.
(우리와 관련없는) 크로스 플랫폼 호환성 이외에도 .NET 언어로 직접 작성하지 않고 .proto로 메시지를 작성해야하는 이유가 있습니까?
설명하는 설정 (.NET 대 .NET, 크로스 플랫폼이 필요하지 않음)이 주어지면 "아니오"라고 말합니다. lot은이 카테고리에 부합하며 코드를 먼저 처리합니다. 즉, C# 유형을 작성하여 사용합니다. 이를 통해 유형에 대한 완벽한 제어 및 유연성을 제공하고 불필요한 빌드/툴링 단계를 피할 수 있습니다.
실제로 이것은 protobuf-net의 핵심 동기였습니다. 다른 모든 .NET 직렬 변환기와 마찬가지로 DSL로 정의하지 않고도 일반 C# 유형에서 작동 할 수 있습니다 (XmlSerializer). , DataContractSerializer, JavaScriptSerializer 등).
protobuf-net에는 .GetProto<T> 기능이 포함되어 있지만이 기능은 아직 v2에서 다시 구현되지 않았습니다. 그러나 이것은 크로스 플랫폼 프리 컴파일러가 완료되고 작동하기 때문에 내 목록에 있습니다. 여기 내 요점은 : 이 크로스 플랫폼 등을 수행해야하는 경우, protobuf-net은 기존 계약에서 .proto를 생성하는 데 도움이 될 수 있습니다.
어떤 점에서 에 다른 플랫폼과의 interop이 필요하다고 염려되는 경우 핵심 기능 세트를 고수하십시오. 같은 protobuf - 순증, 피하십시오 :
DateTime, decimal)
감사합니다 답장 마크. 이 질문은 자연스럽게 Nullable에 매핑되는 일부 선택 필드였습니다. 나는 당신의 대답 [여기] (http://stackoverflow.com/questions/4763875/does-protobuf-net-support-nullable-types)에 걸쳐 달렸다. xslt를 사용자 지정하면 간단하지 않은 것처럼 느껴집니다. 나는 널 값을 나타 내기 위해 디폴트 또는 플래그를 사용하는 것이 더 유혹적 일 것이다. .GetProto 에서 Nullable 을 지원할 계획입니까? –
Watsontap
@Kenn 필자가 할 수있는 것은 무엇이든 지원하려고 노력할 것이다 .p .proto에서 "선택 사항"으로 매핑 될 것이고, 이는 괜찮을 것이다. –
그러면 생성기가 Nullable에 선택적으로 매핑되지 않는다고 생각하면 코드 생성기에서 .GetProto이 비대칭이됩니다. –
Watsontap