إيجابيات وسلبيات استخدام نمط DAO [مغلق]

Question

كما ذكرت في العنوان، أنا مهتم بمعرفة ما تفكرون به (كمطورين ذوي خبرة) حول استخدام نمط DAO، وتحديدًا داخل تطبيق الويب.ما هي المزايا التي وجدتها وما هي عواقب استخدامها التي لم تعجبك؟

Answer 1

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

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

Answer 2

ملحوظة:قد تجد عيوبًا أخرى، ولكن إليك قائمة سريعة من تجربتي

الايجابيات:

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

سلبيات:

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

Answer 3

فوائد استخدام نمط تصميم DAO

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

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

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

3. نظرًا لأن نمط DAO يعتمد على الواجهة، فإنه يعزز أيضًا مبدأ التصميم الموجه للكائنات "البرمجة للواجهة بدلاً من التنفيذ" مما يؤدي إلى كود مرن وعالي الجودة.

Answer 4

وكانت قوات من نمط DAO هي أنها تسمح لك لخلق طبقة تجريد لطيفة من نظام التخزين الفعلي. أنها توفر رؤية وجوه المنحى أكثر من طبقة استمرار وفصل نظيف بين المجال ورمز من شأنها أن تؤدي فعلا الوصول إلى البيانات (على التوالي JDBC والأطر المثابرة، ORM أو حتى JPA).

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

Answer 5

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

• التجريد للتنفيذ الفعلي للوصول إلى قاعدة البيانات يفصل استراتيجية الوصول إلى البيانات عن منطق أعمال المستخدم.لقد سمح لنا ذلك باختيار استراتيجية تنفيذ قصيرة المدى (قالب Spring JDBC) لمرحلة المشروع الأولية مع خيار الانتقال إلى IBATIS أو Hibernate في وقت لاحق.(خيار لسنا في وضع يسمح لنا باتخاذه في هذا الوقت).
• يقدم الفصل فوائد كبيرة في قابلية الاختبار حيث يمكن الاستهزاء بتنفيذ الوصول إلى البيانات بالكامل في اختبار الوحدة.(ربما هذه هي الفائدة الأكبر)
• يتيح لنا الجمع بين هذا مع Spring إمكانية إدخال أي تطبيق لقاعدة البيانات في النظام الذي نختاره (على الرغم من أن هذا ربما يتحدث عن DI أكثر من نمط DAO).

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

Answer 6

طليعة

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

يخدع

• أقل "إثارة" من استخدام أحدث إطار عمل
• لا يستطيع المطورون اختراع عجلاتهم الخاصة (قد يكون محترفًا :-))

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

تحذير، اعتمادًا على موقفك، قد يكون استخدام إطار عمل الثبات بديلاً جيدًا لترميز DAO الخاص بك.

Answer 7

وماذا بديل أنت تنظر؟

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

وذلك أن يترك مسألة بالضبط كيفية القيام طبقة المثابرة. أن الافتراض بلدي سيكون لاستخدام JPA (أو أطر مماثلة). أنا لا نرى في ذلك سبيل المثال متطورة من DAO.

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

Answer 8

وبرو: فصل مجردة
يخدع: كود النمطي (الحمد لله لرمز / مولدات القوالب وفي ORM)

.