این مقاله، 11 ویژگی مهم 7 Entity Framework را بررسی می کند.
کم حجم و قابل گسترش
به جای استفاده از API های موجود برای Entity Framework 6، تیم توسعه آن تصمیم به ساخت این تکنولوژی از صفر گرفت. شما می توانید فقط افزونه هایی را که برای پروژه شما مفید می باشد، استفاده نمایید. الگو و مفهوم استفاده از Entity Framework به همان صورت باقی مانده است. شما می توانید به همان شکل قبل از DbContext/DbSet استفاده نمایید. مزیت قابل گسترش آن این است که می توانید آن را جایگزین کرده و توسعه دهید.
پلت فرم های جدید
Entity Framework در حال حاضر ORM بسیار محبوبی است که شامل اپلیکیشن هایی است که با تکنولوژی های WPF، WinForm و ASP.Net ایجاد شده اند. مایکروسافت با نگاهی به آینده تصمیم به پشتیبانی از پلت فرم های دیگری که در توسعه .Net رایج می باشد، گرفت. این پلت فرم ها شامل Windows Store، Windows Phone و Cloud Optimized .Net می باشد.
Data Storeهای جدید
Entity Framework به طور کاملا واضحی با data store های رابطه ای گره خورده است. حال در نسخه جدید EF پشتیبانی بسیار قابل قبولی از data storeهای غیر رابطه ای را فراهم آورده است. رابطه ای و غیر رابطه ای مانند ذخیره سازی جدول های Azure.
تولید کوئری بهینه
براساس درخواست های بسیار مردم در EF uservoice برای “بهبود تولید SQL”، Diego Vega (مدیر مهندسی، Entity Framework) پاسخ مثبتی به مردم برای شروع کار روی این ویژگی را داد. در نسخه بعدی یا انتشار نهایی، آن ها این ویژگی را اضافه می کنند. EF 7 بسیار ساده تر از EF 6 کوئری های SQL را تولید می نماید.
فقط روش code first
بالاخره تیم مایکروسافت در Entity Framework 7، EDMX را منسوخ کردند. در این باره می توانید مقاله EF7 – فقط code first یعنی چه نوشته Rowan Miller را بخوانید. اگر شما هنوز edmx را دوست دارید، می توانید مقاله – با رسیدن EF7، EDMX چه می شود؟-
آپدیت Batch
دیگر نیازی به به روزرسانی EF Batch برای انجام عملیات batch وجود ندارد چرا که EF7 به طور از پیش تعریف شده آن را پشتیبانی می کند. EF7 دیگر برای هر یک از دستورات insert/update/delete یک دستور جداگانه ارسال نمی کند. EF7 چندین دستور را در یک batch به یکباره به دیتابیس ارسال می کند.
محدودیت های یکتایی
EF7 این امکان را به شما می دهد که کلید های یکتای دیگری علاوه بر کلید اصلی در موجودیت های خود مشخص نمایید. به این ترتیب می توانید این کلیدهای جایگزین را به عنوان کلید هدف در رابطه های کلید خارجی استفاده نمایید. محدودیت یکتایی برای هر یک از کلیدهای جایگزین در model معرفی می شود.
ظاهر آن به چه شکل است
در مجموع، ایندکس و محدودیتی که برای کلید جایگزین معرفی شده اند به این صورت می باشد: AK_<type name>_<property name> می باشد. برای کلیدهای جایگزین ترکیبی، <property name> با یک underline و لیستی از property name ها می آید.
چگونه از آن استفاده کنیم
باید از یک fluent API استفاده کنید چرا که محدودیت یکتایی با استفاده از Data annotations قابل تنظیم نمی باشد.
In-memory provider (برای تست)
class MyContext: DbContext
{
public DbSet < Employee > Employees
{
get;
set;
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity < Employee > ()
.HasAlternateKey(e => e.EmployeeCode)
.HasName("AlteranteKey_EmployeeCode");
}
}
class Employee
{
[Key]
public int EmployeeId
{
get;
set;
}
public string Name
{
get;
set;
}
public string EmployeeCode
{
get;
set;
}
public DateTime DateOfBirth
{
get;
set;
}
}
برای تست عملیات DB در Entity Framework، ما باید DbContext را مدل سازی نماییم که این کار آسانی نیست. ذخیره In-memory برای تست DbContext بدون مدل سازی آن مفید می باشد. ذخیره In-memory کاملا شبیه data store واقعی رفتار می کند. می توانید همان عملیات را به عنوان In-memory provider اجرا نمایید.
Logging
تمامی تعاملات با دیتابیس با استفاده از ویژگی از پیش تعریف شده logging در EF7 نظارت می شود. ویژگی logging توسط Microsoft.Framework.Logging ارائه شده و مایکروسافت ILoginFactory را پیاده سازی کرده که تمامی پلت فرم های .Net را پشتیبانی می کند(البته امیدواریم که همین طور باشد).
Shadow Properties
ویژگی هایی هستند که در کلاس entity وجود ندارند، اما به عنوان بخشی از آن رفتار می کنند. مقدار و وضعیت این ویژگی ها به طور کامل در Change Tracker نگه داری می شوند. این property ها می توانند در تمام عملیات های دیتابیس شرکت کنند، اما نباید از طریق کلاس entity در معرض دید مابقی اپلیکیشن قرار بگیرند. در حال حاضر، شما تنها از طریق fluent API می توانید به shadow properties دسترسی پیدا کنید.
