تنفيذ منطق التصميم

فلسفات نهج التنفيذ

نهج الشلال

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

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

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

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

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

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

يمكن أن يكون للمشروع مراحل أكثر أو أقل عند استخدام نهج الشلال ، ولكن الميزة الرئيسية هي بداية ونهاية رسمية للغاية لكل مرحلة ، مع تسليمات رسمية للغاية.

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

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

تطوير البرامج بتقنية أجيل

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

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

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

التنمية المتزايدة

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

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

برنامج التحكم في التدفق

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

كود المنظم

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

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

خلق المشروع

طبقات

الخطوة الأولى هي النظر في الطبقات المنطقية. لاحظ أن الطبقات ليست هي نفسها الطبقات ، وغالبًا ما يتم الخلط بينها أو حتى تعتبر نفسها.

الطبقات مقابل الطبقات

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

الشكل 8-1: التنظيم الأساسي ثلاثي المستويات

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

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

الطبقات المادية

في تطبيق المؤسسة ، تتوقع أن يكون لديك العديد من العملاء لنفس المنطق. في الواقع ، ما يجعل التطبيق تطبيقًا مؤسسيًا هو أنه سيتم نشره في ثلاث طبقات: العميل ، وخادم التطبيق ، وخادم قاعدة البيانات. إن تطبيق Microsoft Office Access الذي أنشأه قسم المبيعات في شركتك ، رغم أهميته الكبيرة لقسم المبيعات ، ليس تطبيقًا خاصًا بالشركات.

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

إضافة الأنماط إلى الطبقات

توفر الطبقات الأساسية الثلاث نظرة عامة عالية المستوى. دعنا نضيف بعض الأنماط الهيكلية لإنشاء بنية مؤسسة قوية. تظهر النتيجة في الشكل 8-2.

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

تدفق القرار

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

هناك طريقتان لتنظيم خدماتك:

• العمل الموجهة لل
• دولة مدفوعة

نهج موجه نحو العمل

من خلال تنظيم الخدمات بناءً على إجراءات المستخدم ، فأنت تقوم بتنفيذ منطق التطبيق من خلال تقديم الخدمات ، كل منها يعالج طلبًا محددًا من طبقة العرض التقديمي. يُعرف هذا أيضًا باسم نمط البرنامج النصي للمعاملة. هذا النهج شائع لأنه بسيط ويبدو طبيعيًا جدًا. من الأمثلة على الطرق التي تتبع هذا الأسلوب BookStoreService.AddNewOrder (ترتيب الطلب) و BookStoreService.CancelOrder (int orderId).

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

نهج الدولة مدفوعة

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

مشاريع بنية البيانات

يجب عليك اتخاذ عدة خيارات عند تصميم هياكل البيانات الخاصة بك. الخيار الأول هو آلية تخزين البيانات ، والثاني هو الاستخدام المقصود للبيانات ، والثالث هو متطلبات الإصدار. هناك ثلاث طرق للنظر في تصميمات بنية البيانات:

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

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

اختيار محرك تخزين البيانات

عند تصميم التطبيق الخاص بك ، سيكون عليك بلا شك تصميم نوع من مخزن البيانات. تتوفر المخازن وأشكال تخزين البيانات التالية:

• سِجِلّ
• ملف app.config
• xml
• ملفات نصية عادية
• قاعدة البيانات
• انتظار الرسائل

لكل متجر خصائصه الفريدة ويمكن تخصيصه وفقًا لمتطلبات محددة.

تصميم تدفق البيانات

تدفق البيانات باستخدام ADO.NET

من خلال تنفيذ الخدمات التي تركز على البيانات في طبقة منطق التطبيق ، ستقوم بتصميم تدفق البيانات باستخدام ADO.NET. توفر مكتبة فئة .NET Framework واجهة برمجة تطبيقات شاملة (API) لمعالجة البيانات في التعليمات البرمجية المُدارة. يشار إليها باسم ADO.NET ، يمكن العثور على API في مساحة الاسم System.Data. يعد الفصل الكامل بين ناقلات البيانات ومخازن البيانات ميزة تصميم مهمة لـ ADO.NET. تم تصميم فئات مثل DataSet و DataTable و DataRow لتخزين البيانات ولكن لا تحتفظ بأي معرفة بمصدر البيانات. هم يعتبرون مصدر البيانات حيادي. تهتم مجموعة منفصلة من الفئات ، مثل SqlConnection و SqlDataAdapter و SqlCommand ، بالاتصال بمصدر البيانات واسترداد البيانات وملء DataSet و DataTable و DataRow. توجد هذه الفئات في مساحات أسماء فرعية مثل System.Data.Sql و System.Data.OleDB و System.Data.Oracle وما إلى ذلك. بناءً على مصدر البيانات الذي تريد الاتصال به ، يمكنك استخدام الفئات في مساحة الاسم الصحيحة ، وبناءً على نطاق المنتج الذي تستخدمه ، ستجد أن هذه الفئات تقدم وظائف أكثر أو أقل.

نظرًا لأن DataSet غير متصل بمصدر البيانات ، يمكن استخدامه بنجاح تام لإدارة تدفق البيانات في أحد التطبيقات. يوضح الشكل 8-5 تدفق البيانات عند القيام بذلك.

دعنا نلقي نظرة على هذا المشروع ونتخيل أن شخصًا ما قد سجل الدخول إلى مكتبتك وطلب ثلاثة كتب. أدارت طبقة العرض حالة عربة التسوق. العميل جاهز لتقديم الطلب وقد قدم جميع البيانات اللازمة. اختار إرسال الطلب. تقوم صفحة الويب بتحويل جميع البيانات إلى DataSet تحتوي على جهازي DataTables ، أحدهما للطلب والآخر للطلب ؛ إدراج DataRow للأمر ؛ ويدرج ثلاثة صفوف DataRows لأسطر الطلب. ثم تعرض صفحة الويب هذه البيانات مرة أخرى للمستخدم مرة أخرى ، وربط عناصر التحكم بالبيانات مقابل DataSet وتسأل هل أنت متأكد؟ يقوم المستخدم بتأكيد الطلب ويتم إرساله إلى الطبقة المنطقية للتطبيق. تقوم طبقة منطق التطبيق بفحص DataSet لمعرفة ما إذا كانت جميع الحقول المطلوبة لها قيمة وتقوم بإجراء فحص لمعرفة ما إذا كان لدى المستخدم أكثر من 1000 US$. 00 على الفواتير المستحقة. إذا سارت الأمور على ما يرام ، يتم تمرير DataSet إلى طبقة الوصول إلى البيانات ، والتي تتصل بقاعدة البيانات وتقوم بإنشاء عبارات إدراج من معلومات DataSet.

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

تدفق البيانات باستخدام رسم الخرائط العلائقية للكائن

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

يوضح الشكل 8-6 تدفق بيانات مشابهًا للشكل 8-5 ، إلا أنك قمت الآن بإضافة طبقة تعيين علائقية للكائنات واستبدلت كائنات DataSet بحوامل بيانات مختلفة.

الآن افعل نفس الخطوة خطوة كما كان من قبل ؛ تخيل أن شخصًا ما متصل بمكتبتك وطلب ثلاثة كتب. أدارت طبقة العرض حالة عربة التسوق. العميل جاهز لتقديم الطلب وقد قدم جميع البيانات اللازمة. اختار إرسال الطلب. تقوم صفحة الويب بتحويل جميع البيانات إلى DTO ، مع الاحتفاظ بالبيانات لطلب واحد وثلاثة أسطر ترتيب ، مما يؤدي إلى إنشاء الكائنات حسب الحاجة. تعرض صفحة الويب هذه البيانات مرة أخرى إلى المستخدم مرة أخرى ، وتتحكم في ربط البيانات بـ DTO باستخدام ObjectDataSource في ASP.NET 2.0 وتسأل هل أنت متأكد؟ يؤكد المستخدم الاختيار ويتم تقديم DTO إلى الطبقة المنطقية للتطبيق. تقوم طبقة منطق التطبيق بتحويل DTO إلى كائن أعمال من النوع Order بخاصية تحتوي على ثلاثة كائنات OrderLine. طريقة الطلب. يتم استدعاء Validate () للتحقق من صحة الأمر والتحقق من أن جميع الحقول المطلوبة لها قيمة ، ويتم إجراء فحص لتحديد ما إذا كان لدى المستخدم أكثر من R$ 1،000.00 في القسائم المعلقة. للقيام بذلك ، سيستدعي الأمر Order.Customer.GetOutstandingBills (). إذا كان كل شيء على ما يرام ، فسيتم استدعاء طريقة Order.Save (). سيمر الطلب عبر طبقة رسم الخرائط العلائقية للكائن ، حيث يتم تعيين الطلب وصفوف الطلب إلى DataTable في DataSet ، ويتم تمرير DataSet إلى طبقة الوصول إلى البيانات ، والتي تتصل بقاعدة البيانات وتقوم بإنشاء عبارات إدراج من المعلومات الموجودة في DataSet. هناك ، بالطبع ، العديد من الطرق التي يمكن أن يحدث بها رسم الخرائط العلائقية للكائنات ، ولكن لن تتضمن جميعها التحويل إلى DataSet. سينشئ البعض عبارة insert مباشرة لكنهم ما زالوا يستخدمون طبقة الوصول إلى البيانات لتنفيذ هذا البيان.

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

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

الخدمات المستندة إلى المخطط

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

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