مطالب
نگاشت خودکار اشیاء توسط AutoMapper و Reflection - ایده شماره 1
آموزش کامل AutoMapper قبلا در سایت ارائه شده است. در این مقاله می‌خواهیم Mapping نوع‌های مختلف بین Dto و Entity‌های پروژه را توسط Reflection به صورت خودکار انجام دهیم. سورس کامل مثال را می‌توانید در این ریپازیتوری مشاهده کنید.
در این روش ما یک کلاس جنریک را به نام BaseDto داریم که تمام Dto‌های ما برای نگاشت خودکار باید از آن ارث بری کنند. در مثال زیر کلاس PostDto لازم است به کلاس Post نگاشت شود. پس خواهیم داشت :
public class PostDto : BaseDto<PostDto, Post, long>
{
    public string Title { get; set; }
    public string Text { get; set; }
    public int CategoryId { get; set; }

    public string CategoryName { get; set; } //=> Category.Name
}
  • کلاس PostDto خودش را به عنوان اولین پارامتر جنریک BaseDto معرفی می‌کند.
  • به عنوان پارامتر دوم، باید کلاس Entity ایی که قرار است به آن نگاشت شود (Post) را معرفی کنیم.
  • پارامتر سوم، نوع فیلد Id است که در اینجا خاصیت Id کلاس‌های Post و PostDto ما، از نوع long است.
  • نهایتا خواصی را که برای نگاشت لازم داریم، تعریف میکنیم مثل Title و...
  • همچنین می‌توانیم خواصی برای نگاشت با خواص Navigation Property‌های Post هم تعریف کنیم؛ مانند CategoryName که به خاصیت Name از Category پست مربوطه اشاره میکند و AutoMapper به صورت هوشمندانه آن‌ها را به هم نگاشت می‌کند.
تعریف کلاس جنریک BaseDto هم به نحو زیر است.
public abstract class BaseDto<TDto, TEntity, TKey>
        where TDto : class, new()
        where TEntity : BaseEntity<TKey>, new()
{
    [Display(Name = "ردیف")]
    public TKey Id { get; set; }

    public TEntity ToEntity()
    {
        return Mapper.Map<TEntity>(CastToDerivedClass(this));
    }

    public TEntity ToEntity(TEntity entity)
    {
        return Mapper.Map(CastToDerivedClass(this), entity);
    }

    public static TDto FromEntity(TEntity model)
    {
        return Mapper.Map<TDto>(model);
    }

    protected TDto CastToDerivedClass(BaseDto<TDto, TEntity, TKey> baseInstance)
    {
        return Mapper.Map<TDto>(baseInstance);
    }
}
  • نوع TDto به کلاس Dto ما اشاره میکند؛ مثلا PostDto
  • نوع TEntity به کلاس Entity ما اشاره میکند؛ مثلا Post
  • نوع TKey به نوع خاصیت Id اشاره میکند.
  • شرط لازم برای نوع TEntity این است که از <BaseEntity<TKey ارث بری کرده باشد (نوع پایه‌ای که تمام Entity‌های ما از آن ارث بری می‌کنند).
  • متد‌های کمکی ToEntity و FromEntity، کار نگاشت اشیاء را برای ما راحت‌تر می‌کنند.
پیاده سازی کلاس BaseEntity و Post نیز به شرح زیر است.
public abstract class BaseEntity<TKey>
{
    public TKey Id { get; set; }
}

public class Post : BaseEntity<long>
{
    public string Title { get; set; }
    public string Text { get; set; }
    public int CatgeoryId { get; set; }

    public Category Category { get; set; }
}

توضیح متد های ToEntity  و  FromEntity 
متد ToEntity شی Dto جاری را به Entity مربوطه نگاشت کرده و یک وهله از آن را باز میگرداند. پس بجای استفاده دستی از Api‌های AutoMapper مانند Mapper.Map<Post>(postDto)  کافی است متد ToEntity را فراخوانی کنیم؛ مثال:
var postDto = new PostDto();
var post = postDto.ToEntity();
متد بالا برای اکشن Create مناسب است؛ ولی برای اکشن Update خیر. چرا که برای Update نباید نگاشت بر روی وهله جدیدی از Post انجام شود؛ بلکه باید بر روی وهله‌ای از قبل موجود (همان post ایی که بر اساس id واکشی کرده‌ایم) نگاشت انجام شود، تا تغییرات لازم، بر روی همان وهله تاثیر کند. در غیر این صورت اگر وهله جدیدی از post ایجاد شود، چون توسط EF ChangeTracker ردیابی نمی‌شود، به‌روز رسانی هم انجام نخواهد شد.
بنابراین برای نگاشت postDto به یک شیء Post از پیش موجود (post یافت شده توسط id) خواهیم داشت:
var post = // finded by id
var updatePost = postDto.ToEntity(post);
همچنین برای نگاشت از یک Entity به Dto (عکس قضیه بالا: مثلا نگاشت یک postDto به post) کافی است متد ایستای FromEntity را خوانی کنیم. مثال :
var postDto = PostDto.FromEntity(post);

کانفیگ خودکار Mapping توسط Reflection
در ادامه می‌خواهیم کانفیگ Mapping بین Dto‌های پروژه به Entity‌های مربوطه (مثلا PostDto به Dto و برعکس) را به صورت خودکار توسط Reflection پیاده سازی و اعمال کنیم. این کار توسط کلاس AutoMapperConfiguration به نحو زیر انجام می‌شود.
public static class AutoMapperConfiguration
{
    public static void InitializeAutoMapper()
    {
        Mapper.Initialize(configuration =>
        {
            configuration.ConfigureAutoMapperForDto();
        });

        //Compile mapping after configuration to boost map speed
        Mapper.Configuration.CompileMappings();
    }

    public static void ConfigureAutoMapperForDto(this IMapperConfigurationExpression config)
    {
        config.ConfigureAutoMapperForDto(Assembly.GetEntryAssembly());
    }

    public static void ConfigureAutoMapperForDto(this IMapperConfigurationExpression config, params Assembly[] assemblies)
    {
        var dtoTypes = GetDtoTypes(assemblies);

        var mappingTypes = dtoTypes
            .Select(type =>
            {
                var arguments = type.BaseType.GetGenericArguments();
                return new
                {
                    DtoType = arguments[0],
                    EntityType = arguments[1]
                };
            }).ToList();

        foreach (var mappingType in mappingTypes)
            config.CreateMappingAndIgnoreUnmappedProperties(mappingType.EntityType, mappingType.DtoType);
    }

    public static void CreateMappingAndIgnoreUnmappedProperties(this IMapperConfigurationExpression config, Type entityType, Type dtoType)
    {
        var mappingExpression = config.CreateMap(entityType, dtoType).ReverseMap();

        //Ignore mapping to any property of source (like Post.Categroy) that dose not contains in destination (like PostDto)
        //To prevent from wrong mapping. for example in mapping of "PostDto -> Post", automapper create a new instance for Category (with null catgeoryName) because we have CategoryName property that has null value
        foreach (var property in entityType.GetProperties())
        {
            if (dtoType.GetProperty(property.Name) == null)
                mappingExpression.ForMember(property.Name, opt => opt.Ignore());
        }
    }

    public static IEnumerable<Type> GetDtoTypes(params Assembly[] assemblies)
    {
        var allTypes = assemblies.SelectMany(a => a.ExportedTypes);

        var dtoTypes = allTypes.Where(type =>
                type.IsClass && !type.IsAbstract && type.BaseType != null && type.BaseType.IsGenericType &&
                (type.BaseType.GetGenericTypeDefinition() == typeof(BaseDto<,>) ||
                type.BaseType.GetGenericTypeDefinition() == typeof(BaseDto<,,>)));

        return dtoTypes;
    }
}
عملیات با فراخوانی متد ایستا InitializeAutoMapper شروع می‌شود و باید این متد فقط یکبار در اجرای پروژه فراخوانی شود. (مثلا در سازنده کلاس Startup.cs)
public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
        AutoMapperConfiguration.InitializeAutoMapper();
    }
- درون این متد کانفیگ، Mapping نوع‌های مختلف قابل نگاشت برای AutoMapper توسط Mapper.Initialize انجام می‌شود.
- متد ConfigureAutoMapperForDto متد دیگری را به همین نام، فراخوانی می‌کند؛ با این تفاوت که Assembly ورودی پروژه را توسط متد ()Assembly.GetEntryAssembly، یافته و به آن پاس میدهد.
- EntryAssembly به اسمبلی ای که به عنوان نقطه ورود برنامه است، اشاره می‌کند. در این سورس کد چون پروژه ما از نوع ASP.NET Core است، اسمبلی این پروژه به عنوان EntryAssmebly شناخته می‌شود؛ یعنی همان لایه‌ای که کلاس‌های Dto ما (مانند PostDto) داخل آن تعریف شده‌است. ما به این اسمبلی از این جهت نیاز داریم که می‌خواهیم توسط Reflection، تمام نوع‌هایی که از BaseDto ارث بری می‌کنند (مانند PostDto) را یافته و Mapping آنها را به AutoMapper معرفی و اعمال کنیم.
نکته : اگر در پروژه شما Dto‌ها در لایه/لایه‌های دیگری تعریف شده‌اند باید اسمبلی آن لایه‌ها را به آن پاس دهید.
در این مرحله توسط متد GetDtoTypes کار یافتن نوع‌های Dto موجود در اسمبلی/اسمبلی‌های مشخص شده انجام می‌شود.
public static IEnumerable<Type> GetDtoTypes(params Assembly[] assemblies)
{
    var allTypes = assemblies.SelectMany(a => a.ExportedTypes);

    var dtoTypes = allTypes.Where(type =>
            type.IsClass && !type.IsAbstract && type.BaseType != null && type.BaseType.IsGenericType &&
            (type.BaseType.GetGenericTypeDefinition() == typeof(BaseDto<,>) ||
            type.BaseType.GetGenericTypeDefinition() == typeof(BaseDto<,,>)));

    return dtoTypes;
}
  • در خط اول ابتدا تمامی نوع‌های قابل دسترس از بیرون (ExportedTypes) از assembly‌های دریافتی واکشی می‌شود.
  • سپس توسط Where، نوع‌هایی که کلاس بوده، abstract نیستند و از BaseDto ارث بری کرده‌اند، فیلتر شده و بازگردانده می‌شوند.
در ادامه، از لیست نوع‌های Dto یافت شده، پارامتر‌های جنریک TDto و TEntity به ازای هر نوع استخراج می‌شوند.
public static void ConfigureAutoMapperForDto(this IMapperConfigurationExpression config, params Assembly[] assemblies)
{
var dtoTypes = GetDtoTypes(assemblies);

var mappingTypes = dtoTypes
.Select(type =>
{
var arguments = type.BaseType.GetGenericArguments();
return new
{
DtoType = arguments[0],
EntityType = arguments[1]
};
}).ToList();

foreach (var mappingType in mappingTypes)
config.CreateMappingAndIgnoreUnmappedProperties(mappingType.EntityType, mappingType.DtoType);
}

در آخر بر روی لیست یافت شده، گردش می‌کنیم (foreach) و دو نوع DtoType و EntityType (مانند postDto و post) را که باید به یکدیگر نگاشت شوند، به متد CreateMappingAndIgnoreUnmappedProperties ارسال می‌کنیم. کار این متد، معرفی/اعمال Mapping بین نوع‌ها به کانفیگ AutoMapper می‌باشد. همچنین خواصی را که نباید نگاشت شوند، به طور خودکار یافته و Ignore می‌کند.
در مثال جاری، خاصیت CategoryName کلاس PostDto برای خواندن و select از دیتابیس لازم است زیرا می‌خواهیم هر postDto، شامل نام دسته بندی هر پست نیز باشد، ولی این ویژگی برای افزودن یا به‌روزرسانی مدنظر ما نیست؛ چرا که کلاینت ما به هنگام فراخوانی اکشن Create، فقط مقادیر خواص Post (مانند Title, Text و CategoryId) را ارسال می‌کند و نه CategoryName را. در نتیجه CatgoryName همیشه null است. اما مشکلی که ایجاد می‌کند این است که AutoMapper به هنگام نگاشت یک PostDto به Post، چون خاصیت CategoryName با (مقدار null)  وجود دارد، یک وهله جدید (با مقادیر پیشفرض) را برای Category ایجاد می‌کند که خاصیت Name آن برابر با null است و قطعا این مدنظر ما نیست. پس جهت جلوگیری از این مشکل لازم است خواصی از Entity که در Dto موجود نیستند (مانند Category) را Ignore کنیم و این دقیقا همان کاری است که متد CreateMappingAndIgnoreUnmappedProperties انجام می‌دهد. 
public static void CreateMappingAndIgnoreUnmappedProperties(this IMapperConfigurationExpression config, Type entityType, Type dtoType)
{
    var mappingExpression = config.CreateMap(entityType, dtoType).ReverseMap();

    //Ignore mapping to any property of entity (like Post.Categroy) that dose not contains in dto (like PostDto.CategoryName)
    //To prevent from wrong mapping. for example in mapping of "PostDto -> Post", automapper create a new instance for Category (with null catgeoryName) because we have CategoryName property that has null value
    foreach (var property in entityType.GetProperties())
    {
        if (dtoType.GetProperty(property.Name) == null)
            mappingExpression.ForMember(property.Name, opt => opt.Ignore());
    }
}
البته اساسا استفاده از یک Dto هم برای Create/Update و هم برای Select اصولی نیست و بهتر است دو Dto جداگانه که صرفا خواص مورد نیاز را دارند، داشته باشیم که در این صورت مشکل بالا نیز اصلا رخ نخواهد داد. راه حل مورد استفاده کنونی صرفا مرهمی برای یک استفاده غیر اصولی است!
در آخر می‌توان گفت تنها ایراد کوچک ایده‌ی فوق، استفاده از Api‌های استاتیک AutoMapper در کلاس BaseDto است (متد Mapper.Map)  که باعث می‌شود نتوانیم به هنگام تست نویسی، سرویس AutoMapper را با پیاده سازی دیگری (Fake) جایگزین و آن را Mock کنیم. البته این کار برای AutoMapper زیاد معمول هم نبوده و در مقابل مزایای این ایده، به نظرم ارزش استفاده را خواهد داشت.
در قسمت بعدی همین ایده را توسعه خواهیم داد و قابلیت سفارشی سازی Mapping را برای آن فراهم خواهیم کرد.
مطالب
آشنایی اولیه با gRPC
در مقاله‌ی قبلی بطور کلی با Protocol ‌Buffers آشنا شدیم. در این قسمت با gRPC  آشنا شده و همچنین به پیاده سازی یک سرور و کلاینت، با استفاده از gRPC پرداخته که توسط آن به تبادل اطلاعات با یکدیگر میپردازند. 
gRPC یک فریم ورک مدرن و متن باز با کارآیی بالاست. توسط گوگل پیاده سازی شده و جزء انجمن CNCF میباشد (مثل Docker & Kubernetes) که بر روی سیستم عامل‌های متعددی اجرا میشود. به صورت خیلی کارا میتواند سرویس‌های متعددی را به یکدیگر متصل کرده و همچنین از امکاناتی همچون load balancing, monitoring, tracing, health checking, authentication به صورت خیلی ساده پشتیبانی میکند. بسایر سریع و همچنین Low Latency است. مستقل از یک زبان برنامه نویسی خاص هست و برای streaming بسیار مناسب است و همچنین برای سیستم‌های توزیع شده پیشنهاد میشود و به راحتی قابل توسعه و نگهداری است.
راجع به مزایای gRPC بسیار صحبت کردیم. برای طراحی سرویس‌های متعددی که با یکدیگر در ارتباط هستند، مناسب میباشد. از HTTP/2 به صورت پیشفرض استفاده میکند (راجع به تفاوت HTTP/2 و HTTP1 اینجا  را مطالعه بفرمایید).
شاید بزرگترین مشکلی که در حال حاضر دارد این است که REST را پشتیبانی نمیکند. بدین معنا که شما از طریق browser نمیتوانید یک در خواست را به یک سرور پیاده سازی شده توسط gRPC بصورت مستقیم ارسال کنید. راه حل اول برای حل این مشکل، پیاده سازی یک restful gateway با ابزار دلخواه خود و بقیه سرویس‌ها بعد از آن به هم از طریق gRPC ارتباط برقرا میکنند، یا راه حل بهتر اینکه از grpc-gateway  استفاده شود. ابزاری است که به کمک آن میتوانید سیستم خود را با REST یکپارچه سازی نمایید (هر چند راه‌های دیگری برای وصل شدن از مرورگر به یک سرور gRPC با استفاده از کتابخانه‌های third party میسر شده، اما خارج از موضوع بحث است و مطالعه‌ی بیشتر را به خواننده واگذار میکنم)
قدم اول در پیاده سازی یک سرور/کلاینت با استفاده از gRPC، آشنایی با protocol buffers هست. برای آشنایی، به مقاله‌ی قبلی رجوع فرمایید. تمامی پیاده سازی‌های ما از روی کد‌های تولید شده از تعاریف protocol bufferهایی هست که نوشته‌ایم.
حال فرض کنید میخواهیم یک سرور gRPC را با استفاده از #C نوشته و پیاده سازی نماییم:
۱) قدم اول قطعا نوشتن protobuf می‌باش‍د‍‍. همانطور که در مقاله‌ی قبلی ذکر شده است، به صورت زیر، مدل و همچنین متد‌های لازم را معرفی مینماییم و نام آن را helloworld.proto قرار میدهیم.
syntax = "proto3";

package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}
مدل و سرویس‌ها بصورت واضحی نوشته شده‌اند؛ SayHello با ورودی HelloRequest و خروجی HelloReply تعیین شده‌است.
۲) حالا کافی است یک پروژه‌ی Console را ساخته و ابتدا پکیج‌های زیر را نصب نماییم.
Google.Protobuf
grpc
Grpc.Tools
از طریق Grpc.Tools میتوانیم protobuf‌های خود را بصورت خودکار بعد از build تولید نماییم. در csproj آیتم زیر را اضافه کرده و آدرس protobuf را تعیین مینماییم.
<ItemGroup>
      <Protobuf Include="helloworld.proto" />
  </ItemGroup>
حال کافی است کد‌های زیر را جایگزین نماییم:
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using Helloworld;
using Grpc.Core;

namespace ServerGrpc
{
    class GreeterImpl : Greeter.GreeterBase
    {
        public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
        {
            System.Console.WriteLine("request made!");
            return Task.FromResult(new HelloReply { Message = "Hello " + request.Name });
        }
    }

    class Program
    {
       const int Port = 50051;

        public static void Main(string[] args)
        {
            Server server = new Server
            {
                Services = { Greeter.BindService(new GreeterImpl()) },
                Ports = { new ServerPort("localhost", Port, ServerCredentials.Insecure) }
            };
            server.Start();

            Console.WriteLine("Greeter server listening on port " + Port);
            Console.WriteLine("Press any key to stop the server...");
            Console.ReadKey();

            server.ShutdownAsync().Wait();
        }
    }
}
همانطور که مشاهده میکنید، مدل‌ها و سریس‌ها بصورت خودکار تولید شده‌اند (ضمن اینکه میتوانستیم بصورت دستی نیز protobuf را برای زبان دلخواه خود تولید نماییم).
سرور را بر روی پورت مشخصی ایجاد کرده و همچنین سرویس مورد نظرمان را پیاده سازی کرده‌ایم؛ به صورت فوق همه چیز به ساده‌ترین صورت در نظر گرفته شده است.
gRPC به صورت خودکار از پروتکل امن ssl استفاده میکند؛ اما برای راحتی کار ما از آن استفاده نکرده‌ایم.
نکته: فایل‌های generate شده را از طریق آدرس زیر میتوانید پیدا کنید:
obj/Debug/netcoreapp2.2(یا نسخه‌ی دیگری که استفاده میکنید)

حالا بنا داریم یک کلاینت را با یک زبان برنامه نویسی کاملا مجزا نوشته و به سرور grpc متصل شویم. این کلاینت را با زبان Go خواهیم نوشت (بدیهی است می‌توان جای زبان‌های برنامه نویسی کلاینت و سرور را تغییر داد).
نکته: خیلی وارد جزیات زبان Go نمی‌شویم و فقط اشاره‌ای به موارد کلی خواهیم کرد.
ابتدا باید از روی protobuf کد مربوط به Go را تولید نماییم؛ به صورت زیر:
protoc helloworld.proto --go_out=plugins=grpc:.
فرض کنید فایل generate شده در پوشه‌ی proto قرار گرفته به نام "helloworld.pb.go"
یک فایل به نام main.go ساخته و کد‌های زیر را وارد مینماییم.
package main
import (
        "fmt"
        "golang.org/x/net/context"
        "google.golang.org/grpc"
        "gosample/proto"
)
func main() {
    initial()
}

func initial(){
    conn, _ := grpc.Dial("localhost:50051", grpc.WithInsecure())
    defer conn.Close()
    client := helloworld.NewGreeterClient(conn)
    data, _ := client.SayHello(context.Background(), &helloworld.HelloRequest{Name : "Ali"})

    fmt.Println(data)
}

 به سرور به صورت insecure متصل شده ایم؛ آخر برنامه connection را می‌بندیم و SayHello را فراخوانی کرده و جواب را بر روی خروجی نمایش میدهیم.
نکته: gosample اسم پروژه‌ای است که من ساخته‌ام و proto آدرس پوشه‌ای است که فایل تولید شده‌ی grpc داخل آن قرار گرفته‌است؛ بقیه نیز کتابخانه‌های لازم برای کار با grpc میباشد.
نکته: gRPC برای streaming دیتا بسیار مناسب است (هم یکطرفه و همینطور دو طرفه).
نکته: به دلیل سادگی کار با ابزار‌های مختلف، انتخاب خیلی خوبی برای سیستم‌های توزیع شده‌است؛ همانطور که مشاهده کردید به راحتی قابلیت تعامل بین زبان‌های برنامه نویسی متعددی برقرار است.
نکته‌ی آخر: از وارد شدن به موارد ریز اجتناب کرده‌ام و صرفا این مقاله جهت آشنایی و دید کلی نسبت به این موضوع در نظر گرفته شده‌است.
مطالب
C# 12.0 - Interceptors
به C# 12 و دات‌نت 8، ویژگی «آزمایشی» جدیدی به نام Interceptors اضافه شده‌است که به آن «monkey patching» هم می‌گویند. هدف از آن، جایگزین کردن یک پیاده سازی، با پیاده سازی دیگری است. به این ترتیب توسعه دهندگان دات‌نتی می‌توانند فراخوانی متدهایی خاص را ره‌گیری کرده (interception) و سپس آن‌را به فراخوانی یک پیاده سازی جدید، هدایت کنند.


Interceptor چیست؟

از زمان ارائه‌ی NET 8 preview 6 SDK. به بعد، امکان ره‌گیری هر متدی از کدهای برنامه، به دات‌نت اضافه شده‌است؛ به همین جهت از واژه‌ی Interceptor/ره‌گیر در اینجا استفاده می‌شود. خود تیم دات‌نت از این قابلیت در جهت بازنویسی پویای قسمت‌هایی از کدهای زیرساخت دات‌نت که از Reflection استفاده می‌کنند، با نگارش‌های کامپایل شده‌ی مختص به برنامه‌ی شما، کمک می‌گیرند. به این ترتیب سرعت و کارآیی برنامه‌های دات‌نت 8، بهبود قابل ملاحظه‌ای را پیدا کرده‌اند. برای مثال ahead-of-time compilation (AOT) در دات‌نت 8 و ASP.NET Core 8x بر اساس این ویژگی پیاده سازی شده‌است. این ویژگی جدید، مکمل source generators است که در نگارش‌های پیشین دات‌نت ارائه شده بود.


بررسی  Interceptors با تهیه‌ی یک مثال ساده

فرض کنید می‌خواهیم فراخوانی متد GetText زیر را ره‌گیری کرده و سپس آن‌را با نمونه‌ی دیگری جایگزین کنیم:
namespace CS8Tests;

public class InterceptorsSample
{
    public string GetText(string text)
    {
        return $"{text}, World!";
    }
}
برای اینکار ابتدا نیاز است یک فایل جدید را به نام InterceptsLocationAttribute.cs با محتوای زیر به پروژه اضافه کرد:
namespace System.Runtime.CompilerServices;

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true, Inherited = false)]
public sealed class InterceptsLocationAttribute : Attribute
{
    public InterceptsLocationAttribute(string filePath, int line, int character)
    {
    }
}
همانطور که در مقدمه‌ی بحث هم عنوان شد، این ویژگی هنوز آزمایشی است و نهایی نشده و ویژگی فوق نیز هنوز به دات‌نت اضافه نشده‌است. به همین جهت فعلا باید آن‌را به صورت دستی به پروژه اضافه کرد و احتمالا در نگارش‌های بعدی دات‌نت، امضای آن تغییر خواهد کرد ... یا حتی ممکن است بطور کامل حذف شود!

سپس فرض کنید فراخوانی متد GetText در فایل Program.cs برنامه به صورت زیر انجام شده‌است:
using CS8Tests;

var example = new InterceptorsSample();
var text = example.GetText("Hello");
Console.WriteLine(text); //Hello, World!
یعنی متد GetText، در سطر چهارم و کاراکتر 20 ام آن فراخوانی شده‌است. این اعداد مهم هستند!

در ادامه از این اطلاعات در ره‌گیر سفارشی زیر استفاده خواهیم کرد:
using System.Runtime.CompilerServices;

namespace CS8Tests;

public static class MyInterceptor
{
    [InterceptsLocation("C:\\Path\\To\\CS8Tests\\Program.cs", 4, 20)] 
    public static string InterceptorMethod(this InterceptorsSample example, string text)
    {
        return $"{text}, DNT!";
    }
}
این ره‌گیر که به صورت متدی الحاقی برای کلاس InterceptorsSample دربرگیرنده‌ی متد GetText تهیه می‌شود، کار جایگزینی فراخوانی آن‌را در سطر چهارم و کاراکتر 20 ام فایل Program.cs انجام می‌دهد. امضای پارامترهای این متد، باید با امضای پارامترهای متد ره‌گیری شده، یکی باشد.

اکنون اگر برنامه را اجرا کنیم ... با خطای زیر مواجه می‌شویم:
 error CS9137: The 'interceptors' experimental feature is not enabled in this namespace. Add
'<InterceptorsPreviewNamespaces>$(InterceptorsPreviewNamespaces);CS8Tests</InterceptorsPreviewNamespaces>'
to your project.
عنوان می‌کند که این ویژگی آزمایشی است و باید فایل csproj. را به صورت زیر تغییر داد تا بتوان از آن استفاده نمود:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <!--<NoWarn>Test001</NoWarn>-->
    <InterceptorsPreviewNamespaces>$(InterceptorsPreviewNamespaces);CS8Tests</InterceptorsPreviewNamespaces>
  </PropertyGroup>
</Project>
اینبار برنامه کامپایل شده و اجرا می‌شود. در این حالت خروجی جدید برنامه، خروجی تامین شده‌ی توسط ره‌گیر سفارشی ما است:
Hello, DNT!


سؤال: آیا ره‌گیری انجام شده، در زمان کامپایل انجام می‌شود یا در زمان اجرا؟

برای این مورد می‌توان به Low-Level C# code تولیدی مراجعه کرد. برای مشاهده‌ی یک چنین کدهایی می‌توانید از منوی Tools->IL Viewer برنامه‌ی Rider استفاده کرده و در برگه‌ی ظاهر شده، گزینه‌ی Low-Level C# آن‌را انتخاب نمائید:
using CS8Tests;
using System;
using System.Runtime.CompilerServices;

[CompilerGenerated]
internal class Program
{
  private static void <Main>$(string[] args)
  {
    Console.WriteLine(new InterceptorsSample().InterceptorMethod("Hello"));
  }

  public Program()
  {
    base..ctor();
  }
}
همانطور که مشاهده می‌کنید، این ره‌گیری و جایگزینی، در زمان کامپایل انجام شده و کامپایلر، به‌طور کامل نحوه‌ی فراخوانی متد GetText اصلی را به متد ره‌گیر ما تغییر داده و بازنویسی کرده‌است.


سؤال: آیا این قابلیت واقعا کاربردی است؟!

اکنون شاید این سؤال مطرح شود که ... واقعا چه کسی قرار است مسیر کامل یک فایل، شماره سطر و شماره ستون فراخوانی متدی را به اینگونه در اختیار سیستم ره‌گیری قرار دهد؟! آیا واقعا این قابلیت، یک قابلیت کاربردی و مناسب است؟!
اینجا است که اهمیت source generators مشخص می‌شود. توسط source generators دسترسی کاملی به syntax trees وجود دارد و همچنین یکسری اطلاعات تکمیلی مانند FilePath و سپس CSharpSyntaxNodeها که دسترسی به داده‌های متد ()GetLocation را دارند که مکان دقیق سطر و ستون‌های فراخوانی‌ها را مشخص می‌کند.


کاربردهای فعلی ره‌گیرها در دات نت 8

در دات نت 8، این موارد با استفاده از ره‌گیرها بهینه سازی شده و سرعت آن‌ها افزایش یافته‌اند:
- فراخوانی‌هایی که تمام اطلاعات آن‌ها در زمان کامپایل فراهم است، مانند Regex.IsMatch(@"a+b+") که از یک الگوی ثابت و مشخص استفاده می‌کند، ره‌گیری شده و پیاده سازی آن با کدی استاتیک، جایگزین می‌شود.
- در ASP.NET Minimal API، استفاده از lambda expressions جهت ارائه‌ی تعاریفی مانند:
app.MapGet("/products", handler: (int? page, int? pageLength, MyDb db) => { ... })
مرسوم است. این نوع فراخوانی‌ها نیز توسط ره‌گیرها برای جایگزینی handler آن‌ها با کدهای استاتیک، جهت بالابردن کارآیی و کاهش تخصیص‌های حافظه انجام می‌شود.
- بهبود کارآیی foreach loops جهت استفاده از ریاضیات برداری و SIMD در صورت امکان.
- بهبود کارآیی تزریق وابستگی‌ها، زمانیکه به تعاریف مشخصی مانند ()<provider.Register<MyService ختم می‌شود.
- بجای استفاده از expression trees در زمان اجرای برنامه، اکنون می‌توان کدهای SQL معادل را در زمان کامپایل برنامه تولید کرد.
- بهبود کارآیی Serializers، زمانیکه از یک نوع مشخص مانند ()<Serialize<MyType استفاده می‌شود و کامپایلر می‌تواند آن‌را با کدهای زمان کامپایل، جایگزین کند.


محدودیت‌های ره‌گیرها در دات‌نت 8

- ره‌گیرهای دات‌نت 8 فقط با متدها کار می‌کنند.
- مسیر ارائه شده حتما باید یک مسیر کامل و مشخص باشد. یعنی اگر این قطعه کد، به سیستم دیگری منتقل شود، کامپایل نخواهد شد و امکان ارائه‌ی مسیرهای نسبی وجود ندارد.
- امضای متدها، حتما باید یکی باشد. یعنی نمی‌توان یک ره‌گیر جنریک را تعریف کرد.
اشتراک‌ها
CSS isolation در ASP.NET Core 6

CSS isolation simplifies an app’s CSS footprint by preventing dependencies on global styles and helps to avoid styling conflicts among components and libraries.

CSS isolation در ASP.NET Core 6
اشتراک‌ها
71 Loaders زیبا

71 CSS Loaders

Collection of HTML and CSS loader animation. Demo and download code (*zip).
Update of March 2017 collection. 17 new items. 

71 Loaders زیبا
نظرات مطالب
اعتبار سنجی سمت کاربر wysiwyg-editor ها در ASP.NET MVC
در همان callback اعتبارسنجی (function (value, element, param به element در حال بررسی، دسترسی وجود دارد. اما اینجا کاربردی ندارد، چون مخفی است (تصویر اول). یعنی focus بر روی آن، یا تغییر CSS آن قابل مشاهده نخواهد بود. اما داخل همین رویداد گردان می‌توان نوشت:
$(".froala-element").focus();
$(".froala-element").css({"border-color": "red"});
نظرات مطالب
فعال سازی قسمت ارسال فایل و تصویر ویرایشگر آنلاین RedActor در ASP.NET MVC
خیر. احتمالا به این علت که آنچنان مرسوم نیست از چندین قلم در وب استفاده شود، منهای CSS اصلی سایت و تعریف قلم‌های اصلی برای هدرها و امثال آن. به علاوه قلم متن نمایش داده شده در صفحات باید تابع CSS سایت باشد نه ادیتور آن.
ولی در کل می‌تونید براش افزونه بنویسید تا اینکار را انجام دهد.