سؤال

أقوم بإنشاء موقع ويب صغير للمتعة/التعلم باستخدام تصميم متعدد الطبقات للويب/الخدمة/الوصول إلى البيانات.

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

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

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

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

المحلول 3

سلبيات:

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

سيكون من الأفضل لك الذهاب إلى فئات طبقة الوصول إلى الأعمال/البيانات غير الثابتة إما عن طريق:

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

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

نصائح أخرى

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

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

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

إذا كنت على استعداد لرمي OO خارج النافذة، فقد ترغب في التحقق من نمط Singleton أيضًا.

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

  • لا يمكنك بسهولة استبدال تطبيقات منطق عملك
  • لا يمكنك تحديد متغيرات الحالة لتسهيل تقسيم المنطق إلى طرق متعددة
  • من المؤكد أن افتراضك بأن المشكلات متعددة الخيوط لن تنشأ هو افتراض خاطئ
  • لا يمكنك الاستهزاء بهم بسهولة للاختبار

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

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

أود فقط أن أجعل طبقة عملك غير ثابتة؛سيجعل الأمر أسهل بكثير لصيانة التطبيق الخاص بك وتغييره وتطويره.

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

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

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