‫۶ سال و ۳ ماه قبل، جمعه ۲۵ خرداد ۱۳۹۷، ساعت ۱۳:۴۹
در جهت تکمیل بحث بارگذاری اطلاعات وابسته: اضافه شدن Lazy Loading به نگارش 2.1

برخلاف نگارش‌های پیشین EF، اینبار Lazy loading به صورت پیش‌فرض فعال نیست که در بسیاری از موارد یک مزیت مهم، در جهت بهبود کارآیی برنامه به حساب می‌آید؛ چون پیشتر مدام می‌بایستی توسط ابزارهای profiler، برنامه را بررسی می‌کردیم تا از وجود مشکلی به نام select n+1 مطلع می‌شدیم (lazy loading اشتباه، در جائی که نیازی به آن نبوده و رفت و برگشت بیش از اندازه‌ا‌ی را به بانک اطلاعاتی سبب شده‌است).
برای فعالسازی lazy loading در EF Core 2.1 (اگر واقعا به آن نیاز دارید البته) دو روش وجود دارد:
الف) فعالسازی Lazy loading توسط Proxyها
در این حالت ابتدا نیاز است بسته‌ی نیوگت Microsoft.EntityFrameworkCore.Proxies را نصب کنید. سپس در متد OnConfiguring مربوط به Context برنامه، متد UseLazyLoadingProxies را فراخوانی نمائید:
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseLazyLoadingProxies()
        .UseSqlServer(myConnectionString);
و یا اینکار در فایل آغازین برنامه نیز میسر است:
    .AddDbContext<BloggingContext>(
        b => b.UseLazyLoadingProxies()
              .UseSqlServer(myConnectionString));
اکنون EF Core 2.1 خواص راهبری (navigation properties) را که قابل بازنویسی باشند (همان مباحث AOP و تشکیل پروکسی‌ها)، lazy load می‌کند.
این خواص نیز حتما باید به صورت virtual معرفی شوند تا قابلیت بازنویسی را داشته باشند؛ مانند:
public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Post> Posts { get; set; }
}
public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public virtual Blog Blog { get; set; }
}
در این مثال با فعال بودن lazy loading، به محض لمس خاصیت Blog، اطلاعات مرتبط با آن از بانک اطلاعاتی واکشی خواهند شد و نه پیش از آن مانند eager loading که تمام اطلاعات وابسته‌ی به یک موجودیت را نیز واکشی می‌کند.
هرچند این قابلیت بارگذاری اطلاعات وابسته در آینده، جذاب به نظر می‌رسد اما در عمل در حین رندر یک گرید و یا بکارگیری حلقه‌ها، چون سبب رفت و برگشت بیش از اندازه‌ای به بانک اطلاعاتی خواهد شد، باید با دقت مورد استفاده قرار گیرد و اساسا استفاده‌ی از آن در برنامه‌های وب توصیه نمی‌شود (با بررسی‌های پروژه‌های بسیاری مشخص شده‌است که این قابلیت ضررش بیشتر از نفعش است).


ب) فعالسازی Lazy loading بدون استفاده از Proxyها
در این حالت نیازی به نصب بسته‌ی AOP جدید تشکیل پروکسی‌ها نیست. در اینجا در کلاس موجودیت خود باید سرویس ILazyLoader را تزریق کنید:
public class Blog
{
    private ICollection<Post> _posts;
public Blog()
    {
    }
private Blog(ILazyLoader lazyLoader)
    {
        LazyLoader = lazyLoader;
    }
private ILazyLoader LazyLoader { get; set; }
public int Id { get; set; }
    public string Name { get; set; }
public ICollection<Post> Posts
    {
        get => LazyLoader?.Load(this, ref _posts);
        set => _posts = value;
    }
}
public class Post
{
    private Blog _blog;
public Post()
    {
    }
private Post(ILazyLoader lazyLoader)
    {
        LazyLoader = lazyLoader;
    }
private ILazyLoader LazyLoader { get; set; }
public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
public Blog Blog
    {
        get => LazyLoader?.Load(this, ref _blog);
        set => _blog = value;
    }
}
در این روش نیازی به virtual معرفی کردن خواص راهبری نیست. اما در این حالت به علت استفاده‌ی از سرویس ILazyLoader، نیاز خواهید داشت تا بسته‌ی نیوگت Microsoft.EntityFrameworkCore.Abstractions را نیز نصب کنید.
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۲۳:۴۲
شما نیازی ندارید که برای هر کدام از این موارد یک SaveChanges جدا داشته باشید. تمام این اشیاء را به Context اضافه کنید و در پایان SaveChanges را فراخوانی کنید. کل این عملیات در طی یک تراکنش به بانک اطلاعاتی اعمال می‌شود و محاسبه و جایگذاری Idها هم در طی این تراکنش به صورت خودکار مدیریت خواهد شد.
یعنی شما نیازی به محاسبه و دریافت مستقیم Id والد از بانک اطلاعاتی و سپس درج آن در رکوردهای فرزندان ، ندارید. EF این موارد را در طی یک تراکنش به صورت خودکار مدیریت می‌کند. همینقدر که رکوردهای فرزندان توسط خاصیت راهبری که تعریف شده، ارجاعی را به والد خود داشته باشند، از دیدگاه EF یعنی محاسبه‌ی خودکار کلید خارجی و درج آن.
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۲۲:۵۳
- در اینجا تنظیم شده‌است.
- هدف از الگوی واحد کار به همراه تنظیمات تزریق وابستگی‌های آن و تمام این مسایل، به جهت داشتن یک وهله از DbContext در طول عمر یک درخواست هست. یعنی داشتن یک تراکنش کلی در طول درخواست و Commit خودکار آن توسط EF در پایان درخواست (با Dispose خودکار Context). تمام اعمال EF تراکنشی هستند و در بسیاری از موارد نیازی به ایجاد تراکنش‌های اضافی نیست. اگر به بیش از یک تراکنش نیاز دارید، شاید این الگو برای کار شما مناسب نباشد.
- آیا امکان دسترسی به بیش از یک وهله از Context در طول درخواست جاری زمانیکه از الگوی واحد کار استفاده می‌کنیم وجود دارد؟ بله. یک نمونه‌ی آن در کلاس DbLogger جهت ایجاد یک Context مجزا، برای ثبت وقایع برنامه و عدم تداخل آن با Context جاری درخواست، ایجاد می‌شود. نمونه‌ی دیگر آن جهت دائمی کردن کلیدهای رمزنگاری برنامه استفاده شده‌است.
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۱۸:۴۹
این خطا مرتبط به فعال بودن سعی مجدد درخواست‌های شکست خورده است:
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            @"Server=(localdb)\mssqllocaldb;Database=EFMiscellanous.ConnectionResiliency;Trusted_Connection=True;ConnectRetryCount=0",
            options => options.EnableRetryOnFailure());
}
و اگر این مورد فعال باشد، EF Core از تراکنش‌های سفارشی پشتیبانی نمی‌کند. بنابراین این مورد جزو خواص و تنظیمات DbContext شما است و مستقیما ارتباطی به IUnitOfWork که صرفا بیانگر وهله‌ای از آن است، ندارد.
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۱۳:۵۶
ارتقاء به EF Core 2.1: مقدار دهی اولیه‌ی جداول بانک‌های اطلاعاتی
روشی که در مطلب جاری در مورد متد Seed گفته شده‌است، هنوز هم کار می‌کند. در نگارش 2.1 روش توکاری را برای این منظور در متد OnModelCreating معرفی کرده‌اند:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
      .HasData(new Blog { BlogId = 1, Url = "http://sample.com" });
}
اعمال آن نیز تنها یکبار از طریق اجرای عملیات Migrations صورت می‌گیرد و محاسبات ثبت یا به روز رسانی آن نیز خودکار است.
اگر موجودیت در حال ثبت نیاز به تعریف کلید خارجی داشته باشد، باید از یک anonymous class استفاده کرد:
modelBuilder.Entity<Post>().HasData(
    new {BlogId = 1, PostId = 1, Title = "First post", Content = "Test 1"},
    new {BlogId = 1, PostId = 2, Title = "Second post", Content = "Test 2"});
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۱۳:۱۴
یک نکته‌ی تکمیلی:  روش به روز رسانی ابزارهای سراسری نصب شده
اگر دستور نصب یک ابزار سراسری مانند dotnet-outdated به این صورت باشد:
dotnet tool install --global dotnet-outdated
دستور به روز رسانی آن به این شکل خواهد بود:
dotnet tool update --global dotnet-outdated
‫۶ سال و ۳ ماه قبل، چهارشنبه ۲۳ خرداد ۱۳۹۷، ساعت ۰۵:۰۵
- لیست صفحاتی را که کاربر به آن دسترسی دارد، پس از لاگین برای او ارسال کنید (یا به صورت یک آرایه که در سمت Angular کش شود یا به صورت Claims سفارشی داخل توکن JWT او؛ مانند Claims سفارشی نقش‌ها که هم اکنون موجود است).
- سپس توسط یک محافظ مسیر سفارشی، دسترسی‌ها را از این آرایه خوانده و اعمال کنید. برای نمونه محافظ مسیر سفارشی یاد شده، بر اساس Claims مربوط به نقش‌های کاربر که پس از لاگین به سمت کلاینت ارسال می‌شوند، دسترسی به مسیرها را کنترل می‌کند.
‫۶ سال و ۳ ماه قبل، سه‌شنبه ۲۲ خرداد ۱۳۹۷، ساعت ۱۷:۲۱
نکته‌ای در مورد نحوه‌ی تعریف خواص تنظیمات strongly typed

- خواص تعریف شده در کلاس‌های تنظیمات که قرار است به مقادیر و مداخل فایل appsetting.json نگاشت شوند، نیاز است get و set دار باشند.
public class MySettings  
{
   public string StringSetting { get; set; }
   public int IntSetting { get; set; }
البته این مورد فقط جهت خواص ساده صدق می‌کند؛ چون در این حالت در صورت خالی بودن این مقادیر در فایل json، نیاز است نال یا صفر (مقدار پیش‌فرض) را دریافت کرد.

- اما در مورد خواص پیچیده، اینطور نیست:
 public List<string> ListValues { get; } = new List<string>();
در اینجا می‌توان یک خاصیت پیچیده را صرفا get دار تعریف کرد، با این شرط که در زمان binding دارای مقدار باشد؛ مانند new List فوق.

- در حین تعریف خواص پیچیده از اینترفیس‌ها و یا کلاس‌های abstarct نمی‌توان استفاده کرد:
 public ISet<string> Values { get; set; }
از این جهت که binder در پشت صحنه از Activator.CreateInstance(type) برای وهله سازی این خواص استفاده می‌کند و چون برای مثال ISet و یا IList و امثال آن صرفا اینترفیس هستند، قابلیت وهله سازی ندارند. این مورد را به صورت زیر می‌توان مدیریت کرد:
 public ISet<string> Values { get; } = new HashSet<string>(StringComparer.OrdinalIgnoreCase);
چون این خاصیت پیچیده‌است، صرفا get دار تعریف شده‌است به همراه یک آغاز کننده. همین مقدار برای بایند مقادیر به آن کافی است.
البته باید دقت داشت که آغاز کننده‌ی تعریف شده باید دارای متد Add باشد (مانند IList و List)؛ در غیر اینصورت اطلاعاتی به این لیست اضافه نخواهد شد. برای نمونه نمی‌توان از ReadOnlyCollection در اینجا استفاده کرد؛ چون متد Add ندارد.
‫۶ سال و ۳ ماه قبل، سه‌شنبه ۲۲ خرداد ۱۳۹۷، ساعت ۱۵:۵۶
روش دیگری برای آماده سازی دریافت فایل‌های بدون پسوند Let's encrypt
<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
        <rewrite> 
            <rules> 
                <rule name="LetsEncrypt" stopProcessing="true"> 
                    <match url=".well-known/acme-challenge/*" /> 
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" /> 
                    <action type="None" /> 
                </rule> 
            </rules> 
        </rewrite> 
    </system.webServer> 
</configuration>