1- ما هو نموذج كيانات البيانات EDM ؟

إذا كنت مهتما بمعرفة هذا المفهوم ، فيبدو انك لم تقرأ الباب الماضي فقرة " سمات اطار عمل كيان البيانات Entity Framework " ولانها المرة الاولى ، فلا مشكلة من اعادة كتابة التعريف مجددا لأجلك :

ما هو نموذج كيانات البيانات Entity Data Model ؟ هو عبارة عن توصيف لتعريف البيانات المبنية في entity framework . وبدون الـ EDM ، لا توجد علاقات Relationships ولا حتى كيانات بيانية entities في مخطط التصميم لديك Design Schema.

ويعد نموذج كيانات البيانات الجسر الواصل بين تطبيقك ومخزن البيانات ، فهو الذي يتيح لك التعامل مع المظهر المفهومي Conceptual View للبيانات بدل من التعامل معها بالطريقة المعهودة على شكل جداول بيانات حقيقية . وتستخدم كل واجهات البرمجة API’s الموجودة في اطار عمل Entitiy Framework ، الـ EDM في كل تواصل مع البيانات ، سواء كان ذلك لمجرد الحصول على البيانات ام من اجل تحديثها . وهنا تأتي أهمية الادوات Tools الخاصة بالـ Entity Framework والتي يقدمها لنا الاستاذ Visual Studio حيث يتكفل نيابة عنك بتوليد كل الفئات Classes اللازمة للعمل مع الكائنات عوضا عن جداول قاعدة البيانات .

سنتعرف في هذا الباب على التكونين المختلفين لنموذج كيانات البيانات ، فسنتعامل مع المصمم Designer وكذلك مع الوجه الآخر والحقيقي وهو نموذج XML .

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

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

2- بناء أول نموذج بيانات EDM خاص بك :

افتح فيجوال ستوديو وانشيء مشروعا جديدا من نوع Windows Forms ، توجه بعدها إلى القائمة Project واختر Add New Item ، ومن النافذة التي تظهر امامك اختر ADO.NET Entity Data Model :

دع اسمه الافتراضي Model1 ثم اضغط على زر Add .
سيظهر امامك المعالج التالي :

وهو يخيرك بين انشاء EDM فارغ او تكوينه بشكل تلقائي من قاعدة بيانات ، اختر الخيار الاول واضغط على Next ، لتظهر امامك المرحلة التالية من المعالج :

حيث تختار قاعدة البيانات المطلوبة ، وهنا فلتكن قاعدة البيانات التي اتفقنا على استخدامها وهي Northiwnd ، فقم باختيارها اينما كانت لديك ، ثم اضغط على زر Next .
في المرحلة التالية ، سيعرض امامك المعالج كافة الكائنات الموجودة في قاعدة البيانات ، كالجداول Tables ، والعروض views وكذلك الاجراءات المخزنة ، سنقوم في هذا المثال بإضافة الجداول Orders,OrderDetails,Products وتوجه بعدها إلى زر Finish :

الآن سيفتح أمامك فيجوال ستوديو على نافذة مصمم الـ EDM كما بالشكل التالي :

بهذا نكون قد تمكنا من انشاء EDM جديد وبه كل الفئات المطلوبة ، حيث يوجد ثلاث كيانات بيانية ( فئات Classes ) وقد اختصر عليك فيجوال ستوديو جهد كتابة عشرات الأسطر لها ، وحتى تتأكد من كلامي يمكنك التوجه إلى نافذة Solution Explorer ، بعدها اختر زر Show All Files واتجه إلى ملف Model1.edmx وافتح مستواه الفرعي واختر ملف Model1.Designer.vb وشاهد الكود الطويل الموجود به :

ليس هذا فقط ، فالملف Model1.edmx ما هو الا ملف XML وللتأكيد على كلامي ، يمكنك اغلاق الملف ، ثم النقر على اسمه من solution Explorer بالزر الأيمن واختر الخيار Open With واختر XML Editor وشاهد بنفسك النتيجة :

كرمي البرمجي يحتم علي الا ان اعرض عليك مثالا عن كيفية استخدام النموذج السابق في عرض البيانات ، لذلك توجه إلى نافذة Data Sources واختر منها Add New Data Source ومن النافذة التي ستظهر امامك طبعا اختر الخيار Objects :

ومن الخطوة التالية افتح اسم المشروع واختر الفئة Orders :

ثم انه المعالج بالزر Finish ، وتوجه بعدها إلى النافذة Form1 وستشاهد ان النافذة Data Sources ستكون بالشكل التالي :

حيث ظهر الجدول Orders والحقول التابعه له ، لكن مهلا تذكر ان تلك كائنات وليست جدول وحقوله ! والسبب اننا اشرنا إلى الفئات والحقول التي تم توليدها من خلال الـ EDM ، لذلك قم بسحب الجدول Orders إلى النافذة Form1 وستكون النتيجة كما يلي :

وتوجه بعدها إلى حدث التحميل Form_Load التابع للنافذة form1 واكتب الكود التالي :

   1: Dim MyOrders As New NORTHWNDEntities

   2:  

   3: Me.OrdersBindingSource.DataSource = MyOrders.Orders

ثم قم بتشغيل البرنامج ليظهر لك وقد ازدان بالبيانات :

مبارك ! فقد انتهيت من هذا من تكوين EDM جديد من قاعدة البيانات Northwind يخص الجداول الثلاثة Orders,OrderDetails,Products وشاهدنا كيف ان المعالج ولد نيابة عنا مئات الأسطر البرمجية القياسية ، وقد قمنا بعمل ربط بسيط Simple binding للبيانات على اداة DataGridView وشاهدنا كيف ان كل هذا سهل جدا ولا يتخطى خطوات صغيرة وقصيرة .

1- مصمم كيانات البيانات Entity Designer وخصائص الكيانات Entities Properties :

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

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

بالنسبة للعلاقات Relationships ، فإنها ممثله بخط يصل بين الجداول المرتبطة ويحتوي على عنوان يمثل نوع العلاقة : واحد لواحد ، لوحد لمتعدد ، متعدد لمتعدد . والعلاقات هنا ما هي الا كائنات Object من نوع خاص وهو association بين الفئات .

وهناك ما يعرف بالـ Navigation Properties وهي خصائص تمثل الجداول الفرعية المربوطة بعلاقات ، فالجدول Orders مرتبط بالجدول OrderDetails ، لذلك فالكيان Orders ستحتوي على Navigation Property "خاصية ابحار " تسمى OrderDetails طالما اننا قمنا بوضع الجدول OrderDetail sايضا في EDM فسيقوم المصمم Designer مباشرة بإضفة خاصية ابحار Navigation Property للكيان Orders .

اذا قمنا باختيار أي حقل من أي جدول ، اقصد أي كائن من أي كيان entity ، فيمكننا مطالعة خصائصه من مربع الحوار Properties ، والتي من اهمها : EntityKey,Type,Name كما بالشكل التالي :

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

وبالمناسبة ، فهناك نافذتين اضافيتين تساعداننا في العمل مع الـ EDM وهما : Model Browser و Mapping Details ، الأولى شبيهه بنافذة الـ Class View حيث تعرض وجهين مختلفين لل EDM وهما وجه الفئات Classes ووجه قاعدة البيانات Data Store ، اما الثانية ، فهي تشبه نافذة تفاصيل الفئة Class Details حيث يمكنك التحكم بالحقول واضافتها وتعديل بعض خصائصها ، بالاضافة إلى اضافة شروط Conditions وأمور اخرى سنتعرف عليها لاحقا اذا شاء الله .

وبالنسبة إلى نافذة الادوات Tools فستجد هناك لسان تبويب بالإسم Entity Framework يحتوي على عدة ادوات : Entity,Association,Inheretance ، سنتعرف عليها ايضا لاحقا .

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

1- بنية ملف نموذج كيان البيانات EDM :

قلنا سابقا ان الـ Designer والـ EDM يريحان المبرمج ويحملان عن كاهله عملية توليد اكواد كثيرة جدا لفئات وكائنات يحتاجها في التعامل مع البيانات ، وقد سبق وان قمنا بفتح الملف Model1.Designer.vb ورأينا ان به اكواد كثيرة جدا ، ومن باب العلم بالشيء ، ولأنني اريد منك ان تعرف ما يدور خلف الكواليس حتى تفهم القضيه اكثر ، فضلت عرض هذه الفقرة عليك حتى تكون مطلعا اكثر :

في الحقيقة ، يوجد في ملف الـ EDM مجموعة من الفئات Classes تنقسم إلى نوعين : النوع الأول وهي فئة تدير باقي الفئات وتمثل المدير Manager ، بينما النوع الثاني وهي الفئات التي تمثل الجداول او كيانات البيانات entities .

ففي المثال الذي قمنا بعمله سابقا ، يوجد فئة تحمل الاسم NORTHWINDEntities وهي التي تمثل المدير Manager والذي من خلاله نتحكم بالـ Entities ، وهناك ثلاث فئات تحمل الاسماء : Products,Orders,OrderDetails كل منها تمثل Entity والتي قد تمثل جدول واحد او اكثر من قاعدة البيانات .

وسنتعرف بالتفصيل على بنية الفئات السابقة :

1- بنية فئة المدير : NORTHWINDEntities :

اذا كنت تذكر في السابق عندما قمنا بعمل اول برنامج يعتمد على الـ Entities ، فقد مر علينا في مرحلة اختيار عناصر قاعدة البيانات ادخل اسم فئة المدير تم تسميتها في حينها Model Namespace ، تكون هذه الفئة هي المدير الفعلي لباقي الفئات والمتحكم الحقيقي بها .

هذه الفئة معرفة على انها فئة جزئية Partial ، الأمر الذي يعني قابلية كتابتها في ملفات اخرى في المشروع ، وهذا يهم من يستخدم مبدأ تعدد الطبقات N-tier والذي سنتحدث عنه مستقبلا . هذه الفئة مشتقه من الفئة Global.System.Data.Objects.ObjectContext وبالتالي فهي ممثله الشرعي ، وكنا قد تحدثنا سابقا عن ان الكائن ObjectContext انه كائن مهم جدا في اطار العمل EF .

تحتوي على خصائص تمثل كل واحده منها Entity ، فهناك خصائص تحمل الاسم Products,Orders,OrderDetails وهذا على سبيل المثال تعريف الخاصية Orders :

   1: '''<summary>

   2: '''There are no comments for Orders in the schema.

   3: '''</summary>

   4: Public ReadOnly Property Orders() As Global.System.Data.Objects.ObjectQuery(Of Orders)

   5:     Get

   6:         If (Me._Orders Is Nothing) Then

   7:             Me._Orders = MyBase.CreateQuery(Of Orders)("[Orders]")

   8:         End If

   9:         Return Me._Orders

  10:     End Get

  11: End Property   Private _Orders As Global.System.Data.Objects.ObjectQuery(Of Orders)

ومن الكود السابق ، نستنتج ان الخاصية التي تمثل ال Entity المدعوه Orders ما هي الا كائن من النوع ObjectQuery للفئة Orders . الكود السابق سيكون مفهوما اكثر بعد قراءتك للفصول القادمة من الكتاب .

ستجد ايضا ان هناك طريقة Method بالإسم AddToXXX حيث XXX هو اسم الـ Entituy وهي طريقة تستخدم في اضافة كائن جديد " سجل جديد " إلى الكيان المعنية .

ايضا تحتوي هذه الفئة على ثلاث مشيدات Constructors مختلفة ، وحدث Event يدعى SavingChanges يتم اطلاقه بمجرد الرغبة في حفظ التعديلات، وطريقة تسمى OnContextCreated يتم استدعاؤها من قبل المشيدات لأي غرض تراه مناسبا .

1- بنية فئة الكيان Entity : Orders :

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

تتكون هذه الفئة من مجموعة من الخصائص Properties ، تمثل كل خاصية منها كائنا " حقلا في الجدول الحقيقي " ، ومنها على سبيل المثال الخاصية OrderID والتي تعريفها كما يلي :

   1: <Global.System.Data.Objects.DataClasses.EdmScalarPropertyAttribute(EntityKeyProperty:=true, IsNullable:=false),  _

   2:     Global.System.Runtime.Serialization.DataMemberAttribute()>  _

   3:    Public Property OrderID() As Integer

   4:        Get

   5:            Return Me._OrderID

   6:        End Get

   7:        Set

   8:            Me.OnOrderIDChanging(value)

   9:            Me.ReportPropertyChanging("OrderID")

  10:            Me._OrderID = Global.System.Data.Objects.DataClasses.StructuralObject.SetValidValue(value)

  11:            Me.ReportPropertyChanged("OrderID")

  12:            Me.OnOrderIDChanged

  13:        End Set

  14:    End Property   Private _OrderID As Integer

تخبر المصمم Designer ان هذه الخاصية تتبع المجموعة ScalerProperties والتي تقابل حقول في جداول قاعدة البيانات ، والثانية تساعدنا في استخدام هذه الخاصية كعضو بيانات DataMember عندما نتعامل مع Windows Forms او WPF وغيرها من تقنيات العرض .

وهناك استدعاء للطريقة ReportPropertyChanging والمعرفة في الفئة القاعدية EntityClient ، وهي التي تمثل ميزة تعقب التغييرات Changes Tracing التي تحدثنا عنها في الباب الأول . لدي المزيد لأخبرك عنه في الكود السابق في الفقرة التالية الخاصة بالطرق .

بالنسبة للطرق المتوفرة ، فهناك الطريقتان OnXXXChanged OnXXXChanging واللتان تستخدمان عندما يبدأ تعديل قيمة أي حقل وبعد الانتهاء من التعديل على التوالي .

وهناك الطريقة CreateXXX والتي تستخدم في انشاء كائن جديد من الفئة الحالية ، كالطريقة التالية :

   1: Public Shared Function CreateOrders(ByVal orderID As Integer) As Orders

   2:     Dim orders As Orders = New Orders

   3:     orders.OrderID = orderID

   4:     Return orders   End Function

وبالنسبة للاحداث Events ، فهناك الحدثان PropertyChanged و PropertyChangingفالأول يتم تنفيذه عند بداية التعديل والثاني بعد انتهاء التعديل . جدير بالذكر ان هذان الحدثان لا يتبعان الفئة EntityClient وإنما فضاء الأسماء System.componentModel .

واعتقد انك الآن وصلت إلى مرحلة استوعبت فيها الكثير عن بنية أي نموذج كيانات بيانات EDM .

1- المكونات الثلاث الرئيسية لملف النموذج Model.edmx :

هذا الجزء بالذات يحاول الكثير من المبرمجين تجاهله نظرا لأنهم يعتقدون عدم حاجتهم لتعديله او تطويره ، ولكن لو تذكر في الباب الماضي ، تحدثنا عن ان هناك المزيد من الخصائص والقدرات في نموذج البيانات EDM غير موجودة في المصمم Designer ولكنها متاحة للتعديل والاضافة بشكل يدوي في ملف الـ XML ، ومن هنا تأتي اهمية الحديث عن هذا الموضوع ، الا انني لن اطيل فيه كثير ان شاء الله تعالى لأنني اعلم ان الكثيرين يشمئزون من لغة XML ولو انها رائعة !

يتكون الملف Model.edmx من ثلاثة اجزاء رئيسية وهي النموذج المفهومي Conceptual Model ، الخريطة Mapping ، و نموذج التخزين والمنطق Storage/Logical Model .

النموذج المفهومي Conceptual Model ، هو جزء يختص بهيكلة النموذج ، حيث تجد فيه كل الـكيانات Entities وكائناتها ، بالاضافة إلى أي علاقات Associsations بينها . وفي حقيقة الامر ، الكيانات Entities من النوع EntityType ، وهناك ما يعرف بالـ EntityContainer وهناك يتم تعريف فضاء الاسماء الذي يتبعه الـ EDM وكل جزء من الـ Entity مع مقابله في الفئات التي توجد في الملف Model.Designer.vb . وهناك تفرع خاص بالعلاقات Associations يتم فيه تعريف العلاقات ونوعها .

الخريطة Mapping ، وفيها يتم ذكر كل entity والكائنات التابعة لها ، هذا مثال للكيان Orders :

   1: <EntityTypeMapping TypeName="IsTypeOf(NORTHWNDModel.Products)">

   2:        <MappingFragment StoreEntitySet="Products">

   3:          <ScalarProperty Name="CategoryID" ColumnName="CategoryID" />

   4:          <ScalarProperty Name="Discontinued" ColumnName="Discontinued" />

   5:          <ScalarProperty Name="ProductID" ColumnName="ProductID" />

   6:          <ScalarProperty Name="ProductName" ColumnName="ProductName" />

   7:          <ScalarProperty Name="QuantityPerUnit" ColumnName="QuantityPerUnit" />

   8:          <ScalarProperty Name="ReorderLevel" ColumnName="ReorderLevel" />

   9:          <ScalarProperty Name="SupplierID" ColumnName="SupplierID" />

  10:          <ScalarProperty Name="UnitPrice" ColumnName="UnitPrice" />

  11:          <ScalarProperty Name="UnitsInStock" ColumnName="UnitsInStock" />

  12:          <ScalarProperty Name="UnitsOnOrder" ColumnName="UnitsOnOrder" />

  13:        </MappingFragment>

  14:      </EntityTypeMapping>

  15:    </EntitySetMapping>

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

بقي ان اوضح نقطة أخيرة – وهي لمعلوماتك فقط ! – ان هذه الثلاثة اقسام موجوده كلها في ملف واحد وهو ملف Model.edmx الخاص بالـ EDM الذي تعمل عليه ، الا ان الحقيقة انه وفي وقت الترجمة Compiling ، يتم انشاء ثلاثة ملفات ، كل ملف لجزء من الثلاثة ، حيث يوجد ملف للنموذج المفهومي conceptual model يحمل اللاحقة csdl ، وهناك ملف لل Storage Layer يحمل اللاحقة ssdl ، بينما ملف ثالث يحمل اللاحقة msl يمثل جزء الخريطة Mapping .

وهناك ايضا نقطة اخرى ، يحث يحتوي على الملف Model.edmx على منطقة محرمة للتعديل اليدوي من قبل المبرمجين ، تختص بمعلومات حول موقع كل Entity وعرض صندوقها وغيرها من الامور التي يحتاجها الـ Designer في عرض النموذج امامك !

1 – ما هو اطار عمل كتل البيانات Entity Framework ؟

اطار عمل كتل البيانات Entity Framework هو اطار عمل لتمثيل البيانات على شكل كائنات مرتبطة في .Net Framework . يتمتع اطار العمل هذا بكونه جزءا لا يتجزأ من ADO.NET كتقنية من التقنيات المضمنة بها انطلاقا من الاصدار 3.5 SP1 . وبالتالي فهذه التقنية تعتبر اختا لباقي التقنيات كال Dataset,LINQ to SQL وغيرها ، والآن اصبح لدينا مرونة كافيه للقيام في بناء التطبيقات المعتمدة على قواعد البيانات .

تقنية الـ Entity Framework تقوم بتغليف جداول قاعدة البيانات بفئات تتضمن طرق وخصائص تمثل كائنات قاعدة البيانات ، بمعنى لو كان لديك جدول بالإسم Persons وبه حقول كـ PersonID,FirstName,LastName,…etc فإن هذه التقنية ستقوم بتوليد فئة Class بالإسم Persons به حقول بنفس اسم حقول الجدول Persons في قاعدة البيانات ، بإختصار ، تقوم هذه التقنية بإنشاء نموذج Model لكائنات قاعدة البيانات ، موفرة عليك بذلك الكثير من الجهد خصوصا عندما نتكلم عن تطبيقات متعددة الطبقات N-Tier Applications .

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

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

ميزة اخرى في هذه التقنية ، لو أنك قد استخدمت LINQtoSQL لكنت قد اعجبت بالـ O/R Designer وكيف يحول الجداول والـ Stored Procedures الخاصة بقاعدة بيانات من نوع SQL Server مباشرة إلى كائنات برمجية : فئات وطرق Classes,Methods … الخ ويصبح بإمكانك استخدام LINQ مباشرة في الاستعلام عن البيانات وتعديلها واضافتها وحذفها ،، فإنني متأكد من اغرامك بها ولحسن الحظ فيوجد لدينا ايضا ما يدعى بالـ ADO.NET Entity Model ليحاكي الجداول ويقوم بتوليد كل شيء نيابه عنك .

وفي الحقيقة يعتبر اطار عمل كتل البيانات Entity Framework احد التقنيات التي تبنيها مايكروسوفت في سبيل جعل تطوير وبناء انظمة الأعمال business Systems بشكل سهل وميسر . فبدلا من الاعتماد على كائنات DataReaders مباشرة في جلب البيانات وقراءتها والتعقيدات الناتجة عن هذا الامر ، فلماذا لا يكون هذا الكائن هو البنية التحتية فقط ، بمعنى ان نقوم ببناء فئات يستخدمها المبرمجون بطريقة محاكية للجداول ، فالجدول Customers يكون هناك قائمة List(Of Customer) من الفئة Customer وبالتالي سيكون الامر عليك ايها المبرمج امرا اسهل ؟

من ناحية السهولة ، سيكون افضل بكثير من الاعتماد على الـ DataReader مباشرة ، ولكننا نتكلم عن المزيد من السهولة ، فانت ستحتاج إلى التعرف على التعديلات التي طرات على البيانات ، وحفظها ، والتعرف على السجلات المحذوفة ، وغيرها من هذه الاجراءات المعتادة في هكذا نوع من التطبيقات ، وبالتالي فستحتاج إلى كتابة المزيد من الاكواد والابتعاد عن المهمة الاساسية في تطوير وبناء تطبيقك !

من هنا ستنسى شيء اسمه عمود او حقل Column او سجل Row وسيكون عليك الاهتمام فقط بـفئات Classes و خصائص Properties . لذلك كله ، يأتي لنا اطار العمل Entity Framework ليسهل لنا كل هذا الامر ، فهو يسهل علينا تمثيل البيانات على شكل فئات وكائنات برمجية مباشرة ، نتحكم بها من خلال الفاضلة لغة البرمجة المحببة إلى قلوبنا ، ويقدم لنا سهوله شديدة في الاستعلام باستخدام ثلاث طرق مختلفة سنتعرف عليها لاحقا، كما يسهل لنا التعرف على التغييرات Changes Tracking ، ويدعم التسلسل Serialization ، الامر الذي يساعدنا كثيرا في تطوير التطبيقات مهما كبر حجمها ، مع استهلاك اقل وقت في التطوير .

ويستخدم اطار كتل البيانات ، ما يعرف بكيان نموذج البيانات Entity Data Model ، وهو نموذج مطور من ما يعرف بالـ Entity Relationship Modeling, ERM وهو مفهوم ظهر في تطوير قواعد البيانات منذ سبعينيات القرن الماضي .

2- نظرة تاريخية في تقنيات الاتصال :

قبل حوالي احد عشر عاما من الان ، أي في حوالي 1998 م ، كان صدور الاصدار السادس والاخير من لغة فيجوال بيسك 6 متضمنا ثلاث تقنيات اساسية وهي DAO,RDO,ADO – وللأسف فهناك من يستخدم DAO اليوم ! – كانت تقنية ADO هي الاحدث يومها وكانت تضم اداءا افضل وكائنات اذكى وافضل من DAO,RDO ، وكعادة مايكروسوفت ، جاءت تقنيات الدوت نت لتحمل معها مكتبة وحيدة وهي ADO.NET للتعامل مع قواعد البيانات وتضمنت وضعي اتصال : الوضع المتصل Connected Mode والوضع المنفصل Disconnected Mode ، وكان المبرمجون اما خيارين فقط : اما استخدام تقنيات الوضع المتصل المتمثلة في كائنات مثل DataReader و Command ، او استخدام الوضع المنفصل والمتمثل في كائني الـ Dataset والـ TableAdapter . الخيارات محدودة في الاتصال ، والتقنيات قليلة ، فإذا كنت ترغب بعمل استعلام ، فكنت ستحتاج إلى كتابة جمل استعلام SQL تقليدية سواء في باني الاستعلامات Query Builder او في كائن Command وغيرها من الاماكن المعروفة لدى المبرمجين المخضرمين ، ومن المشاكل التي واجهت المبرمجين حينها ، كثرة الاقواس وعبارات الدمج النصي عبارات الاستعلام حيث انها تعتبر متغيرات من النوع String يتم ارسالها إلى مزود قاعدة البيانات لا اكثر ولا اقل ، وكذلك كان لزاما علينا استخدام الباراميترات Parameters لتمرير البيانات بشكل آمن وللهروب من حقن البيانات SQL Injection .

مع ذلك ، كل تلك التقنيات لم تكن ترتقي إلى المستوى المطلوب في التطبيقات التجارية ، فعملية كتابة تطبيقات متعددة الطبقات n-tier applications كانت تحتاج إلى جهود كبيرة ووقت كبير نسبيا – مقارنة باليوم ! – وعمليات الاستعلام في البيانات كانت معقدة شيئا ما ، ظهر بعدها امكانية تقسيم ملفات الـ Dataset لتصبح منفصلة عن بعضها في مشاريع مختلفة الامر الذي رفع مستوى الانتاجية في تطوير التطبيقات متعددة الطبقات ، الا ان صدور النسخه الثالثة من اطار العمل .net framework والنسخة التاسعة من فيجوال بيسك والثالثة من سي شارب ، كانت هي المطور الاساسي لهذه العملية ، فظهور الاستعلامات المتكاملة باللغة Language Integrated Query ادى إلى ثورة حقيقية في مجال الاستعلام عن البيانات من داخل التطبيق ، كما ان المزودات الاخرى كـ LINQtoSQL و LINQtoDataset و LINQtoXML ادى إلى تسهيل التعامل بشكل بالغ مع قواعد البيانات وخصوصا الجزء الاستعلامي منها ، فاصبح بإمكاننا التخلي عن استخدام حلقات For Each التكرارية المملة ، وصار الاستعلام ممتعا ولم تصبح عملية تذكر اسماء الحقول او الاخطاء الاملائية فيها عملية شاقة ابدا بعد اليوم بفضل خاصية IntelliSence في Visual Studio .

تقنيات كـ LINQtoSQL اخذت تشق طريقها بقوة في التطبيقات التجارية والتطبيقات المتوسطة والكبيرة ، واخذت تسهل الامور كثيرا ، خصوصا انها كانت مدعومة بشكل فعال من تقنية LINQ فالاستعلام كما قلنا صار جزءا من اللغة .

وعلى الرغم من كل هذه التغييرات والتطورات التقنية ، الا ان الامر لم يقف عند هذا الحد ، فصدور اطار عمل كتل البيانات Entity Framework لاحقا كجزء من تقنية ADO.NET اثار جدلا واسعا ، فقد امكن العمل بشكل مدمج اكثر ، ولم يصبح تركيز المبرمج الا على اكواده وبرامجه فقط ، فهو لا يرى قاعدة البيانات على الاطلاق ، والاستعلام لم يعد حكرا لا على جمل T-SQL و لا على تقنية LINQ بل ظهرت طرق اخرى ايضا يتناولها هذا الكتاب بالتفصيل ان شاء الله .

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

ولكن هل هذا هو نهاية المطاف ؟

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

3- تعددت التقنيات ، فأيها اختار ؟

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

في الحقيقة ، يوجد حاليا ثلاث تقنيات رئيسية للاتصال بالبيانات والتعامل معها وهي : Dataset,LINQtoSQL,Entity Framework وسنحاول هنا التعرف على زيد وعبيد ، وهل خلفان هو الانسب لمشروعي ام سليمان ؟

سنسهل القضية يا جماعة بمقارنة Dataset و LINQtoSQL اولا ، حسنا العملية تعتمد على السيناريوهات الموجودة لديك :

بالنسبة للـ Dataset :

- الـ Dataset سهل التعريف ، والتسلسل Serialize ، ويسهل فصل الكود فيها عن تصميمه في المشاريع المتعددة الطبقات خصوصا بما يتعلق بالـ TableAdapter المضمنه فيه .

- الـ Dataset يحتوي على متتبع للتغيرات التي تطرأ على البيانات المضمنه فيه، ويدعم التغيير دفعه واحده Batch Editing وكذا بالنسبة للتصفيه والعرض ، كما انه يتعامل بشكل تلقائي مع العلاقات المركبة Complex Relationships .

- يسهل استخدام Dataset عندما نرغب في عمل ربط بيانات DataBinding بشكل متقدم ومعقد .

- يصعب استخدام Dataset عندما نرغب بعمل بعمل عمليات تحقق متقدمة على البيانات .

- يجب تجنب استخدام Dataset عندما تقوم ببناء تطبيق موزع ليس كل العملاء Clients فيه مبنية على net.

بالنسبة لـ LINQtoSQL :

- يقدم لك LINQtoSQL دعم تحكم كامل بالتحقق Validation, السلوك Behavior ، منطق الأعمال BusinessLogic ، كما انها سهله التوريث للفئات الاخرى ، هذا يعني امكانيه عمل طبقات ام وطبقات مشتقة للاعمال بكل سهولة .

- يمكن عمل تسلسل Serialization لفئات LINQtoSQL على شكل مصفوفات Arrays لغير عملاء net.

- بمجرد ايقاف الاتصال بين LINQtoSQL والـ DataContext ، تكون عملية ال Databinding وتعقب التغييرات على البيانات عملية صعبة ويجب عليك القيام بكل ذلك بنفسك !

وعلينا ايضا ملاحظة ان تقنية LINQtoSQL محصورة على SQL Server فقط .

وبالنسبة لـ Entity Framework فتتميز عن LINQtoSQL بالأمور التالية :

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

- بإمكانك التعامل مع والتحكم بـأنواع مختلفة من وراثة البيانات .

- التعامل المباشر مع العلاقات من نوع متعدد لمتعدد Many-to-Many .

- قابلية استخدام مصادر بيانات دون قواعد البيانات كـ Reporting Services وغيرها.

- قابلية التعامل مع انواع قواعد بيانات دون الاكتفاء بـ SQL Server.

ومثل كل تلك الايجابيات فهناك السلبيات ، فلا يوجد شيء او احد كامل هنا ابدا ؛ فهناك بطء نسبي في التعامل مع البيانات مقارنة بـ LinqToSQL ، فضلا عن التعقيد النسبي والذي سيتلاشى مستقبلا كما تخطط مايكروسوفت ، حيث ان من المخطط ان يوقف تطوير LINQtoSQL في الاصدارات القادمة وتكون Entity Framework هي السبيل الأمثل والأساسي والافتراضي – اذا عندك كلمة اخرى مناسبة اضفها مع الكلمات الثلاثة السابقة ! – لبرمجة تطبيقات تعتمد على قواعد البيانات .

خلاصة الامر ، اذا كان تطبيقك من النوع الصغير نسبيا ومعتمدا على SQL Server وحدة دون غيره ، ولا تحتاج إلى أي من مواصفات المرونة Flexibility التي يتمتع بها Entity Framework فيكفيك LINQtoSQL وحده .

4- سمات اطار عمل كيان البيانات Entity Framework :

يتمتع اطار العمل entity Framework بدعم واسع من الادوات والكائنات معا ، فهو يتسم بدعمه بالمميزات التالية :

- نموذج كتل البيانات Entity Data Model

- ادوات تصميم كتل البيانات entity Data Model Design Tools

- ادارة الكائنات بواسطة خدمات الكائنات Objects Services

- تتبع التغييرات Change Tracking

- ادارة العلاقات Relationship Management

- ربط البيانات Data Binding

- عميل الكيان Entity Client

وسنتحدث عنها واحدا واحدا ، فهي تقف في صف واحد بإحترام – هذه مزحة ! :

نموذج كتل البيانات Entity Data Model :

ما هو نموذج كتل البيانات Entity Data Model ؟ هو عبارة عن توصيف لتعريف البيانات المبنية في entity framework . وبدون الـ EDM ، لا توجد علاقات Relationships ولا حتى كتل بيانية entities في مخطط التصميم لديك Design Schema ، اما ما هو مخطط التصميم Design Schema فهو يستخدم لبناء الفئات Classes التي تجدها امامك بدلا من مناداة الجداول مباشرة في قاعدة البيانات . هناك المزيد من الامور لكن افضل التعرف عليها لاحقا في حينها .

وبالرغم من ان اطار العمل مصمم لكي يسمح للمبرمج بالعمل مباشرة بالفئات الموجود في نموذج كتل البيانات Entity Data Model ، الا ان نموذج كتل البيانات EDM لا يتمثل شيء ذا قيمة بدون التعامل مع قاعدة البيانات الحقيقية . وفي الحقيقة ان النموذج الذي تراه في EDM ما هو الا تعليمات XML تصف مكونات الـنموذج Model وخصائصه ( الجداول وحقولها المضمنه ، والطرق وغيرها ) . ملف أخر يقوم بعملية التوجيه Mapping ليربط الكائنات بمقابلاتها في قاعدة البيانات .

وخلال عملية تنفيذ استعلام Query او امر Command ، سيقوم اطار العمل entity Framework بترجمة الاستعلامات المنفذة على كائنات وفئات Objects and Classes إلى استعلامات واوامر مناسبة لقاعدة البيانات.

- ادوات تصميم كتل البيانات entity Data Model Design Tools

وكعادة التقنيات القادمة من مايكروسوفت ، فلكل واحدة منها مائة اداة وأداة تجعل العمل يسيرا ، فلن تقوم بكتابة كود لا يخصك بل سيقوم الجماعة – واقصد الادوات ! – بكتابة الاكواد اللازمة لتوصيف الجداول على شكل entities وغيرها من الكائنات. يقدم لنا Visual Studio مجموعة ادوات مرئية Visual Tools تمكنك من العمل بشكل مرئي مريح وسهل ، فلا اعتقد انك ترغب بكتابة نموذج Model لعشرة جداول بينها علاقات وبكل واحد ما متوسطه 5 او 6 حقول فتخيل ان تكتب كل ذلك بهيئة XML بنفسك ! لا اعتقد ان هناك من يحب ان يقوم بكل ذلك بنفسه !

لسوء الحظ ، فإن المصمم Designer يحتوي على قصور ، يتمثل في كونه لا يدعم كل ميزات وخصائص الـ EDM "كبن" ، ولكن لا تقلق فتلك المميزات هي نادرة الاستخدام ، وستتعرف عليها مستقبلا ان شاء الله ، لكن حينها لا تنفع لومة لائم ، حيث انه سيتوجب عليك فتح الـ Model كملف XML والاضافة والتعديل عليه بنفسك ، لذلك فأحسب حسابك من الآن ، لو أردت التعمق كثيرا فعليك الالمام بـ XML .

من الاشياء الجميلة في الـ Designer هو دعمه للتعرف والتعامل مع الاجراءات المخزنة Stored Procedures ، ولكن ايضا وللأسف – مجددا وكالعادة في كل مرة ! – يوجد حدود وقصور وستحتاج في بعض الاحيان إلى التعديل في ملف الـ XML ايضا !

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

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

- ادارة الكائنات بواسطة خدمات الكائنات Objects Services

هل رأيت كيف يكون الشيخ في مجلس قبيلته متوسطا وظاهرا ومتقدما عليهم جميعا ؟ فتلك هي ادارة الكائنات بواسطة خدمات الكائنات Objects Services ميزة اساسية تحتل مرتبة متقدمة جدا في قلب Entity Framework ، وتعرف كثيرا باسم خدمات الكائنات Objects Services . في السطور الماضية قد يظن البعض انني بالغت قليلا في كلامي ووصفي لمكانة خدمات الكائنات Objects Services ولكن الحقيقة فيما اقول تظهر في الشكل التالي والذي يمثل بنية Entity Framework :

فهو يتقدم الجميع في اطار العمل من حيث الاستخدام ، وهو المسؤول عن توفير كل الوظائف المطلوبة للعمل بالكائنات Objects المبنية على الكيانات الموجودة entities . تقدم خدمات الكائنات فئة تدعى EntityObject ، اهمية هذا الامر هي في ان خدمات الكائنات تدير مجموعة كائنات من ترث الفئة EntityObject ، المزيد من المعلومات في الطريق ! فعملية الادارة ليست بتلك الهينة ، حيث يتم تكوين الكائنات Materializing Objects بناءا على نتائج الاستعلامات ، ويبقي على تتبع للتغيرات التي تطرأ على البيانات – عفوا قصدي الكائنات ! ، كما يقوم بإدارة العلاقات Relationships بين الكائنات ويقوم اخيرا بحفظ التغييرات وارسالها إلى قاعدة البيانات .

وبين عملية الاستعلام عن البيانات وتحديث تلك الموجودة ، تقدم خدمات الكائنات استضافة لمجموعة من القدرات الخاصة بالتعامل مع كائنات الكتل Entity Objects كالنزول إلى ادنى المستويات في اطار العمل نيابة عنك يا سيدي العقيد ، والتي تتمثل في التعامل مع قاعدة الجنود – عفوا قصدي البيانات ! وتتعامل مع نتائج الاستعلامات بنفسها ، كل هذا بدلا عنك . بقي ان نذكر ان خدمات الكائنات تقدم شيئا آخر وهو دعم التسلسل Serialization للكائنات بنسقين ثنائي Binary و XML الامر الذي يجعلك تأخذ بالمثل القائل : حط في كرشك جحه !

افلا نقول لها كلمة : شكرا على كل هذه الجهود ؟

- تتبع التغييرات Change Tracking

مجرد القيام بالاستعلام عن البيانات والتعديل عليها لا يكفي يا حبيبي ، فكيف ستعرف السجلات المضافة والمعدلة والمحذوفة حتى تقوم بتحديث قاعدة البيانات ؟ بدلا من ان تكتب عشرات الاسطر البرمجية في سبيل تعقب تلك التغييرات ، وتظهر لديك مئات الشوائب البرمجية جراء ذلك لكل كائن تقوم باستخدامه ، يقدم لك اطار العمل entity Framework هذه الميزة نيابة عنك فأرح نفسك من كل هذا التعب والتفكير في هذا الموضوع وركز على مشروعك اكرم لك !

فبمجرد انشاء أي كائن كيان entity او الحصول على قيم استعلام ، يتم تتبع كل التغييرات التي تنشأ عليها ، ويتم كذلك تجهيز جمل Insert,Update,Delete خاصة بها في قاعدة البيانات ! فضلا عن هذا كله ، توفر لك دعم محترم للتعامل مع الاجراءات المخزنة التي تقوم بهذه العمليات .

- ادارة العلاقات Relationship Management

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

- ربط البيانات Data Binding

تعد خاصية ربط الادوات بالبيانات Data binding من اهم الخصائص التي تميز اطار العمل .Net Framework و Visual Studio ، وبالطبع فإطار العمل Entity Framework يقدم لك دعما محترما بهذا الخصوص ، فيمكنك استخدام الكتل البيانيه Entities كمصدر بيانات في أي مكون كـ BindingSourc eاو حتى مباشرة في الادوات مثله مثل أي مصدر بيانات اخر .

ولا ننسى ان لمطوري ويب دعم كبير ايضا، فهناك اداة كاملة تدعى EntityDataSource والتي تعد مشابهه للاداتين SqlDataSource و LinqDataSource .

- عميل الكيان Entity Client

يعد عميل الكيان من اهم واجهات برمجة التطبيقات API’s المقدمة في اطار العمل Entity Framework ، فهو من اساسات الـ Entity Framework ، فإن كانت خدمات الكائنات Objects Services كشيخ في قبيلته ، فإن عميل الكيان Entitiy Client يعد والي السلطان ، او عامل الخليفة Entity Framework عليهم كلهم ، فهو المسؤول عن التعامل مع استعلامات المخزن Store Quries ، والأوامر commands من اجل الاتصال بقاعدة البيانات ، تنفيذ الأوامر ، احضار النتائج ، وتغليفها بمظهر الكائنات الموافق للـ EDM .

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

ملخص الأمر ، ان عميل الكيان EntitiyClient يعود بالبيانات بشكل جدولي Tabular وتكون قابلة للقراءة فقط ، بينما تقوم خدمات الكائنات ObjectServices بتغليف البيانات الجدولية بـكائنات Objects مطابقة للـ EDM ويقدم الدعم لعملية تعقب التغييرات التي تطرأ على البيانات وكذلك يقدم امكانية حفظ تلك التغييرات إلى قاعدة البيانات .

5- الاختلاف في الاصدارات :

هناك اختلافات كثيرة قادمة مع الاصدار الثاني – او الرابع ! – لكن على كل حال تلك النسخه لا تزال تجريبية ، وحتى تصدر ، علينا بالموجود ، لذلك افضل لك ان تتقن Entity Framework v1 وعندما يصدر الاصدار التالي مع النسخه 4 من .Net Framework سيكون معرفة التطورات الجديدة امر اسهل من ذي قبل .

6- أمثلة هذا الكتاب :

اود اخبارك بأنني ساستخدم قاعدة بيانات من نوع SQL Server في الاكواد والامثلة الموجودة ، وهي قاعدة البيانات الشهيرة Northwind ، فأحرص على اقتنائها ان لم تكن لديك نسخه منها من الرابط التالي حتى تستطيع التجريب والتطبيق مع الكتاب :

http://www.microsoft.com/Downloads/details.aspx?FamilyID=06616212-0356-46a0-8da2-eebc53a68034&displaylang=en

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

في هذه السلسلة – والتي اسأل الله ان اوفق في نشرها كاملة وضمها في كتيب متكامل بإذنه تعالى ، لتكون المرجع العربي الأول في هذا المجال – سأتناول اطار العمل ADO.NET Entity Framework في اصداره الأول – المضمن مع الاصدار 3.5 SP1 من اطار العمل .Net Framework ، سبق وان قمت بكتابة مقالة مصغرة عن هذه التقنية  ، بيد انني وجدت نفسي متقبلا للإبحار فيها بعمق اكبر ، فقررت ان اكتب سلسلة يستفيد منها كل من يمر عليها .

أترككم مع البداية بعد قليل

ان كنت قد تجولت في مواقع الانترنت ذات العلاقه بمايكروسوفت ، فأكيد ان صداعا في الرأس بدأ يصيبك من رؤية بعض المصطلحات المعتمدة في الاصدرات القادمة ابرزها T4 ، فعشرات المواقع والمجلات والمدونات تتحدث عن T4 واجزم انك رأيت ذلك المصطلح امامك عشرات المرات ! والسؤال الذي يطرح نفسه : ماذا يقصد بـ T4 ؟

T4 هو رمز الى عبارة Text Templating Transformation Toolkit – اي حرف T اربع مرات بدل TTTT !! – وهي تقنية طورتها مايكروسوفت سابقا وقد قامت حاليا برفع متسوى تطويرها الى مرحلة متقدمة جدا ، هذه التقنية تستخدم في توليد الاكواد Code Generation في مختلف منتجات مايكروسوفت وابرزها بطبيعه الحال Visual Studio . 

محرك T4 موجود اصلا في النسخه 2008 وقادم بشكل قوي جدا في 2010 ، ففي الاصدار الحالي لايوجد اي اداة Tool لاستخدامها في اعادة توليد الاكواد الروتينية ، ولكن في الاصدار 2010 فالوضع مختلف حقا من هذه الناحية ، وبالنسبه للاصدار 2008 فيمكنك استخدام ادوات خارجيه تؤدي هذا الغرض منها اداة Visual T4 Editor و Visual T4 Code Generator وبعضها يتوفر في اصدارات مجانية وهي تتميز بإندماجها بشكل كلي مع Visual Studio .

موقع الاداة Visual T4 هو : http://www.visualt4.com/
وموقع الاداة  Visual T4 Code Generator هو :

http://t4-editor.tangible-engineering.com/T4-Editor-Visual-T4-Editing.html

هي اداة برمجية مجانية تقوم شركة مايكروسوفت بإصدارها ، وهي عبارة عن اضافة على Visual Studio 2005 وما فوق ، تهدف الى البحث في اكواد مشاريعك عن نقاط الضعف في البيانات ، والتي يقصد بها الثغرات المعروفة كـ SQL Injection ،XSS Injection و XPath Injection في اكوادك وتعرضها عليك ، هذه قائمة بهذه الثغرات التي تكتشفها:

Cross Site Scripting
SQL Injection
Process Command Injection
File Canonicalization
Exception Information
LDAP Injection
XPATH Injection
Redirection to User Controlled Site

لتحميل هذه الاداة اتبع الرابط التالي ، علما بانها لاتزال تحت التطوير beta .

في يوم حالك السواد ، قمت بتشغيل حاسوبي لأجد مجموعة من المشاكل الغريبة في النظام – ويندوز فيستا – حيث ان متصفح الانترنت Internet Explorer 8 كل بضعه دقائق ينبهني بأن برنامجا حاول تعديل محرك البحث الرئيسي فيه ، وبعض البرامج لا تعمل كما يجب ، توجهت بعدها إلى Visual Studio 2008 وهناك كانت المفاجأه ! لا يوجد أي قالب Tamplate لأي نوع من المشاريع في أي لغة سواء VB او C# وبالتالي لا يمكن انشاء أي مشروع جديد ! ولا حتى اضافه أي عنصر جديد إلى أي مشروع موجود مسبقا ! وفي كل مره تظهر امامي الرسالة التالية :

"No template information found. See the application log in Event Viewer for more details. To open Event Viewer, click Start, click Control Panel, double-click Administrative Tools, and then double-click Event Viewer."

توجهت إلى مستعرض الاحداث Event Viewer فوجدت الرسالة التالية :

the global template information is out of date. Regenerate the templates by running ‘devenv.exe /installvstemplates’ or reinstalling the application.

فور قراءتي للرسالة السابقه ، توجهت إلى محرر الاوامر في ويندوز Command Promote وكتبت ما يلي الاوامر التالية سطرا بسطر :

cd \

cd c:\Program files\Microsoft visual Studio 9.0\common7\IDE

devenv.exe /installvstemplates

بعد تلك السطور انحلت المشكله وعادت المياه إلى مجاريها !

تحياتي

يوجد الكثير من الطرق التي لعمل حقول هوية مميزة Identity fields او ما يعرف بالمفتاح الأساسي Primary Key Filed ، من اشهرها على الاطلاق حقل الـ Autoincrement او الترقيم التلقائي ، والتي يتم فيها توليد رقم تلقائي يزيد عن اخر رقم في العداد الخاص بقيمة تكون في اغلب الاحيان 1 ، تتميز بالخفة والنحافه ، وبالتالي فنحن نتوقع منها الاداء المتميز كونها تحمل قيمة رقمية صغيرة تبدأ من 1 وتصل للآلاف لكنها قد تصل الملايين كلما كبر حجم البرنامج وزاد استخدامه ، وان يكن ، فهي لاتزال ارقام صحيحه integers قد تكون مثلا 99999999999953424 وماذا يعني ذلك ؟ فلا يوجد مشاكل حتى اللحظه فما احلاها !

ولكن ما يعيب هذا الاسلوب هو افتقادها إلى شيء مهم للغاية ، حيث اننا في التطبيقات الكبيرة نوعا ما ، يكون اغلب اعتمادنا على الوضع المنفصل فقد نستخدم Dataset,LINQtoSQL,Entity Framework,…etc ونضيف سجلات Records وقد يتم تعديلها حتى قبل ان ترسل إلى قاعدة البيانات database ، والمشكلة التي ستحدث هنا ، ان كائنات البيانات التي بحوزتنا لن تستطيع اسناد قيمة لحقل المفتاح الأساسي ، حيث ان اصدارها يتم حكرا على قاعدة البيانات فقط ، ولن نستطيع معرفة قيمتها الا بإضافة السجلات إلى قاعدة البيانات وهنا تمكن المشكلة ، ففي التطبيقات التجارية والتطبيقات التي تعتمد على تعدد الطبقات n-tier applications ، يتم اضافة العديد من السجلات وحزمها كلها في حزمة واحده لإرسالها دفعة واحدة إلى قاعدة البيانات ، كما يتم قبل ذلك كله تبادل البيانات بين طبقتي العرض والاعمال ، ناهيك عما يدور خلف الكواليس من عمليات تحقق وسين وجيم !

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

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

قد يقترح احدهم ان نكبر المجال ليكون إلى 20 مليون مثلا وبالتالي نضع انفسنا في امان اكثر ونكون على يقين بأن نسبه تكرار الرقم صغيرة جدا – اقسم 1 على 20 مليون ! – ومن هنا سنحتاج إلى ان يكون حقل المفتاح الاساسي من نوع خاص ، فالنوع الرقمي – اما في .net او في SQL Server – لن يحتويه في اغلب الاحيان فنحن نتحدث من منظور التطبيقات المتوسطة والكبيرة والملايين ، مما قد يدفعنا إلى استخدام حقل نصي في قاعدة البيانات ، ونوع نصي كـ String مثلا في برنامجنا ، لكن هذا النوع يعاب عليه البطء في مثل هذه العمليات ، فهذا الحقل هو المفتاح الاساسي وتعتمد عليه كل العمليات الأخرى مما يعني ان ينخفض مستوى الأداء بشكل كبير جدا جدا ويصبح العمل بطيئا للغاية .

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

طيب والحل ؟

ينفرد SQL Server وكذلك .Net Framework بالنوعين UniquIdentifier و GUID – الاول في الاول والثاني للثاني طبعا ! – فهذا النوع يقوم بتوليد سلسلة نصية طويلة مثل التالية:

dc63e853-804b-4eac-b2e8-270bf1095a63

21c5d16d-d455-49e1-ab4a-7ff39753c4f9

5690757b-544f-49d8-b412-d45433f55202

1c7c7409-a9cf-48cd-a051-6a3a145b90c3

1be8fd38-785c-4628-b5f8-efab7b4d7e40

fc9270f6-fc6b-426e-b7d8-d4b43ec73f6a

4f400213-dcdc-4c91-9ec0-5ce916332be4

74211c09-0bb7-4eea-8944-94581545e3a3

cbb03156-990e-4e15-891e-96788861b8f7

c3b60d21-94a0-4764-866b-582b04fa9701

d0921672-bfff-41c1-9c17-56a76d459d66

3434c358-2371-4352-b16e-c72c4c138525

21afb37d-5981-4c7f-b6f5-0c15a8b7cda5

c1675a25-c365-4015-8151-16d1b2ff7271

ceabf72d-3076-4784-80d8-879a53e21e0c

55760bd0-b7bc-4b14-8b4e-b808e9cb35fe

فنسبه تكرار الرقم ضئيلة للغاية وقد تصل إلى – بحسب حساباتي المتواضعة – 15.78E-51 تخيل 51 خانة عشرية كلها اصفار ! اذا نسبة ضئيلة جدا جدا من التكرار ، فمن هذه الناحية نضمن عدم التكرار ، ومن ناحية نوع البيانات فهو مدعوم في اطار العمل .net وفي قاعدة البيانات SQL Server ايضا ، طيب ماذا عن السرعة ؟

من ناحية السرعة فلا تقلق ، فبما اننا بعدنا عن النوع String فنحن في جهة آمنة من البطء ، خصوصا ان النوع مدعوم في كلا المكانين SQL Server و .Net Framework

وماذا بعد ؟

تتوفر الفئة GUID مباشرة في فضاء الاسماء System ، والميزة التي تتمتع بها انها Shared خصوصا الدالة NewGUID التي تعود بقيمة GUID هكذا : Guid.NewGuid() ، وبالنسبة لإنشاء كائن جديد فذلك عادي جدا :

Dim x As Guid         x = Guid.NewGuid         Console.WriteLine(x)         Console.Read()

ولكن تذكر دائما وجوب استدعاء الدالة NewGUID في حالة رغبتك بإنشاء مميز جديد ، حيث ان الكود التالي :

سيعطينا نفس الناتج تماما مرتين ! والحل يكمن في استدعاء الطريقة المشتركة Guid.NewGuid في كل مرة :

بهذا نكون قد انتهينا من هذا الموضوع .

تحياتي

عندما نكون قد وصلنا إلى هذه المرحلة ، اعتقد انه قد حان الوقت لنكون قد انتهينا من الحاجه في اظهار الكثير من الخطوات ! حيث انني اود عرض الاختلافات فقط !

نقوم بداية بإضافة فئة جديدة من النوع ADO.NET Entity data Model ونسميها مثلا CustomerOrdersModel ثم يظهر امامنا المعالج طالبا منا تحديد كيفية تصميم مصدر البيانات لنطلب منه توليد النموذج بكرم من قاعدة البيانات :

الخطوة التالية ، يطلب منك المعالج تحديد قاعدة البيانات ، قم بتحديد قاعدة البيانات Northwind بنفسك ، ثم انتقل إلى الخطوة التي بعدها وحدد الجدولين Customer,Orders ، وفي خانة الـ Namespace اكتب اسم دلالي مميز سنحتاجه لاحقا وليكن Entities ، انه المعالج بعدها ، لتفتح لك نافذة جديدة وهي نافذة الـ ModelDesigner ، طبعا لا حاجه لك في تعديل أي شيء هناك :

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

الآن توجه إلى النافذة الجديدة Form1 لنقوم بتطوير نافذة Master Details من النوع Full Details ، سنحتاج اولا إلى اضافة الـ DataSource ، وهنا تشترك الطريقتان LINQ-to-SQL و EntityFramework في كون الطريق هي نفسها ، حيث تختار ان يكون مصدر البيانات هو كائن Object ثم تحدد الفئة Customer وتنهي المعالج كالعادة لتجد الفئات قد وجدت على شكل جداول في النافذة Datasources ، قم بعدها بسحب الجدول Customer على شكل Details إلى النافذة from1 ثم الجدول Orders الفرعي التابع له النافذة ايضا ! بعدها انتقل مباشرة إلى نافذة محرر الاكواد حيث اننا سنحتاج إلى كتابة سطيرات برمجي بسيطة :

حيث نقوم اولا بتعريف كائن جديد من النوع Entities وهي الفئة التي تحضن باقي فئات الجداول في الـ Entity Framework ، وفي حدث التحميل نقوم باسناد قيمة إلى الكائن BindingDataSource ولكن هنا لدي ملاحظه مهمه جدا ، وهي ضرورة استخدام الطريقة Inculde وارسال إسم الجدول المرتبط معها ، حيث لو كتبت ent.Customers فإن سجلات الجدول الفرعي Orders لن تظهر وانما ستظهر البيانات الاساسية فقط من الجدول الاب Customers .

وبالنسبة لحفظ التعديلات فكما نلاحظ فإننا لا نحتاج إلا إلى مناداة الطريقة SaveChanges حتى يتولى عنك خلفان وعباس وحمدان القيام بالباقي !

بالنسبة لتطوير نموذج من النوع Lookup List فلا اعتقد انك ترغب في اعادة كل السطور من الدرسين الماضيين وتغيير كلمه واحده فقط في كل مره !

استخدام مزود LINQ-to-SQL لا يختلف كثيرا عن استخدام Dataset الا في بعض الخطوات البسيطة ، كما سنرى الآن :
في البداية ، نقوم بإضافة فئات LINQ-to-SQL وذلك بالتوجه إلى القائمة Project | Add New Project Item ثم اختيار LINQ-to-SQL Classes واعطها الاسم CustomerOrders ، ستظهر امامك نافذة خالية ، سنحتاج ان نقوم بسحب الجداول المطلوبة إلى الجزء الايسر منها من نافذة Server Explorer ، لذلك اذهب إلى نافذة server Explorer وافتح قاعدة البيانات من هناك او اضفها إلى تلك القائمة من خلال الزر Connect to Database . بعد قيامك بهذا ، قم بسحب الجدولين Order,Customers إلى الجزء الايسر من نافذة الـ O/R Designer التي ظهرت قبل قليل ، وستلاحظ انشاء الجدولين هناك على شكل فئات كما بالصورة التالية :

بهذا نكون قد هيئنا فئات LINQ-to-SQL للعمل عليها ، ننتقل الان إلى تصميم النافذة الاولى ، وهي التي تتبع النمط Full Detailed ، سنتوجه بداية إلى النافذة Data Sources ونقوم بإضافة مصدر بيانات جديد لكن انتبه عندما يظهر امامك المعالج اختر الخيار Objects وليس Database كما بالصورة التالية :

وذلك لاننا سنختار ان يكون مصدر البيانات هو الفئات التي ولدها الـ O/R Designer وليس قاعدة البيانات مباشرة .
في المرحلة التالية من المعالج ، اختر الفئة Customer كما بالصورة التالية :

قم بعدها بإنهاء المعالج بالخيار Finish مباشرة ، الآن ستظهر كل حقول الجدول Customer على شكل فئة وخصائص تابعة لها وكذلك فئة فرعية بالإسم Orders وهي تمثل الجدول Orders التابع للجدول Customer بعلاقة من النوع One-to-Many كما بالشكل التالي :

يمكنك الان التعامل مع تلك الفئات مباشرة مثلما عملنا مع Dataset في مرة الماضية ، حيث قم بسحب الفئة customer إلى النافذة على شكل Details ، ثم قم بسحب الجدول Orders التابع لها ايضا إلى النافذة ، هنا سنحتاج إلى خطوة اضافية بسيطة وهي تعبئة الفئة Customer بالبيانات ، حيث ان الفئة الحالية ستكون وكأنها مجرد مخطط لا اكثر نستخدمه في انشاء الادوات والربط بينها بسهولة ، توجه إلى محرر الاكواد واكتب الكود التالي :

الكائن db يمكنك اعتباره ممثل لجداول قاعدة البيانات الموجودة في الـ O/R Designer ويمكنننا من خلاله الوصول إلى الفئات التابعة له ( المقابلة للجداول ) والتحكم بها كما سنرى ،

في الحدث form_load نقوم بإسناد الفئة db.Customers لتكون هي مصد البيانات في الـ CustomersBindingSource ، وفي حدث CustomerBindingNavigatorSaveItem_Click الذي يتم تفجيره بمجرد نقر زر الحفظ نستخدم ذات الكائن ليقوم بإرسال كل التغييرات التي طرأت على البيانات سواءا كانت هذه التغييرات اضافة ، حذف او حتى تعديل بسطر واحد فقط !

بهذا نكون جاهزين لتشغيل التطبيق وتجربة النموذج الجديد !

بناء نموذج من نوع Lookup List :
لا اعتقد انك بحاجه إلى اعادة مجموعة من الاسطر كتبناها في حديثنا عن تطوير نافذة من النوع Lookup List باستخدام dataset ولا اعتقد ايضا انك بحاجه إلى اعادة كتابة سطرين صغيرين كتبناهما قبل حوالي 10 اسطر ! لذلك سأكتفي هنا بعرض المثال مباشرة .

1- استخدام الـ Dataset :

سافترض بانك تعرف كيفية اضافة مصادر البيانات فلن اضع صورا هنا ، سنقوم اولا باضافة مصدر البيانات من خلال القائمة Data | Add New Data Source ومن هناك نحدد قاعدة البيانات Northwind ونختار الجدولين Customers و Orders فقط ثم ننهي المعالج .

عمل الـ Full Details Form :

نتوجه بعدها إلى النافذة Form1 لنقوم بالعمل عليها ، وارجو منكم التركيز جيدا هنا .

1- توجه إلى القائمة Data | Show Data Sources او اضغط على shift+alt+d ستظهر لك النافذة بالشكل التالي :

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

من اهم الامور هنا هو وجود الجداول المتربطة بشكل متداخل ، فلاحظ من الصورة السابقة وجود الجدول Orders مرتين ، الاولى بشكل تابع للجدول Customers والثانية بشكل مستقل عنه ، تبعية الجدول Orders للجدول Customers من خلال العلاقة التي بينهما ( One-to-Many ) يعني امكانيه عرض السجلات التابعة لكل سجل بشكل سهل جدا . هذا ما سنشاهده بعد قليل فلا تخف.

قم بالضغط على الجدول Customers وستنبثق لك قائمة صغيرة لتحدد طريقة العرض اختر منها details كما بالشكل التالي :

الآن الخطوة الاكثر اثارة واهمية ، وهي سحب الجدول Custometrs إلى النافذة form1 وتركه هناك ، سيقوم Visual Studio بتوليد كل الادوات والاكواد المطلوبة لعرض البيانات وربطها والتنقل بينها … الخ كما بالصورة التالية :

لو قمت بتشغيل التطبيق الآن ، ستلاحظ ظهور البيانات بشكل جميل ومرتب مع امكانية التنقل بين السجلات بسهولة ، فضلا عن امكانيه الاضافة والحذف والحفظ ايضا .

لم ينته عملنا بعد ، فنحن نريد اضافة الجدول Orders التابع للجدول Customers ، وارجو ان لا تخلط هنا مع الجدول Orders المستقل لأنه لن يفيدنا ، لذلك قم بسحل الجدول Orders الفرعي إلى النافذة ايضا وشاهد النتيجة :

لو قمت الان بتجربة البرنامج ، ستجده يعمل بالشكل المطلوب تماما ، فبمجرد عرض سجل من الجدول customers في الاعلى ، يتم عرض السجلات المرتبطة به من الجدول Orders مباشرة في الاداة DataGrid في الاسفل مباشرة .

اذا كنت تستخدم الاصدار 2008 فقد اتممت كل الامور الضرورية المطلوبة ، اما في الاصدار 2005 و .net framework 2.0 فأنت بحاجه إلى اضافة بعض السطور في كود الحفظ من الـ BindingNavigator فهنا يتم تحديث كل جدول على حده للأسف ، لذلك ستجد كودا مثل :

وهذا يعني تحديث بيانات الجدول Customers فقط دون الجدول Orders المرتبط به ، لذلك اضف بعض السطور ليصبح الكود النهائي بالصورة التالية :

بينما في الاصدارات الاحدث من اطار العمل وكذلك فيجوال ستوديو ، يتم توليد الفئة TableAdapterManager يقوم بإدارة كل الكائنات من النوع tableAdapter والعمل عليها دفعة واحدة ! فكود الحفظ سيكون مولدا تلقائيا بالشكل التالي :

حركة اخيرة احبها في هذا النوع من النوافذ وهو استخدام عجلة الفأرة MouseWheel للانتقال بين السجلات حيث نضيف الكود التالي في حدث الـ MouseWheel التابع للنافذة Form مباشرة :

بهذا نكون قد انهينا نافذة من النوع Detail view .

بناء نافذة من النوع Lookup :

هنا قم بإضافة نافذة جديدة فارغة إلى مشروعك ، وتوجه إلى نافذة الـ Datasources وحدد الجدول Customers وقم بتحديد النوع None لكل الحقول ، فلا نريد عرض سوى حقل واحد وهو ContactTitle حيث نريد عرض اسم الـ contact فقط ، وبالنسبة لهذا الحقل ، اختر الاداة ListBox :

الآن قم بسحب الجدول customers عن بكرة أبيه إلى النافذة Form ، ستلاحظ توليد الـ BindingNavigator وكل المكونات الاخرى ، وتوليد اداة ListBox فارغة ، قم بالنقر في الزر العلوي منها كما بالشكل التالي :

قم بتفعيل الخيار Use data bound items ، وستتغير تلك النافذة الصغيرة لتظهر عدة خيارات اضافية بها ، يهمنا منها الخاصية Datasource ، اختر منها CustomerBindingSource كما بالشكل التالي :

وبالنسبة للخاصية DisplayMember اختر الحقل ContactName التابع للـ customerBindingSource دون غيره :

الآن قم بتعيين قيمة الخاصية dock التابعة للاداة Listbox لتكون Left حيث اننا نود عرضها بالجانب الايسر في هذه الحالة – وفي حالة كون التطبيق باللغة العربية اجعله Right لاتنسى رجاءا ! – بعدها توجه مرة اخرى إلى النافذة DataSources وقم بسحب الجدول Orders الفرعي – التابع لـ Customers – إلى النافذة مباشرة وقم بضبط الخاصية Dock لها لتكون fill ، شغل بعدها البرنامج مباشرة وشاهد النتيجة بنفسك :

حيث يظهر لك في الاداة ListBox الحقل ContactName وبمجرد اختيار احد القيم من هناك يتم عرض البيانات الفرعية التابعة له من الجهة اليمنى في الاداة DataGridView .

تبقى فكرة الحفظ نفسها التي طبقناها في المرة السابقة مع النوع الاخر من النوافذ وذلك في حالة كونك تستخدم VS2005,.net 2.0 .

بهذا نكون انتهينا من عرض طريقة استخدام الـ Dataset في انشاء نوافذ تعرض البيانات بطريقة Master Details .