protobuf-net واشتقاق من مجموعات عامة

Question

أواجه مشكلة في معرفة كيفية الحصول على protobuf-net لتسلسل كائن مستمد من القائمة <T>. لقد حاولت إضافة سمة protoinclude لكنني أتلقى protobuf.protoException: يجب أن تكون القائمة المعروفة من النوع 1 لـ protoincludeattribute فئة فرعية مباشرة لـ UserTypecollection. عندما أقوم بإزالة attrib protoinclude ، يبدو أن البيانات لا يتم تسلسلها على الإطلاق. لا يمكنني العثور على أي أمثلة على هذا الموقف في أي مكان. أقوم بإضافة تسلسل Protobuf كخيار لواجهة برمجة تطبيقات WS الخاصة بنا وأحتاج إلى الحفاظ على التوافق مع DataContractSerializer.

[CollectionDataContract(), ProtoContract(InferTagFromName = true)]
[ProtoInclude(100, typeof(List<UserType>))]
public class UserTypeCollection : List<UserType>
{ ... }

[DataContract(), ProtoContract(InferTagFromName = true)]
public class UserType { ... }

Answer 1

ProtoInclude يستخدم للدلالة الفرعية الأنواع ، وليس الأنواع الأساسية (بعد كل شيء ، النوع الأساسي معروف بالفعل). أيضا ، IList<T> معالجة ينبغي إلى حد كبير يكون ضمنيا. لاحظ أن "الاستنتاج ..." وما إلى ذلك لا تفعل سوى القليل في حالة القوائم ، نظرًا لأن القوائم مجرد تسلسل العناصر الموجودة.

لما يلي ، أفترض أنك تحاول تسلسلها قائمة (ككائن أفضل):

أنا لست على الجهاز الصحيح في الوقت الحالي ، لكن في DLLs الصادرة ، أود توقع أن يلف القائمة عبر هدف سيجعلها تعمل:

[DataContract]
public class Foo {
    private readonly UserTypeCollection items = new UserTypeCollection();
    [DataMember(Order=1)]
    public UserTypeCollection Items {get{return items;}}
}

في "V2" ، آمل أن يعمل هذا السيناريو من البداية. سأحاول اختبار هذا غدًا (عندما يكون لدي الجهاز المناسب).

فكر آخر ؛ التصنيف الفرعي List<T> عادةً ما تكون مفيدة للغاية ، نظرًا لأن أيًا من الأساليب افتراضية. متروك لك ، بالطبع. وملاحظة أخيرة - في "V2" يمكننا وصف النموذج خارجيًا إذا كنت ترغب في الحصول على مزيد من التحكم في التسلسل ولكن دون التأثير على الأنواع نفسها.