التحقق من البيانات في Getter/Setter أو في أي مكان آخر؟

Question

أنا أتساءل عما إذا كانت فكرة جيدة التحقق في getters و المستوطنين, أو في أي مكان آخر في الكود.

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

Answer 1

حسنًا، أحد أسباب احتواء الفصول عادةً على أعضاء خاصين باستخدام الحروف/المحددات العامة هو بالضبط أنه يمكنهم التحقق من البيانات.

إذا كان لديك رقم يمكن أن يتراوح بين 1 و100، فسأضع بالتأكيد شيئًا ما في جهاز الضبط الذي يتحقق من صحة ذلك ومن ثم ربما أقوم بطرح استثناء تم اكتشافه بواسطة الكود.السبب بسيط:إذا لم تقم بذلك في أداة الضبط، عليك أن تتذكر أن الحد من 1 إلى 100 في كل مرة تقوم بتعيينه، مما يؤدي إلى تكرار التعليمات البرمجية أو عندما تنساه، فإنه يؤدي إلى حالة غير صالحة.

أما بالنسبة للأداء، فأنا مع كنوث هنا:

"يجب أن ننسى الكفاءات الصغيرة، على سبيل المثال حوالي 97٪ من الوقت:التحسين المبكر هو أصل كل الشرور."

Answer 2

@Terrapin، إعادة:

إذا كان كل ما لديك هو مجموعة من خصائص [مجموعة/GET] البسيطة] ...قد تكون كذلك حقول

الخصائص لها مزايا أخرى على الحقول.إنها عقود أكثر وضوحًا، ومتسلسلة، ويمكن تصحيح أخطائها لاحقًا، وهي مكان جيد للتمديد من خلال الميراث.إن بناء الجملة الأكثر تعقيدًا هو تعقيد عرضي - .net 3.5 على سبيل المثال يتغلب على هذا.

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

Answer 3

هذا يعتمد.

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

Answer 4

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

بعد كل شيء، هذا هو المقصود من الخصائص.إذا كان كل ما لديك هو مجموعة من الخصائص مثل...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

...قد تكون أيضًا حقولًا

Answer 5

قد ترغب في التحقق من ذلك تصميم يحركه المجال, بقلم إريك إيفانز.لدى DDD فكرة المواصفات:

...كائنات قيمة تشبه المسند الصريح لأغراض متخصصة.المواصفات هي مسند يحدد ما إذا كان الكائن يفعل أو لا يفي ببعض المعايير.

أعتقد أن الفشل السريع هو شيء واحد، والآخر هو مكان الحفاظ على منطق التحقق من الصحة.المجال هو المكان المناسب للاحتفاظ بالمنطق وأعتقد أن كائن المواصفات أو طريقة التحقق من صحة كائنات المجال الخاص بك سيكون مكانًا جيدًا.

Answer 6

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

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

لا تحتاج إلى أي نوع من التحقق من صحة المُحصل، لأن المعلومات الموجودة على الكائن موثوق بها بالفعل لتكون صالحة.

لا تقم بحفظ التحقق الخاص بك حتى تحديث قاعدة البيانات !!من الأفضل أن اخفاق سريع.

Answer 7

أحب التنفيذ IDataErrorInfo ووضع منطق التحقق من الصحة الخاص بي في خصائص الخطأ وهذا [columnName] .وبهذه الطريقة، إذا كنت تريد التحقق برمجيًا مما إذا كان هناك خطأ، فيمكنك ببساطة اختبار أي من هذه الخصائص في التعليمات البرمجية، أو يمكنك تسليم التحقق من الصحة إلى ربط البيانات في Web Forms أو Windows Forms أو WPF.

خاصية الربط "ValidatesOnDataError" الخاصة بـ WPF تجعل هذا الأمر سهلاً بشكل خاص.

Answer 8

أحاول ألا أسمح أبدًا لكائناتي بالدخول إلى حالة غير صالحة، لذلك سيكون لدى أدوات الضبط بالتأكيد التحقق من الصحة بالإضافة إلى أي طرق تغير الحالة.بهذه الطريقة، لا داعي للقلق أبدًا من أن الكائن الذي أتعامل معه غير صالح.إذا احتفظت بأساليبك كحدود للتحقق، فلا داعي للقلق أبدًا بشأن أطر التحقق واستدعاءات أسلوب IsValid() المنتشرة في كل مكان.