لماذا يتم تعديل الحقول الخاصة في عقود البيانات من خلال العقود العامة؟

عند إنشاء مشروع WCF جديد ، يتم إنشاء خدمة نموذج نيابة عنك. عقد البيانات الافتراضي هو (لقد قمت بتغيير عنوان حقل نوع السلسلة):

[DataContract]
public class CompositeType
{
    bool boolValue = true;
    string name = "";

    [DataMember]
    public bool BoolValue
    {
        get { return boolValue; }
        set { boolValue = value; }
    }

    [DataMember]
    public string Name
    {
        get { return name; }
        set { name = value; }
    }
}

ما فائدة وجود هذه الحقول الخاصة boolValue و الاسم ؟ هل هي ممارسة جيدة لكتابة بعض البيانات التعقيم أو بعض التلاعبات الأخرى في العقد ، وبالتالي النفخة؟ يبدو أن السبب الوحيد العقلاني بالنسبة لي عدم الكتابة إلى الحقول مباشرة. فهل هو bloatware أو لديه سبب وراء ذلك؟

0

3 إجابة

نفس السبب الذي سبق لك أن كتبت فيه مقرضًا ومؤسسًا لأي قيمة خاصة ، للمساعدة في تغليف التغليف وتسمح لك بالتعامل مع الأعمال الداخلية لفصلك دون أن تقلق بشأن خرق الأعضاء الخارجيين لأنهم كانوا يتلاعبون بالمتغيرات مباشرة.

0
وأضاف

الإجابة المختصرة هي أن الخصائص العامة تسمح لك ، المصمم ، بتقييد القيم قبل أن يتم تعيينها لحقولك الخاصة ، مما قد يحفظك من التعامل مع البيانات غير المتوقعة. على الرغم من أن معظم طرق الحصول على وتعيين هي نفسها ، فهي في كثير من الأحيان خط الدفاع الأول ضد البيانات السيئة.

0
وأضاف
حسنًا ، كان السؤال في الواقع هو ما إذا كان سيتم تعقيم البيانات في عقد البيانات (يعني ذلك أثناء إرساله) أو قبل إرسال البيانات. أعتقد أن عقد البيانات قد يتضخم إذا قمت بكتابة منطق التعقيم فيه. إذن أنت لا توافق؟
وأضاف المؤلف Arnthor, مصدر
أنت لم تفهمني مجدداً يجب أن يتم تعقيم البيانات ، والسؤال هل سيتم تعقيمها في عقود البيانات أو في مكان آخر. على سبيل المثال ، من المؤكد أنها لا ممارسة هندسية سليمة لكتابة كود تعقيم البيانات في ملف ascx. يمكنك القيام بذلك في ملف back-end .ascx.cs. أنا لا أسأل عن اكتساب ، أو المستوطنين أو التحقق من الصحة. لقد كنت موجودًا. كان السؤال هو مكان إجراء التحقق من الصحة.
وأضاف المؤلف Arnthor, مصدر
أنا أعترض. ما نسميه bloat ، وغيرها تعريف أفضل الممارسات هندسة البرمجيات السليمة. نعم ، أنت تضيف بضعة أسطر من التعليمات البرمجية ، لكن الضمانات الدفاعية هي أكثر من تستحقها. بالإضافة إلى ذلك ، لا نكتب إلى شرائح ROM. لدينا القدرة على المعالجة والنطاق الترددي والذاكرة لعدم التضحية متانة في مذبح الاقتصاد.
وأضاف المؤلف GrayFox374, مصدر

في رأيي ، يجب أن يكون الغرض DataContracts المفرد لنقل البيانات بين المجالات. يجب أن يكون منطق التحقق/التعقيم خارج مسؤوليات DataContract. خاصة إذا كان القصد هو مشاركة/ربط ملف الكود في مشاريع/منصات متعددة لإعادة الاستخدام.

هذا يعني أيضًا أنه لا يجب أن يكون لديك كائن DataContract المستخدم في مكان آخر في طلبك. يجب أن يمر عبر نوع محول أو محول لقراءة/كتابة المحتوى إلى الكائنات الخاصة بالتطبيق. في هذا التحويل (أو كائنات التطبيق الخاص بك) حيث يمكنك القيام ببعض التحقق من الصحة. كلما كانت طبقة نقل البيانات الخاصة بك أبسط كلما كان ذلك أفضل.

بشكل مقنع ، قد تضيف رمز التسجيل/التصحيح في المستوطنين/الذين يحصلون على المال (ويفضل بشكل مؤقت) لتتبع مدخلات/مخرجات البيانات حسب الحاجة. حتى الآن ، هذه هي الحالة الوحيدة التي شعرت فيها بوضع أي شيء بخلاف الخصائص البسيطة في كائن DataContract (ومرة أخرى ، فعلت ذلك مؤقتًا فقط).

تحرير: لماذا هذا هو الملف المولدة الافتراضية ، لست متأكدا. تستخدم كائنات My DataContract دومًا الخصائص التلقائية. أود أن أقترح ربما كان هذا التراجع إلى .NET 2.0 قبل طرح الخصائص التلقائية ، ولكن لم يتم تقديم WCF/DataContracts حتى 3.0 على أي حال.

0
وأضاف