В конечном счете, я думаю, что ответ здесь будет «нет». Есть хорошее базовое правило руководства, которое применяется к DTO:
- DTO, как правило, должны быть настолько просты, насколько это возможно, для передачи данных для сериализации таким образом, который хорошо подходит для конкретного сериализатора.
- если этой базовой модели достаточно для работы с над этим слоем , тогда отлично
- но если нет: не боритесь с сериализатором ; вместо этого создайте отдельную модель предметной области над уровнем DTO и просто сопоставьте две модели до сериализации или после десериализации
Или, говоря иначе: тот факт, что генератор не хочет показывать элементы только для чтения, не имеет значения, потому что если вам нужно что-то экзотическое, вам не следует использовать сгенерированный тип вне кода, который напрямую касается сериализации , Итак: в вашем типе домена, который отражает DTO: сделайте его доступным только для чтения там .
Что касается , почему поля, доступные только для чтения, обычно не используются в инструментах сериализации: вы, вероятно, хотите иметь возможность дать ему значение. Инструменты сериализации обычно хотят иметь возможность писать все, что умеют читать, и читать все, что умеют писать.
Незначительное примечание для полноты, так как вы упомянули C #: если вы используете подход с первым кодом для protobuf-net, он будет хорошо работать только с {get;} -подключением, только с {get;} -подключением только вручную. , если , все открытые члены тривиально отображаются в очевидный конструктор.