Я, возможно, что-то пропустил, но я пытаюсь бороться с буферами протоколов в простой способ для предоставления расширений позже. Это кажется немного неясным, поэтому я сразу перейду к проблеме.Буферы протокола с расширениями
Я пишу сборку для поддержки различных задач, одна из которых включает описание структурированных данных. Отличное время для использования буферов протокола. Первичный класс для использования буферов протокола называется StateDefinition. Вот файл .proto я придумал для него:
package Kannon.State; message StateDefinition { enum StateTypes { GRAPHICS = 0; AUDIO = 1; MIND = 2; PHYSICS = 3; NETWORK = 4; GENERIC = 5; } repeated StateTypes requiredStates = 1; optional GraphicsStateDef Graphics = 2; optional AudioStateDef Audio = 3; (etc) } message GraphicsStateDef { extensions 100 to max; } message AudioStateDef { extensions 100 to max; } (etc)
Моя цель состояла в том, чтобы эти _StateDef сообщения будут расширены позже, с какими полями это понадобится. Однако это расширение произойдет независимо от библиотеки, которую я сейчас пишу.
Kagents.dll -> Ручки StateDefinition разбор и т. Д.
Что-то, ссылающееся на Kagents.dll -> Имеет файл protobuff с расширением GraphicsStateDef для определения необходимого состояния.
Я надеялся, что определение «продлить GraphicsStateDef» приведет к созданию кода, который позволит мне использовать свойства для доступа к этим полям и избегать громоздких синтаксисов Extendible.AppendValue() и GetValue().
Одно решение, которое я придумал, что кажется хаком, чтобы определить класс в ссылающегося DLL с помощью методов расширения, например, так:
public static class GraphicsExt { enum Fields { someValue = 1, someOtherValue = 2 } public static Int32 someValue(this State.GraphicsStateDef def) { return Extensible.GetValue(def, Fields.someValue); } public static void someValue(this State.graphicsStateDef def, Int32 value) { Extensible.AppendValue(def, fields.someValue, value); } }
Если кто-то может придумать лучшего способа, я был бы очень благодарен , =) Кроме того, я не уверен, насколько ясное описание проблемы вышло, поэтому, если есть какие-либо разъяснения или дополнительная информация, которую я могу предоставить, сообщите мне. =)
EDIT: Итак, много размышляя об этом и осознав, что я неправильно подхожу к проблеме. StateReference должен хранить список разных игр GameState. Кроме того, в нем хранится StateDefinition, в котором должно описываться состояние этой государственной справки. В настоящее время я пытаюсь десериализовать буферы состояний в разные классы (GraphicsStateDef), когда мне действительно нужно десериализовать сами объекты состояния.
Поэтому мне нужно переосмыслить дизайн таким образом, чтобы StateDefinition становился контейнером для потока и извлекал только достаточно информации для поля «repeat StateTypes requiredStates = 1». Затем в сборке ссылок остальная часть потока может быть десериализована в соответствующие состояния.
Есть ли у кого-нибудь рекомендации относительно того, как подойти к этому? Несколько идей формулируются, но ничего конкретного, и мне бы хотелось, чтобы вклад других.
Вы используете protobuf-net? Существуют ли какие-либо известные проблемы с генерацией кода для расширенных определений? – Merritt
Да, я использую protobuf-net. И нет, не то, что я знаю, я все же проверю. Это даже не проблема генерации кода, так это то, что я не могу придумать, какой языковой механизм использовать для «завершения» класса во внешней сборке. Частичные классы будут работать отлично, но откажутся пересекать границу сборки. – Quantumplation
Любые мысли о моем редактировании? Я все еще не совсем уверен, как я к этому подхожу. – Quantumplation