الرئيسية > ado.net entity framework > الباب الثاني : استكشاف نموذج كيانات البيانات Entity Data Model

الباب الثاني : استكشاف نموذج كيانات البيانات Entity Data Model

ديسمبر 14, 2009 أضف تعليقاً Go to comments

 

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. ديسمبر 25, 2009 الساعة 11:55 ص

    بارك الله فيك ,, هل هذا الموضوع تقريباً مرتبط بال TABLE mapping ؟؟

  1. No trackbacks yet.

أضف تعليقاً

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

WordPress.com Logo

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   / تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   / تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   / تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   / تغيير )

Connecting to %s

%d مدونون معجبون بهذه: