Protobuf-Net: استثناء من نوع السلك غير صحيح خصائص GUID

Question

أواجه مشكلات تفضي إلى خصائص GUID معينة من الكيانات التي تم إنشاؤها بواسطة ORM باستخدام Protobuf-Net.

فيما يلي مثال مبسط على الكود (يعيد إنتاج معظم عناصر السيناريو ، لكنه لا يعيد إنتاج السلوك ؛ لا يمكنني فضح كياناتنا الداخلية ، لذلك أنا أبحث عن أدلة لمراعاة الاستثناء). قل لدي فصل ، Account مع ال AccountID القراءة فقط GUID ، و AccountName القراءة والكتابة سلسلة. أنا تسلسل وتهرب على الفور استنساخ.

تخلص من رمي Incorrect wire-type deserializing Guid استثناء أثناء هجرته.

هنا مثال الاستخدام ...

        Account acct = new Account() { AccountName = "Bob's Checking" };
        Debug.WriteLine(acct.AccountID.ToString());
        using (MemoryStream ms = new MemoryStream())
        {
            ProtoBuf.Serializer.Serialize<Account>(ms, acct);
            Debug.WriteLine(Encoding.UTF8.GetString(ms.GetBuffer()));
            ms.Position = 0;
            Account clone = ProtoBuf.Serializer.Deserialize<Account>(ms);
            Debug.WriteLine(clone.AccountID.ToString());
        }

وإليك مثال على فئة orm'd (مبسطة ، ولكنه يوضح الدلالات ذات الصلة التي يمكنني التفكير فيها). يستخدم لعبة shell لإلغاء خصائص القراءة فقط من خلال تعريض حقل الدعم ("لا يمكن الكتابة" بشكل أساسي "لا ينبغي أن تكتب" ، ولكن يمكننا مسح التعليمات البرمجية للحصول على مثيلات التعيين لهذه الحقول ، وبالتالي فإن الاختراق يعمل من أجلنا المقاصد).

مرة أخرى ، هذا يفعل ليس إعادة إنتاج سلوك الاستثناء ؛ أنا أبحث عن أدلة على ماذا يستطع:

[DataContract()]
[Serializable()]
public partial class Account
{
    public Account()
    {
        _accountID = Guid.NewGuid();
    }
    [XmlAttribute("AccountID")]
    [DataMember(Name = "AccountID", Order = 1)]
    public Guid _accountID;

    /// <summary>
    /// A read-only property; XML, JSON and DataContract serializers all seem
    /// to correctly recognize the public backing field when deserializing: 
    /// </summary>
    [IgnoreDataMember]
    [XmlIgnore]
    public Guid AccountID
    {
        get { return this._accountID; }
    }

    [IgnoreDataMember]
    protected string _accountName;

    [DataMember(Name = "AccountName", Order = 2)]
    [XmlAttribute]
    public string AccountName
    {
        get { return this._accountName; }
        set { this._accountName = value; }
    }
}

يبدو أن كل من Serializers XML و JSON و DataContract يقومون بتسلسل / تخلص من الرسوم البيانية للكائنات على ما يرام ، وبالتالي فإن ترتيب السمات يعمل بشكل أساسي. لقد جربت protobuf-net مع القوائم مقابل مثيلات واحدة ، وأنماط بادئة مختلفة ، وما إلى ذلك ، ولكن لا يزال يحصل دائمًا على استثناء من نوع الأسلاك غير الصحيح ...

لذا فإن الأسئلة المحددة هي ، هل هناك أي تفسير / حلول معروف لهذا؟ أنا في حيرة أحاول تتبع الظروف (في الكود الحقيقي ولكن ليس المثال) يمكن أن تسبب ذلك.

نحن أمل عدم الاضطرار إلى إنشاء تبعية protobuf مباشرة في طبقة الكيان ؛ إذا كان هذا هو الحال ، فربما سنقوم بإنشاء كيانات DTO وكيل مع جميع الخصائص العامة التي لها سمات protobuf. (هذه قضية ذاتية لدي مع جميع نماذج التسلسل التعريفي ؛ إنها نمط في كل مكان وتفهم سبب ظهوره ، ولكن IMO ، إذا استطعنا وضع رجل على سطح القمر ، فيجب أن يكون "الطبيعي" أن يكون له كائنات وعقود التسلسل منفصل. ؛-))

شكرًا!

Answer 1

متفق عليه ، يجب ألا تحتاج إلى تبعية صريحة - DataMember على ما يرام. ويستخدم ProtoBuf-Net نفس المنطق إعادة تجاهله وما إلى ذلك. كيف / أين تقوم بتخزين البيانات؟ في تجربتي ، فإن السبب الأكثر شيوعًا لذلك هو أن الناس يفرطون في كتابة المخزن المؤقت (أو الملف) ببيانات مختلفة ، وعدم اقتطاعه (ترك القمامة في نهاية الدفق) ، كما نوقش هنا. هل هذا يتعلق بالسيناريو الخاص بك؟