سلام
پیش از این گفتیم که ORM به نگاشت اشیای دیتابیس به اشیای درون برنامه اشاره دارد، پس در یک ORM ما نیاز به تعریف بخشی معادل جداول و فیلدهای دیتابیس درون برنامه مان داریم تا کتابخانه و موتور ORM بتواند مقادیر دیتابیس را درون اشیا ما نگاشت یا منتقل کند و تغییرات ما در آن اشیا را بطور معکوس در دیتابیس اعمال کند.
برای این امر در EF نیاز به تعریف یک کلاس Entity ساده (POCO) با نام فیلدها و مشابه Type آن ها در دیتابیس داریم.
این کلاس برای جدول Person که در پست قبل فیلدهایش را معرفی کردیم، بدین شکل خواهد بود:
[Table( "Person" )]
public class Person
{
[Key, DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public int PersonID { get; set; }
public string Title { get; set; }
public string FirstName { get; set; }
public string MiddleName { get; set; }
public string LastName { get; set; }
public DateTime ModifiedDate { get; set; }
}
- ویژگی Table در کد فوق نام واقعی دیتابیس را مشخص میکند.
- ویژگی Key هم مشخص کننده PrimaryKey واقعی جدول است، این ویژگی تنها مورد اجباری است، یعنی وجود آن دریکی از فیلدهای کلاس Entity شما اجباری است.
- ویژگی DatabaseGenerated هم با مقدار Identity مشخص میکند که این فیلد AutoNumber است، یعنی به EF اعلان میکند که در زمان Insert شاید مقدار صفر داشته باشد ولی پس از Insert خودکار در دیتابیس عددی خواهد گرفت و EF باید این تغییرات را لحاظ کند.
- ویژگی های بسیار دیگری وجود دارد که نحوه نگاشت صحیح را کنترل میکنند که در این مقاله از بیان آنها صرف نظر میکنیم.
دقت کنید که نام ونوع Property های این کلاس با نام و نوع ستون های جدول دیتابیس مان منطبق است.
class Person که در کد فوق تعریف کردیم در واقع معادل نگاشت وانتقال یک سطر جدول دیتابیس است وهر Property این کلاس هم معادل یک ستون در دیتابیس است.
پس تا اینجا وبا تعریف یک کلاس ساده (POCO) نگاشت ستون ها ویک سطر دیتابیس را به سادگی انجام دادیم، میماند نگاشت خود یک چیزی برای معادل جدول بودن و یک چیزی برای معادل دیتابیس بودن.
دقت کنید که class Person معادل یک سطر است درحالیکه جدول (یک سطح بالاتر) شامل تعداد بیشماری سطر است.
برای معادل سازی دیتابیس وجداول تعریف یک کلاس دیگر هم لازم است:
public class DBUnit
: DbContext
{
public DBUnit()
: base( "MyConnection" )
{
}
public DbSet<Person> Persons { get; set; }
}
و کار نگاشت تمام است! بسیار ساده ، کارآمد و لذت بخش است.
اجازه دهید ببینیم چه نوشته ایم؟
DbSet یک مجموعه سفارشی در EF است که معادل یک جدول میشود.
همانطورکه گفتیم جدول مجموعه سطرها است و DbSet هم مجموعه ای از نمونه های class Person است.
پس ما نیاز داریم برای هر جدول یک DbSet در این کلاس اضافه کنیم، دقت کنید که نام Persons در اینجا مهم نیست و میتوانست هر نام دیگری که ما با آن راحت بودیم باشد، EF از این نام استفاده نمیکند.
کلاس وراثت گرفته شده از DbContext هم در اینجا نقشی معادل نگاشت کل دیتابیس را برای ما ایفا میکند.
اگر دقت کنید یک دیتابیس در بانک اطلاعاتی شامل چندین جدول است و در اینجا هم کلاس DbContext ما میتواند شامل چندین DbSet باشد.
==============
نکته دیگری که باقی می ماند، محتوا رشته ConnectionString است که ماهیت آن معرف دوستان است.
(ConnectionString یک رشته تنظیمی است که حداقل شامل چهار مقدار اصلی است: آدرس سرور دیتابیس، نام بانک اطلاعاتی و نام کاربری و گذرواژه اتصال به دیتابیس است) کلمه "MyConnection" معرف کلید دسترسی به ConnectionString در فایل app.config (پروژه exe) یا فایل web.config (پروژه asp.net) است.
این مورد چیز جدیدی نیست و روشی استاندارد قبل از EF است که در EF مدون تر شده است.
فرمت فایل config.* باید چیزی شبیه این باشد:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="MyConnection" providerName="System.Data.SqlClient" connectionString="Data Source=IP ;Initial Catalog=DATABASE ;User ID=USERNAME ;Password=PASSWORD " />
</connectionStrings>
...
(فقط جهت اطلاع، این مورد ConnectionString کمی در ASP.Net Core 1 و EF7 تفاوت کرده که البته هنوز در محدوده آزمایشی است) ==============
تا این مرحله ما موفق شدیم معادل ها یا نگاشت هایی برای مفاهیم ستون، سطر، جدول وکل دیتابیس مان در کدهایمان ایجاد کنیم.
از اینجا به بعد ما با این معادل ها کار میکنیم، آنها را میخوانیم ، تغییر میدهیم و اضافه میکنیم و... و EF بین ما ودیتابیس قرار میگیرد و خودکار دستورات SQL لازم جهت چهار عمل اصلی CRUD را ساخته (INSER, SELECT, UPDATE, DELETE) و اجرا میکند.
اجازه دهید مجالی پیش آید در پست بعدی به طریقه کار عملی خواهیم پرداخت.
شب خوش.