سؤال

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

أعمل حاليًا على مجموعة من الأدوات:

  • AC# خدمة Windows ، للحفاظ على قاعدة بيانات Oracle بشكل أساسي.
  • AC# Windows Service ، (والتي سيتم استخدامها في مواقع عقدة متعددة) لمعالجة محتوى قاعدة البيانات.
  • واجهة ويب ASP.NET لتسهيل إدارة "النظام" العام

تم حاليًا تطوير خدمات Windows كتطبيقات وحدة تحكم (لتسهيل تصحيح الأخطاء/التطوير) وأنا في خضم تحويلها إلى خدمات.بعد اختبار هذه الخدمات لبضعة أيام، وجدت أنني أرغب في زيادة دقة التسجيل الخاص بي.أجد أنني أفتقد Console.WriteLine() وأرغب في توفير مصدر سجل بديل مثل ملف ثابت لهذا النوع من المخرجات.وقد دفعني هذا إلى التفكير، "هل يجب أن أستخدم إطار عمل، أم أنني حصلت على ما يكفي منه؟"

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

من خلال الأدوات المذكورة أعلاه، هناك حالات متعددة للتسجيل لا تختلف عن:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

على الرغم من أنها أساسية تمامًا، إلا أن هذه الطريقة تستخدم الانعكاس لتحديد مصدر الخطأ.

سؤالي

بالنظر إلى حل التسجيل الحالي الخاص بي يبدو "كافيًا" من حيث ما يفعله وكيف يتكامل مع جميع حلولي.ومع ذلك، فقد كنت أبحث في أطر عمل التسجيل (لا سيما log4net) وأبهرتني ميزاتها.إن القدرة على إضافة تنسيق إخراج آخر، إذا لزم الأمر في المستقبل (مثل خادم SMTP)، تبدو رائعة بالنسبة لي!:)

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

شكرًا،

هل كانت مفيدة؟

المحلول

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

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

أما بالنسبة لتنفيذه، فهناك العديد من المواقع الجيدة التي تتحدث معك خلال عملية الإعداد.إن كيفية الاستفادة فعليًا من كائنات التسجيل التي يوفرها لك log4net هي خيار معماري، ولكن يمكنك ببساطة تغيير مُنشئ الكائن ليأخذ كائن log4net ومن داخل هذا الكائن، ما عليك سوى استخدام كائن log4net كما تفعل مع Console.WriteLine .

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

نصائح أخرى

نعم.يعد استخدام إطار عمل تسجيل موجود ومثبت (مثل Log4net) فكرة جيدة.

يمكن تكوين Log4Net في وقت التشغيل (وهو أمر رائع لتتبع المشكلات في كود الإنتاج).

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

نعم، أنت بالتأكيد تريد استخدام إطار عمل التسجيل.سيسمح لك إطار التسجيل بما يلي:

  • قم بتعيين مستويات التسجيل لمثيلات المسجل المختلفة.
  • قم بتعيين "الملحقين" أو الإخراج لكل مثيل من مثيلات المسجل المختلفة.

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

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

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

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

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

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

سأوجه صيحة إلى NLog (http://nlog-project.org/home) لأنه لا يعاني من متلازمة "Straight Java Port - ثم أعد الكتابة" لمعظم oss .Net libs.

كانت بعض الفوائد الرئيسية بالنسبة لنا هي Logger.IsFooEnabled السريع جدًا (القراءة المتقلبة) والأداء العام للنظام.

رغم ذلك، كل منها خاص بها، لكنني شخصيًا أفضل NLog لمشاريعي (وبعض عملائي أيضًا).

هتاف ، فلوريان

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

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

أعتقد أن مسؤولي النظام يتوقعون أن تقوم الخدمات بتسجيل الدخول إلى سجل أحداث التطبيق في windows.

ابحث عن System.Diagnostics.EventLog، على الرغم من أن log4net سيكتب إليه أيضًا..

البيان الأولي في موقع log4j قد تساعدك في الإجابة على بعض أسئلتك، المبادئ الأساسية هي نفسها في log4net:

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

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

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

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

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

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top