أين يجب أن أتعامل مع الاستثناءات ، في BLL ، DAL أو PL؟

Question

ما هو أفضل مكان للتعامل مع الاستثناءات؟ BLL ، DAL أو PL؟

هل يجب أن أسمح للطرق في DAL و BLL بإلقاء الاستثناءات على السلسلة والسماح لـ PL بالتعامل معها؟ أم يجب أن أتعامل معهم في BLL؟

على سبيل المثال

إذا كان لدي طريقة في DAL الخاصة بي ، فإن تصدر "ExecuteNonquery" وتحديث بعض السجلات ، وبسبب سبب واحد أو أكثر ، تتأثر 0 صفوف. الآن ، كيف يجب أن أخبر PL الخاص بي أنه سواء حدث استثناء أم أنه لم يكن هناك صفوف متطابقة مع هذه الحالة. هل يجب أن أستخدم "حاول التقاط" في رمز PL الخاص بي وأعلمه من خلال استثناء ، أو يجب أن أتعامل مع الاستثناء في DAL وإرجاع بعض التعليمات البرمجية الخاصة مثل (-1) للسماح لـ PL بالتمييز بين (الاستثناء) و (لا صفوف متطابقة حالة أي صفوف الصفر المتأثرة)؟

Answer 1

ليس من المنطقي السماح باستثناء يتم إلقاؤه في فقاعة DAL حتى PL - كيف من المفترض أن يتفاعل المستخدم إذا تعذر إنشاء اتصال قاعدة البيانات؟

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

Answer 2

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

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

تحرير: (توضيح) عليك أن تتعامل مع بعض الأخطاء في كل مكان - لكن هذه ليست قاعدة "كل وظيفة". في معظم الأوقات ، يسمح لهم بالفقاعة إلى PL ومعالجة الخطأ العالمي .NET مع الكود الخاص بك: قم بتسجيل مكدس المكالمات الكامل من هناك عبر روتين مشترك يمكن الوصول إليه من جميع الطبقات الثلاثة عبر معالجات الأحداث (انظر التحرير في أسفل الرسالة ). هذا يعني أنك ستفعل ليس احصل على/تصطاد من خلال كل رمزك ؛ فقط الأقسام التي تتوقعها وخطأها ويمكنك التعامل معها هناك ، أو ، أو أقسام غير حرجة ، والتي تقوم بها بتسجيل الخطأ وإبلاغ المستخدم بالوظائف غير المتوفرة (هذا أكثر ندرة وبرامج فائقة الاعتماد/الحرجة)

بصرف النظر عن ذلك ، عند العمل مع عناصر محدودة الموارد ، غالبًا ما أستخدم الكلمة الرئيسية "استخدام" أو حاول/أخيرًا/نهاية المحاولة بدون الصيد. لأعلام قفل/mutex/إعادة دخول multithreading/إلخ. تحتاج أيضًا إلى المحاولة/أخيرًا في جميع الحالات حتى لا يزال برنامجك يعمل (وخاصة التطبيقات الحكومية).

إذا كنت تستخدم استثناءات بشكل غير صحيح (على سبيل المثال ، للتعامل مع غير الأسواق عندما يجب أن تستخدم البيان if أو التحقق من ذلك ، ستعمل عملية iffy قبل أن تجربها) ، ستنهار هذه الفلسفة أكثر.

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

تعديل: حاجة أخرى على الأقل الحصول على روتين التسجيل في PL - سيعمل هذا بشكل مختلف اعتمادًا على المنصة. يقوم تطبيق نعمل على مشاركته في BLL/DAL مع 3 إصدارات PL: إصدار ASP.NET ، وإصدار WinForms ، وإصدار اختبار الانحدار وضع دفعة تطبيق وحدة التحكم. روتين التسجيل الذي يطلق عليه هو في الواقع في BLL (DAL فقط يرمي الأخطاء أو يعالج تمامًا أيًا أو يعيد إدخاله). لكن هذا يثير حدثًا يتم التعامل معه من قبل PL ؛ على الويب ، يضعه في سجل الخادم ويقوم بعرض رسالة خطأ على غرار الويب (رسالة ودية للإنتاج) ؛ في Winforms ، تظهر نافذة رسالة خاصة مع معلومات الدعم الفني ، وما إلى ذلك وتسجيل الخطأ وراء الكواليس (يمكن للمطورين القيام بشيء "سري" لرؤية المعلومات الكاملة). وبالطبع في إصدار الاختبار ، فهي عملية أبسط بكثير ولكنها مختلفة أيضًا.
لست متأكدًا من كيفية فعل ذلك في BLL باستثناء تمرير معلمة "ما هي المنصة" ، ولكن نظرًا لأنه لا يشمل مكتبات WinForms أو ASP التي يعتمد عليها التسجيل ، فستكون هذه خدعة.

Answer 3

الجواب القصير هو أن يتوقف!

يجب عليك فقط التعامل مع استثناء إذا كان بإمكانك فعل شيء مفيد به. يعتمد "شيء مفيد" مرة أخرى على ما تفعله. قد ترغب في تسجيل تفاصيل الاستثناء على الرغم من أن هذا لا يتعامل معه حقًا ويجب عليك إعادة تقديم الاستثناء بعد تسجيله في معظم الظروف. قد ترغب في لف الاستثناء في بعض الاستثناءات الأخرى (ربما مخصصة) من أجل إضافة المزيد من المعلومات إلى الاستثناء. مع لمس mebeckish ، قد ترغب في محاولة التعافي من الاستثناء من خلال إعادة تشغيل العملية على سبيل المثال - يجب أن تكون حريصًا على عدم إعادة المحاولة إلى الأبد. أخيرًا (عذر التورية) قد ترغب في استخدام كتلة أخيرًا لتنظيف أي موارد مثل اتصال DB المفتوح. ما تختار القيام به بالاستثناء سيؤثر على المكان الذي تتعامل معه. من المحتمل أنه لا يوجد قدر كبير من الأشياء المفيدة التي يمكن القيام بها مع العديد من الاستثناءات بخلاف الإبلاغ عن المستخدم أن خطأ حدث في هذه الحالة سيكون من المقبول أكثر من التعامل مع الاستثناء في طبقة واجهة المستخدم والإبلاغ عن المشكلة للمستخدم (ربما يجب عليك تسجيل الاستثناء أيضًا ، بعد ذلك أسفل طبقاتك).

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

هذه هي مقالة معقولة حول استثناء التعامل مع أفضل الممارسات.

Answer 4

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

Answer 5

يجب أن تدير جميع الطبقات في تطبيقك الاستثناءات. هذا يعرف أنه تقاطع الذرة ، لأنه يظهر في جميع طبقاتك. أعتقد أن استخدام إطار عمل مثل Enterprise Investment Block مع Unity ، سوف ينتهي بك الأمر برمز أفضل بشكل عام. نلقي نظرة على هذا المنصب

http://msdn.microsoft.com/en-us/library/ff664698(v=pandp.50).aspx

سوف يستغرق الأمر وقتًا ما لإتقانه ، ولكن هناك الكثير من الأمثلة وشاشة الشاشة الموجودة هناك.

Answer 6

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

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

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

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

Answer 7

السؤال لك هو أين الاستثناء ذي صلة؟ إذا كان استثناءً من الوصول إلى البيانات ، فيجب اكتشافه في DAL. إذا كان استثناء المنطق ، فيجب أن يتم اكتشافه في BLL. إذا كان استثناء عرض تقديمي ثم في PL.

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

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

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