أين يجب أن توجد مجموعات البيانات في بنية n-tier (متعددة الطبقات)؟

Question

نحن نجري حاليًا مناقشة حول ما إذا كان ينبغي إدراج مجموعة البيانات في طبقة البيانات أو طبقة الأعمال؟

يعتقد صديقي أن جميع مكونات ADO.NET يجب أن توضع في طبقة البيانات.بالنسبة لي لا يبدو هذا صحيحا للأسباب التالية:

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

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

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

هل يمكن لبعض الخبراء من الطبقة N أن يساعدونا في تحديد الطريق الذي يجب أن نسلكه؟شكرا لك مقدما

Answer 1

حيث أنا الآن نقوم بإرجاع مجموعات البيانات وجداول البيانات وصفوف البيانات وقارئي البيانات من طبقة البيانات إلى طبقة الأعمال.

الأساس المنطقي هو أن هذه الأنواع ليست خاصة بنكهة ديسيبل.سواء كنت تستخدم mysql، أو Access، أو SQL Server، أو Oracle، أو أي مجموعة بيانات تعتبر مجموعة بيانات، وبالتالي لا بأس بالعودة من طبقة بيانات مستوى الجذر.

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

---

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

Answer 2

في رأيي، لا تستخدم DataSet على الإطلاق.لا تستخدم حتى DataSet المكتوبة.هذه بنيات قديمة تم إنشاؤها قبل LINQ.انتقل مباشرة إلى التاريخ القديم، وادخل في زمن المضارع:استخدم LINQ للكيانات وإطار الكيان (EF).الاثنان مرتبطان ارتباطًا وثيقًا ولكن ليسا نفس الشيء.

لا تكشف كيان EF عبر حدود الخدمة.لسوء الحظ، اختارت Microsoft الكشف عن تفاصيل التنفيذ عند إجراء تسلسل لكيان ما.بخلاف ذلك، استخدم EF واستمتع بمتعة أكبر بكثير مما كنت ستحصل عليه مع DataSet.

Answer 3

حسنًا، عزل الوصول إلى البيانات ليس بالأمر الجديد:لقد فعلنا ذلك منذ 15 عامًا (نعم، منذ 15 عامًا!).

لقد عملت في الكثير من الأماكن وشاهدت الكثير من طبقات البيانات المعزولة.

لكنني أبداً -- أبداً !- شاهد مصدر بيانات يتم استبداله!

نعم رأيته مرتين:ومرتين، نقوم أيضًا باستبدال طبقة البيانات القديمة وجميع البرامج العلوية...

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

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

في كتبي، أي طبقة بيانات غبية.

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

Answer 4

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

Answer 5

المشكلة الأساسية التي أواجهها مع DataSets هي أن بنياتها هي مرآة دقيقة لمخطط قاعدة البيانات.

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

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

Answer 6

يجب أن أوافق على عدم استخدام dataSets على الإطلاق.أحد التطبيقات التي عملت عليها كانت مجموعات البيانات في كل من طبقة البيانات وطبقة التطبيق.تطابقت DataLayer DataSets مع قاعدة البيانات حيث قامت مجموعات بيانات طبقة التطبيق بإلغاء تسوية المعلومات لجعلها أكثر قابلية للاستهلاك في الواجهة الأمامية.