#EfCore_Best_Practice

Solve the problem 1+N in Ef Core

حل مشکل 1+N در Ef Core

این مشکل در correlated subqueries رخ میدهد.
به عنوان مثال در کوئری زیر
var query = context.Customers.Select(
c =>
c.Orders.Where(o => o.Amount > 100).Select(o => o.Amount)

);
ابتدا کوئری برای دریافت لیستی از Customers به دیتابیس ارسال میشود .
و به ازای هر Customer کوئری زیر

c.Orders.Where(o => o.Amount > 100).Select(o => o.Amount)
ترجمه و به سمت دیتابیس ارسال میشود.

این مشکل با نام مشکل 1+N شناحته میشود.

از Ef Core 2.1 به بعد Optimization ای برای این قبیل کوئری ها انجام شده است که از وقوع این مشکل جلوگیری میکند و سبب میشود که کوئری بالا حداکثر به دو اس کیو ال کوئری ترجمه شود.
کوئری اول سلکتی برای Customer ها و کوئری دوم اعمال فیلتری بر روی Order ها

برای انجام اینکار هم نیاز به انجام یک تغییر کوچک در کوئری خود دارید.

var query = context.Customers.Select(
c => c.Orders.Where(o => o.Amount > 100).Select(o => o.Amount).ToList());

کافیست به SubQuery خود متد ToList() را اضافه کنید .


اطلاعات بیشتر در مورد این مسئله را می توانید در Issue 4007 مربوط به ریپازیتوری Ef Core مشاهده و دنبال کنید.
@fullStackDevs

#EfCore_Best_Practice
#Explicit_compiled_queries

در این پست به معرفی یک ویژگی باحال که از EF 5 به بعد و در LINQ to SQL نیز وجود داشت و در EF Core از نسخه 2.0 به آن افزوده شد می پردازیم.

در ابتدا Ef Core در ورژن 1.0 ویژگی query caching را معرفی کرد . این ویژگی علاوه بر پرفورمنسی که دارد اما دارای سربارهایی نیز است.
هر کوئری برای کش شدن و نگه داری آن در حافظه و سپس استفاده مجدد از آن به یک کلید هش شده نیاز دارد که تولید این کلید هش شده از روی Query Expression سرباری دارد.

اما از نسخه Ef Core2.0 ویژه گی query compilation به آن اضافه شده.
در این حالت کوئری یک بار کامپایل شده و در حافظه نگه داری میشود و می توانید به هر دفعات که خواستید از ان استفاده کنید.

Example:

private static Func<AdventureWorksContextDI, int, Orders> _getOrderById =
EF.CompileQuery((AdventureWorksContextDI context, int id) =>
context.WorkOrders.Select(
x => new Orders
{
Id = x.WorkOrderId,
ProductName = x.Product.Name,
Quantity = x.OrderQty,
Date = x.DueDate
}).FirstOrDefault(x => x.Id == id));

usage :

public Orders GetOrderByIdCompiled(int id)
{
return _getOrderById(_context, id);
}

چه زمانی از این ویژگی استفاده کنیم ؟
1-کوئری تان قرار است خیلی بیشتر از یک بار متوالی اجرا شود.
2-کوئری شما به قدر کافی پیچیده است و هزینه هربار کامپایل ان زیاد است.


* نکته اول اگر دلیگیت کامپایل کوئری مورد نظر خود را به صورت استاتیک تعریف کنید می توانید در تمام نمونه های ApplicationDbContext خود از آن استفاده کنید.
*نکته دوم نسخه جاری Ef Core هنوز نوع خروجی

List<T>

را برای یک کامپل کوئری پشتیبانی نمیکند.

@fullStackDevs

#Value_Conversions
#EFCore

🧩 Value Conversions

این ویژگی در EF Core 2.1 اضافه شد.
ویژگی Value Conversion امکان تبدیل مقادیر پراپرتی ها به تایپ های مشخص در هنگام خواندن یا نوشتن در دیتابیس را میدهد.
این تبدیل میتواند از یک نوع به همان نوع یا از یک نوع به نوع دیگر باشد مانند تبدیل مقادیر enum به string و برعکس.
برای مثال برای ذخیره مقادیر enum بصورت string به شکل زیر میتوانیم عمل کنیم :

public class Rider
{
    public int Id { get; set; }
    public EquineBeast Mount { get; set; }
}

public enum EquineBeast
{
    Donkey,
    Mule,
    Horse,
    Unicorn
}

و سپس برای اینکه مقادیر این enum در دیتابیس به صورت string ذخیره شود ، به این صورت "Donkey", "Mule" بایستی Value Conversion ای بدین شکل تعریف کنیم .

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<Rider>()
        .Property(e => e.Mount)
        .HasConversion(
            v => v.ToString(),
            v => (EquineBeast)Enum.Parse(typeof(EquineBeast), v));
}

یا به عنوان مثال حتما تا کنون برای شما پیش آمده که در درون Entity Class خود برای یک پراپرتی از Complex type استفاده کرده باشد.
مثلا برای نگه داری مقدار پول به جای استفاده از type های decimal یا int ، از یک custom type که خود انرا تعریف کرده اید استفاده کرده باشید.

public class MyEntity
{
...
public Money salary { get; set; }

//Money is a class, actually it's my custom type

}
برای ذخیره چنین type هایی در دیتابیس و واکشی انها در قالب custom type مان، میتوانیم از ویژگی Value conversion کمک بگریم.
برای انجام اینکار بایستی برای پراپرتی salary (در مثال بالا) یک ValueConverter در متد OnModelCreating در Context بسازیم اینکار به دو صورت قابل انجام است .
روش اول

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
    modelBuilder.Entity<MyEntity>()
        .Property(b => b.Salary )
        .HasConversion(
            v => JsonConvert.SerializeObject(v),
            v => JsonConvert.DeserializeObject<Money>(v));
}

و روش دوم

var converter = new ValueConverter<Money, string>(
    v => JsonConvert.SerializeObject(v),
    v => JsonConvert.DeserializeObject<Money>(v));

modelBuilder

.Entity<MyEntity>()
.Property(e => e.Salary)
.HasConversion(converter);

✔️ توجه داشته باشد که برای ذخیره شی Money در دیتابیس و واکشی آن از دیتابیس در قالب یک Money روال سریالایز و دیسریالایز کردن آن به Json نیازمند است.

روش دوم برای مواردی که دو پراپرتی از یک value converter استفاده میکنند مناسب است.
*نکته مقادیر null به value converter پاس داده نمیشوند.
خود Ef Core نیز کلاس های value converter از پیش تعریف شده ای دارد که در فضای نام
Microsoft.EntityFrameworkCore.Storage.ValueConversion
وجود دارند .که لیستی ار آنها را در این لینک میتوانید ببینید.به همین خاطر EF Core با دارا بودن لیستی از این value converter بسیاری از تبدیلات نوع ها به نوع های دیگر در هنگام ذخیره مقادیر در دیتابیس را به صورت اتوماتیک انجام میدهد در واقع این امر زمانی مشخص میشود که DataBase Provider خود را مشخص و کانفیگ میکنید.
مثلا مثال enum بالا را میتوانید با value converter های خود ef core انجام دهید.

var converter = new EnumToStringConverter<EquineBeast>();

modelBuilder
    .Entity<Rider>()
    .Property(e => e.Mount)
    .HasConversion(converter);

🎯 و نکته اخر اینکه
با مشخص کردن نوع یک پراپرتی به صورت صریح به کمک اتریبیوت

 [Column(TypeName = "TypeName")]

می توان همین کار را انجام داد و Ef Core متوجه میشود که باید مقدار این پراپرتی رو در هنگام ذخیره در دیتابیس به نوع مورد نظر تبدیل کند.
این ویژگی هنوز محدودیت هایی دارد برای مثال :
-مقادیر null نمیتوانند تبدیل شوند
-امکان اعمال یک value converter به صورت کلی برای دسته ای از پراپرتی ها نیست و باید به صورت تک به تک اعمال شوند.
-استفاده از value conversions ممکن است توانایی EF Core را برای ترجمه عبارات به SQL تحت تأثیر قرار دهد.


@fullStackDevs

#High_Performance
#EfCore_Best_Practice
#DbContext_pooling

🔸 در این پست به معرفی یک روش جدید Register کردن DbContext به Di Container در متد ConfigureServices در کلاس Startup می پردازیم.
ابتدایی ترین و ساده ترین روش که برای Register کردن custom DbContext خود به سیستم dependency injection استفاده میکنیم تا بعدا نمونه ای از custom DbContext خود به صورت constructor parameters و یا دیگر روش های دریافت Instance از DI، دریافت کنیم روش زیر است :
services.AddDbContext<


BloggingContext

>(options => options.UseSqlServer("ConnectionString"));

🔹 که Register کردن DbContext به این طریق به معنی ساختن یک instance جدید از DbContext برای هر Request میباشد که مطمئنا روال Instance سازی از DbContext هزینه هایی برای اپلیکیشن دارد.
در نسخه 2.0 از Ef Core روش جدید برای Register کردن DbContext به سیستم dependency injection معرفی شد که همانطور که در مثال بعدی خواهید به صورت شفاف مجموعه ای از موارد DbContext قابل استفاده مجدد را ارائه می دهد.

services.AddDbContextPool<BloggingContext>(
    options => options.UseSqlServer(

ConnectionString


));

▪️ اگر از این متد برای Register کردن DbContext استفاده کنید زمانیه که در اپلیکیشن درخواست نمونه ای جدید از DbContext داده شود ابتدا در Context Pool چک میشود که ایا نمونه ای از DbContext وجود دارد و اگر نمونه ای وجو داشت،در اختیار درخواست دهنده قرار میدهد.
در نهایت هنگامی که Request پردازش شد و کار ان با نمونه دریافت شده DbContext تمام شد، Ef تمامیه State های قابل ردیابی DbContext را که از آنها آگاه هست را reset کرده و DbContext inctance دوباره به Context Pool بر میگردد.
این روال از نظر مفهومی شبیه connection pooling در Ado.net است و از مزیت های آن میتوان به کاهش هزینه ساخت DbContext instance اشاره کرد.
استفاده از این متد البته باعث محدودیت های اندکی در متد OnConfiguring() در DbContext میشود.

🔻 نکته بسیار مهم

نکته مهم این است که اگر به صورت Custom مکانیزمی را در derived DbContext class خود پیاده کرده باشید که باعث نگه داری state ای شود و از انجایی که Ef core فقط state هایی که از آنها اگاه هست را reset میکند پس در نتیجه state که شما به صورت custom ایجاد کرده اید در DbContext instance باقی میماند و باعث share شدن آن در بین درخواست ها میشود.


@fullStackDevs

#High_Performance
#EfCore_Best_Practice
#DbContext_pooling

🔸 در این پست به معرفی یک روش جدید Register کردن DbContext به Di Container در متد ConfigureServices در کلاس Startup می پردازیم.
ابتدایی ترین و ساده ترین روش که برای Register کردن custom DbContext خود به سیستم dependency injection استفاده میکنیم تا بعدا نمونه ای از custom DbContext خود به صورت constructor parameters و یا دیگر روش های دریافت Instance از DI، دریافت کنیم روش زیر است :
services.AddDbContext<


BloggingContext

>(options => options.UseSqlServer("ConnectionString"));

🔹 که Register کردن DbContext به این طریق به معنی ساختن یک instance جدید از DbContext برای هر Request میباشد که مطمئنا روال Instance سازی از DbContext هزینه هایی برای اپلیکیشن دارد.
در نسخه 2.0 از Ef Core روش جدید برای Register کردن DbContext به سیستم dependency injection معرفی شد که همانطور که در مثال بعدی خواهید به صورت شفاف مجموعه ای از موارد DbContext قابل استفاده مجدد را ارائه می دهد.

services.AddDbContextPool<BloggingContext>(
    options => options.UseSqlServer(

ConnectionString


));

▪️ اگر از این متد برای Register کردن DbContext استفاده کنید زمانیه که در اپلیکیشن درخواست نمونه ای جدید از DbContext داده شود ابتدا در Context Pool چک میشود که ایا نمونه ای از DbContext وجود دارد و اگر نمونه ای وجو داشت،در اختیار درخواست دهنده قرار میدهد.
در نهایت هنگامی که Request پردازش شد و کار ان با نمونه دریافت شده DbContext تمام شد، Ef تمامیه State های قابل ردیابی DbContext را که از آنها آگاه هست را reset کرده و DbContext inctance دوباره به Context Pool بر میگردد.
این روال از نظر مفهومی شبیه connection pooling در Ado.net است و از مزیت های آن میتوان به کاهش هزینه ساخت DbContext instance اشاره کرد.
استفاده از این متد البته باعث محدودیت های اندکی در متد OnConfiguring() در DbContext میشود.

🔻 نکته بسیار مهم

نکته مهم این است که اگر به صورت Custom مکانیزمی را در derived DbContext class خود پیاده کرده باشید که باعث نگه داری state ای شود و از انجایی که Ef core فقط state هایی که از آنها اگاه هست را reset میکند پس در نتیجه state که شما به صورت custom ایجاد کرده اید در DbContext instance باقی میماند و باعث share شدن آن در بین درخواست ها میشود.


@fullStackDevs

.NET December 2020 Updates – 5.0.1

به روزرسانی دات نت 2020 منتشرشد. این به روزرسانی ها شامل reliability و سایر موارد غیر ایمنی هستند. برای جزئیات بسته های به روز شده ، به یادداشت های انتشار جداگانه مراجعه کنید. همچنین از امروز ، به روزرسانی های .NET Core از طریق Microsoft Update شامل Windows Update Update Services (WSUS)

https://devblogs.microsoft.com/dotnet/net-december-2020/


انتیتی فریموورک (EF Core 5.0.1) اکنون در NuGet است!
#efcore #EntityFramework

انتیتی فریموورک (EF Core 5.0.0) فقط در چهار هفته بیش از 500،000 دانلود در NuGet داشته است.

اکنون 5.0.1 با رفع 26 اشکال در ناگت موجود است!
Download EF Core 5.0.1 from Nuget

@fullStackDevs

#Dapper
#EFCore

EF Core 6.0 !


#EntityFramework biweekly update #efcore

TechEmpower Fortunes perf!

⏫ EF Core 6.0 is 33.1% faster than EF Core 5.0
⏫ Dapper is also 6.0% faster
⏫ EF Core is now at 93.5% of Dapper perf


Plus: learn to contribute! We live-streamed a PR end-to-end.

📌 Link

@fullStackDevs