آشنایی با کاربرد Data Annotation-رویکرد Code First Migration

کلیه حقوق مادی و معنوی این مقاله متعلق به آموزشگاه تحلیل داده می باشد و هر گونه استفاده غیر قانونی از آن پیگرد قانونی دارد .

 Data Annotations ها و مهاجرت(Migration) از رویکرد Code First در Entity Framework Data Annotations

مقدمه

Data Annotationها کاربرد های گسترده ای در Entity Framework دارند و با به کار بردن آنها در کلاس model، می توانیم اعتبار سنجی ها را اجرا کنیم. به این ترتیب کلاس هایی را در اختیار ما قرار می دهد، که یکسری metadata برای Entity Framework DbSet  فراهم میکند.

این مقاله در ادامه مقاله قبلی، با عنوان "رویکرد Code First در Entity Framework  با استفاده از ASP.NET MVC" می باشد.

فولدر app_data، و سپس فایل پایگاه داده (mdf.) را باز کنید تا به جدول Artists برسید. اگر به نوع ستون ArtistName دقت کنید، می بینید که نوع آن nvarchar(max) است و Allow Nulls تیک خورده است.

قصد نداریم که حداکثر سایز را برای نوع داده در نظر بگیریم، اما این قراردادی است که Entity Framework استفاده می کند. قبلاً گفتیم که ArtistName یک رشته است، اما نگفتیم به چه اندازه ای باشد. بنابراین منطقی است که Entity Framework حداکثر سایز را برای ArtistName در نظر بگیرد. همانطور که در بخش مقدمه گفته شد، data annotationها، یکسری metadata برای Entity Framework dbSet فراهم میکند.

برای استفاده از DataAnnotationها، باید یک ارجاع از System.ComponentModel.DataAnnotations داشته باشیم.

زمانی که قرار است با اعداد کار کنیم، Entity Framework ،نوع های داده در SQL را به نوع های داده در .NET نگاشت می کند. برای مثال long معدل bigint است. یکی از حرفه ای ترین نوع داده، datetime است. Datetime در واقع یک نوع با مقدار است و نمی تواند null شود و حتماً باید یک مقدار در خودش نگهدارد.

فرض کنیم productOrderها را داریم. در productOrder هم orderdate و هم shipDate را داریم. Order date تاریخی است که سفارش ثبت شده است و همیشه برای آن مقدار خواهیم داشت. اما ship date چطور؟ احتمالاً تا زمانی که محصول به مقصد ارسال نشود، مقدارش null خواهد بود. چه کنیم؟! در یک چنین مواقعی از nullable استفاده می کنیم. البته از علامت ? هم می توان به جای آن استفاده کرد. برای مثال:

Nullable<DateTime> shipDate

و یا:

DateTime? shipDate

هر دو قابل قبول هستند. بیایید به صورت عملی جلو برویم:

فایل Artist.Cs را فولدر model در کد مقاله قبلی باز کنید. مانند تصویر زیر، دو ویژگی به ArtistName اضافه کنید:

Required(): مشخص می کند که این فیلد از پایگاه داده یک ستون الزامی است.

String Length(): اولین پارامتر حداکثر طول و پارامتر دوم حداقل طول دلخواه را تعیین میکند.

Artist.Cs مشابه تصویر زیر است.

بر اساس قرارداد Entity Framework، ویژگی ای را به عنوان کلید اصلی در نظر می گیریم که یا پسوند ID داشته باشدو یا فقط ID باشد. اگر ویژگی مورد نظر نامی غیر از این داشت، میتوانیم با استفاده از ویژگی [key] آن را به عنوان کلید اصلی تعیین کنیم.  Entity Framework نام کلاس را همنام با نام جدول در نظر می گیرد. اگر بخواهیم این رفتار را با تعیین نام جدید، تغییر دهیم می توانیم از ویژگی [Table("newName")] استفاده کنیم:

بسیار خوب! حالا آن را build کرده و برنامه را اجرا کنید. به آدرس Artist/Index در مرورگر بروید.

با خطای Invalid Operation Exception مواجه خواهید شد. این پیغام اعلام میکند که  DataContext از زمانی که پایگاه داده ایجاد شده، تغییر کرده است و باید مهاجرت کد (code migrations) را برای بروزرسانی پایگاه داده در نظر بگیریم. این پیغام مانند تصویر زیر خواهد بود:

بروزرسانی پایگاه داده در صورت تغییر model

فرآیند زیر را برای شروع Code First Migration دنبال کنید:

1.      ابتدا package manager console را باز کنید.( View -> Other Windows -> Package Manager Console)

2.      مانند تصویر زیر، دستور Enable-Migrations را تایپ کنید:

به ما میگوید که بیش از یک نوع context در اسمبلی CodeFirstDemo یافت شده است. درست است! یک همان CodeFirstDemoContext ای است که ما ساختیم و دیگری UserContext پیش فرضی است که برای مدیریت هویت (identity management) به کار می رود. علاوه بر این به ما پیشنهاد می کند که چطور نسخه ای را که ما ایجاد کرده ایم را بروزرسانی کند. از خط دستور زیر برای فعالسازی مهاجرت استفاده می کنیم:

Enable-Migrations –ContextTypeName CodeFirstDemo.Models.CodeFirstDataContext – EnableAutomaticMigrations

3.      حالا باید پایگاه داده را بروزرسانی کنیم تا تغییرات بر روی آن اجرا شوند.

اگر بخواهیم مشخص کنیم که چه تغییراتی باید بروزرسانی شوند، می توانید با نوشتن کد بروزرسانی پایگاه داده در package manager console این کار را انجام دهیم. زمانی که آن را اجرا کنیم با یک پیغام خطا مواجه خواهیم شد: "مهاجرت خودکار به دلیل احتمال از دست دادن داده ها، فعال نشد." این خطا به دلیل محدود کردن ستون ArtistName، از سایز حداکثر به 100 است. Entity Framework فکر میکند ممکن است سایز برخی artist nameها بیشتر از سایز تعیین شده باشد و به همین دلیل به ما هشدار می دهد که ممکن است داده هایمان را از دست بدهیم.

اما ما می دانیم که هیچ داده ای نداریم که از دست برود. بنابراین با استفاده از دستور " updatedatabase –script –force" تغییرات را تحمیل می کنیم.

به محض اجرا فایل script آن باز می شود.

به دو تغییر دقت کنید:

جدول Artist با استفاده از کوئری Alter بروزرسانی شده است و جدول دیگری به نام MigrationHistory ایجاد شده است و رد تغییرات را در آن ذخیره می کند. Entity Framework با استفاده از این جدول تعیین میکند که آیا datacontext و database، هنگام اجرای برنامه یکسان هستند یا خیر.

حالا باید آن را اجرا کنیم. هم می توانیم کوئری ها را با استفاده از SQL Server Management Studio و یا با استفاده از Package Manager Console اجرا کنیم.

بسیار عالی! حالا فایل .mdf را از Solution Explorer باز کنید و تغییرات را مشاهده کنید.

در ستون ArtistName، گزینه Allow Nulls تیک نخورده و همانطور که انتظار می رود، حداکثر طول مجاز 100 است.