ما هي أفضل طريقة ومناسبة لكتابة الرمز في WinForms؟

Question

ما هي أفضل طريقة لكتابة الرمز؟

(1) مثل كتابة الكود مباشرة في button_click() حدث.

أو

(2) قم بعمل وظيفة هذا الرمز الذي أكتب فيه button_click() الحدث واكتب هذه الوظيفة في فئة واحدة ثم هذه الوظيفة يجب أن أتصل بها في button_Click() الحدث. هل يطلق عليه three-tier approach لكتابة الرمز؟

كما هو الحال في button_Click() حدث أكتب الرمز لحفظ السجلات في csv file from datatable. لذلك يجب أن أكتب هذا الرمز في button_Click() الحدث أو يجب أن أقوم بوظيفة جديدة وفئة جديدة وأكتب هذه الرمز في هذه الوظيفة وهي الفئة الجديدة واتصال تلك الوظيفة في button_Click() حدث.

هذا مثال واحد فقط ولكن أنا أتحدث عن كل الرمز المكتوب في طلبي ما هو appropriate and best way to write the code وما هي الفوائد؟ لاحظ أنني أكتب الرمز في WinForms مع C#.

Answer 1

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

ألق نظرة أيضًا على نمط MVC, ، ستفهم الفكرة بأكملها بشكل أفضل.

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

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

Answer 2

كل هذا يتوقف على الموقف.

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

كل هذا يتوقف على الموقف.

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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