تطبيق قاعدة بيانات N-Linered دون استخدام Orm، كيف تحدد UI ما تحتاجه من البيانات لعرضه؟

Question

أبحث عن مؤشرات ومعلومات هنا، سأجعل هذا CW منذ أن أظن أنه ليس لديه إجابة واحدة صحيحة واحدة. هذا هو ل C #، وبالتالي سوف أقدم بعض المراجع إلى LinQ أدناه. أنا أيضا اعتذر عن الوظيفة الطويلة. اسمحوا لي أن ألخص السؤال هنا، ثم يتبع السؤال الكامل.

ملخص: في تطبيق UI / Bll / DAL / DAL 4-DILEERED، كيف يمكن أن يتغير التغييرات إلى واجهة المستخدم، لإظهار المزيد من الأعمدة (قل في شبكة)، تجنب التسرب عبر طبقة منطق الأعمال وإلى طبقة الوصول إلى البيانات، إلى احصل على تعليق البيانات لعرضه (على افتراض أنه بالفعل في قاعدة البيانات).

---

دعنا نفترض تطبيق الطبقات مع 3 (4) طبقات:

• واجهة المستخدم (UI)
• طبقة منطق الأعمال (BLL)
• طبقة الوصول إلى البيانات (DAL)
• قاعدة البيانات (DB؛ الطبقة الرابعة)

في هذه الحالة، DAL مسؤولة عن بناء بيانات SQL وتنفيذها مقابل قاعدة البيانات، وإرجاع البيانات.

هي الطريقة الوحيدة للبناء "بشكل صحيح" مثل هذه الطبقة فقط "تحديد *"؟ بالنسبة لي هذا كبير لا لا، لكن اسمحوا لي أن أشرح لماذا أتساءل.

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

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

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

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

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

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

وما بعد ذلك عندما يتم تغيير واجهة المستخدم، لمساعدة المستخدم على أبعد من ذلك، بإضافة المزيد من الأعمدة، ما مدى عمق / يجب علي أن أذهب لتغيير UI؟ (على افتراض أن البيانات موجودة في قاعدة البيانات بالفعل، لا يلزم وجود تغيير هناك.)

أحد الاقتراحات التي جاءت هي استخدام LinQ-To-SQL و IQueryable، بحيث إذا كان دال، الذي يتعامل مع ما (كما هو الحال في أي أنواع البيانات) ولماذا عاد (كما هو الحال في حيث في كل من البنود) التي تم إرجاعها، يمكن ل Bll من المحتمل أن ترجع تلك التي يصل إلى UI، والتي يمكن أن تقوم بعد ذلك ببناء استعلام LinQ من شأنها استرداد البيانات التي يحتاجها. يمكن بعد ذلك سحب رمز واجهة المستخدم في الأعمدة التي يحتاجها. هذا من شأنه أن يعمل منذ مع احبابه الأقرباء، وسوف ينتهي واجهة المستخدم في الواقع تنفيذ الاستعلام، ويمكن بعد ذلك استخدام "تحديد جديد {x، y، z}" لتحديد ما تحتاجه، وحتى الانضمام إلى جداول أخرى، إذا لزم الأمر.

هذا يبدو فوضوي لي. أن تقوم UI بتنفيذ رمز SQL نفسه، على الرغم من أنه قد تم إخفاءه خلف واجهة LinQ.

ولكن، لذلك يحدث هذا، لا ينبغي السماح ل BLL أو DAL بإغلاق اتصالات قاعدة البيانات، وفي نوع IOC من العالم، قد تحصل على خدمة DAL-Service بشكل أسرع من رمز UI، بحيث قد ينتهي استعلام LinQ فقط مع الاستثناء "لا يمكن الوصول إلى كائن التخلص".

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

من فضلك قل لي كيف غبي ونثبتني خطأ؟

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

Answer 1

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

UI <-- (viewmodel) ---> BLL <-- (model) --> Peristence/Data layers

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

Answer 2

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

أوافق تماما على أن مخاوف دال لا ينبغي السماح بالتسرب إلى الطبقات العليا، لذلك فإن BLL العازل ضروري.

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

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

تمرين مهم للغاية هو تحليل وعرضها بشكل صحيح مجاميع نموذج المجال بحيث يضربون الرصيد الصحيح. الكتاب تصميم مدفوعة المجال يحتوي على بعض التحليلات المضيئة جدا من مجاميع النمذجة.

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

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