‫۱ ماه قبل، دوشنبه ۸ مرداد ۱۴۰۳، ساعت ۱۶:۴۴

حل مشکل حذف منطقی در جداولی که فیلد منحصر به فرد دارند

[Index(nameof(PhoneNumber), IsUnique = true)]
public class User
{
    public long Id { get; set; }

    [Required]
    [MaxLength(100)]
    public string FullName { get; set; } = null!;

    [Required]
    [MaxLength(11)]
    public string PhoneNumber { get; set; } = null!;

    public bool IsDeleted { get; set; }
}

در موجودیت User فیلد PhoneNumber منحصر به فرد است.

کاربری با شماره تلفن 123 ثبت نام میکند و بعد حذف میشود

الان شماره تلفن 123 آزاد است و کاربر دیگری میتواند با این شماره ثبت نام کند و این کاربر نیز حذف میشود و یک کاربر جدید با شماره تلفن 123 ثبت نام میکند

FullName    PhoneNumber    IsDeleted
User1       123            True
User2       123            True
User3       123            False

پس با وجود اینکه شماره تلفن Unique است ولی میتوان شماره تلفن تکراری داشت به شرطی که IsDeleted=True باشد و باید فقط یک شماره تلفن 123 با IsDeleted=False داشت.

برای اینکار از Filter ها استفاده میکنیم و تنها کافیست در فایل Configuration موجودیت User این کد را اضافه کرد

public class UserConfiguration : IEntityTypeConfiguration<User>
{
    public void Configure(EntityTypeBuilder<User> builder)
    {
        builder.HasIndex(x => x.PhoneNumber)
            .HasFilter("[IsDeleted] = 0");
    }
}

الان شرط Unique بودن فقط در صورتی کار میکند که IsDeleted=False باشد.

چند مطلب و پروژه‌ی تکمیلی، اگر علاقمند به پیاده سازی سفارشی اعتبارسنجی و احراز هویت Blazor 8x در حالت SSR هستید:
- Custom cookie authentication in Blazor SSR  (اگر موفق به خواندن کامل آن نشدید، از این آدرس استفاده کنید)
- «SparkPoc» یک پیاده سازی سفارشی مبتنی بر کوکی مخصوص SSR
که اصل و اساس آن‌ها این مطلب است: «اعتبارسنجی مبتنی بر کوکی‌ها در ASP.NET Core 2.0 بدون استفاده از سیستم Identity» و در Blazor SSR هم قابل استفاده‌است.
‫۹ ماه قبل، شنبه ۱۸ آذر ۱۴۰۲، ساعت ۱۲:۱۲
اصلاحیه: کارآیی spread operator بیشتر نیست!

در متن در مورد spread operator عنوان شده «که ... نگارش C# 12 آن کارآیی بیشتری دارد». این مورد بدون توجه به #Low-Level C تولیدی، نوشته شد و ... متاسفانه نادرست است!
برای مثال فرض کنید، چنین متدی را دارید که با استفاده از spread operator، کار بازکردن یک آرایه را انجام می‌دهد:
public int[] WithSpread()
{
   int[] data = new int[10_000];
   int[] results = [..data];
   return results;
}
معادل #Low-Level C آن (کد نهایی که کامپایلر برای تبدیل آن به IL تولید می‌کند) به صورت زیر است ( #Low-Level C را در Rider، در منوی #Tools -> IL Viewer -> Select Low-Level C می‌توانید تولید کنید):
public int[] WithSpread()
{
  int[] numArray1 = new int[10000];
  int index1 = 0;
  int[] numArray2 = new int[numArray1.Length];
  int[] numArray3 = numArray1;
  for (int index2 = 0; index2 < numArray3.Length; ++index2)
  {
    int num = numArray3[index2];
    numArray2[index1] = num;
    ++index1;
  }
  return numArray2;
}
همانطور که مشاهده می‌کنید، این قطعه کد در C#12 و دات‌نت 8، به شدت ابتدایی تولید شده و به همراه هیچ نوع بهینه سازی نیست. کارآیی این قطعه کد، نسبت به زمانیکه از متد قدیمی CopyTo آرایه‌ها استفاده می‌شود، به مراتب کمتر است (تا 3 برابر!)؛ چون متد CopyTo به همراه بهینه سازی‌های سخت‌افزاری هم هست. به نظر قرار شده بهینه سازی کارآیی spread operator در نگارش بعدی دات‌نت انجام شود.

برای آزمایش شخصی آن، از کلاس زیر استفاده کنید:
using BenchmarkDotNet.Attributes;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace SpreadBenchmark
{
    [MemoryDiagnoser]
    public class Tests
    {
        private readonly int[] _myData = new int[10_000];

        [Benchmark(Baseline = true)]
        public int[] WithToArray()
        {
            int[] results = _myData.ToArray();
            return results;
        }

        [Benchmark]
        public int[] WithCopyTo()
        {
            int[] results = new int[_myData.Length];
            _myData.CopyTo(results, 0);
            return results;
        }

        [Benchmark]
        public int[] WithSpread()
        {
            int[] results = [.._myData];
            return results;
        }
    }
}
که در فایل Program.cs به این صورت فراخوانی می‌شود:
using BenchmarkDotNet.Running;
using SpreadBenchmark;

BenchmarkRunner.Run<Tests>();
با این وابستگی:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.13.10" />
  </ItemGroup>
</Project>
‫۹ ماه قبل، چهارشنبه ۱۵ آذر ۱۴۰۲، ساعت ۱۷:۲۷
در ASP.NET Core 8.0 نیز امکان مدیریت استثناءها به صورت سراسری با پیاده‌سازی اینترفیس  IExceptionHandler مسیر شده است:
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;

internal sealed class GlobalExceptionHandler : IExceptionHandler
{
    private readonly ILogger<GlobalExceptionHandler> _logger;

    public GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger)
    {
        _logger = logger;
    }

    public async ValueTask<bool> TryHandleAsync(
        HttpContext context,
        Exception exception,
        CancellationToken cancellationToken = default)
    {
        _logger.LogError(exception, "An unhandled exception has occurred while executing the request.");
        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "Server Error",
        };

        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        await context.Response.WriteAsJsonAsync(problemDetails);

        return true;
    }
}

برای ریجستر کردن آن نیز:
builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
// other code
app.UseExceptionHandler();
‫۹ ماه قبل، سه‌شنبه ۱۴ آذر ۱۴۰۲، ساعت ۱۱:۱۶
یک نکته‌ی تکمیلی: روش معرفی مستنداتی به استفاده کننده‌ها در مورد قابلیت آزمایشی در حال استفاده

اگر علاقمند هستید تا در حین نمایش خطاها، استفاده کننده‌ها را به آدرس خاصی نیز راهنمایی کنید، می‌توان از خاصیت UrlFormat به صورت زیر استفاده کرد:
[Experimental("SPC101", UrlFormat = "https://www.example.com/diagnostics/{0}.html")]
public static void TestMethod(string path)
در اینجا {0} به صورت خودکار با diagnostic ID جایگزین می‌شود.
‫۹ ماه قبل، دوشنبه ۱۳ آذر ۱۴۰۲، ساعت ۱۱:۵۳
یک نکته‌ی تکمیلی: روش اعتبارسنجی پارامترهای سازنده‌ی اولیه

اگر برای نمونه پیشتر کار اعتبارسنجی و یا بررسی نال نبودن پارامترهای دریافتی از متد سازنده را در همانجا انجام می‌دادید، روش انجام آن در حالت استفاده‌ی از پارامترهای سازنده‌ی اولیه، به صورت زیر است:
class Employee(string firstName, string lastName)
{
    private readonly string _firstName = firstName.Length >= 5 ? 
                                        firstName : 
                                        throw new ArgumentException("There must be atleast 5 characters");

    private readonly string _lastName = lastName;

    public string FullName()
    {
        return $"Full name  = {_firstName} {_lastName}";
    }
}
‫۹ ماه قبل، جمعه ۱۰ آذر ۱۴۰۲، ساعت ۱۷:۱۵
یک نکته‌ی تکمیلی: اضافه شدن پارامترهای از نوع ref readonly به C# 12

در انتهای نکته‌ی خروجی ref readonly عنوان شد که «در ابتدا قصد داشتند ref readonly را برای تعریف پارامترهای value type نیز بکار برند، اما این تصمیم با معرفی پارامترهای از نوع in جایگزین شد» اما ... مجددا به C# 12 اضافه شده‌است:
مثال زیر را درنظر بگیرید:
namespace CS8Tests;

public class RefReadonlySample
{
   public void Test()
   {
      var number = 5;
      Print(ref number);
      Console.WriteLine($"After Print -> Your number is {number}");
      
      // Output:
      // Print -> Your number is 5
      // After Print -> Your number is 6
   }
   
   private void Print(ref int number)
   {
      Console.WriteLine($"Print -> Your number is {number}");
      number++;
   }
}
در این مثال، ارجاعی از متغیر عددی number (که یک value type است) به کمک واژه‌ی کلیدی ref به متد Print ارسال شده و درون این متد، مقدار این متغیر تغییر کرده‌است که این تغییر به خارج از متد Print نیز منعکس می‌شود.
اگر بخواهیم از تغییرات پارامتر number در متد Print جلوگیری کنیم، می‌توان از واژه‌ی کلیدی in که در C# 7.2 ارائه شد، استفاده کرد:
 private void Print(in int number)
در این حالت در سطر ++number، به خطای زیر می‌رسیم:
error CS8331: Cannot assign to variable 'number' or use it as the right hand side of a ref assignment because it is a readonly variable

اکنون در C# 12 همین عمل را توسط واژه‌های کلیدی ref readonly نیز می‌توان پیاده سازی کرد:
private void Print(ref readonly int number)
خطایی را هم که گزارش می‌دهد، دقیقا همانند خطای ذکر شده‌ی واژه‌ی کلیدی in است.

سؤال: چرا این تغییر در C# 12 رخ داده‌است، زمانیکه واژه‌ی کلیدی in، دقیقا همین کار را انجام می‌داد؟
هدف، وضوح بیشتر API تولیدی و تاکید بر readonly بودن ارجاع دریافتی در این حالت و یکدستی قسمت‌های مختلف زبان است.
همچنین واقعیت این است که یک چنین قابلیت‌هایی، استفاده‌ی روزمره‌ای را در زبان #‍C ندارند و بیشتر هدف از وجود آن‌ها، استفاده از API کتابخانه‌های C++/C در زبان #C است. برای مثال بجای اینکه تمام ارجاعات فقط خواندنی آن‌ها را به پارامترهایی از نوع in تبدیل کنند (در کدهای قدیمی) که سبب بروز مشکلات عدم سازگاری می‌شود، اکنون می‌توانند به سادگی refهای قدیمی تعریف شده را ref readonly کنند؛ بدون اینکه استفاده کنندگان با مشکلی مواجه شوند.
‫۹ ماه قبل، جمعه ۱۰ آذر ۱۴۰۲، ساعت ۱۰:۵۹
یک نکته‌ی تکمیلی: کتابخانه‌ی «PolySharp» امکان استفاده‌ی از یک چنین قابلیت‌هایی را در نگارش‌های پایین‌تر دات‌نت نیز میسر می‌کند. همچنین کتابخانه‌ی مشابه دیگری به نام «Polyfill» هم در این زمینه موجود است.
‫۹ ماه قبل، جمعه ۱۰ آذر ۱۴۰۲، ساعت ۰۲:۰۸
یک نکته‌ی تکمیلی: در C# 12 می‌توان کلاس‌ها، structها و interfaceهای بدون بدنه داشت!

اگر به متن دقت کرده باشید، یک چنین تعریفی هم در آن هست:
public class MyBaseClass(string s); // no body required
این مورد هم جزو تازه‌های C# 12 است. برای مثال بجای {}class Foo می‌توان نوشت ;class Foo. تمام موارد زیر در C# 12 مجاز هستند:
class Foo;

struct Bar;

interface IFoo;
معمولا از اینترفیس‌های بدون بدنه برای علامتگذاری یک‌سری کلاس‌ها و یافتن ساده‌تر آن‌ها از طریق Reflection استفاده می‌شود.