C# Geeks (.NET)

🔗Chain Of Responsibility

🔥 نکته حیاتی در Hangfire: جنگ با ساعت و تایم‌زون‌ها! ⏰🌍

اگر تا حالا براتون پیش اومده که جابی رو برای ساعت ۸ صبح تنظیم کردید ولی ساعت ۱۱:۳۰ اجرا شده، این پست برای شماست!

⚠️ ماجرا چیه؟
هنگ‌فایر (Hangfire) به صورت پیش‌فرض (Default) همه جاب‌های تکرارشونده (Recurring Jobs) رو بر مبنای ساعت UTC اجرا می‌کنه. یعنی اگر تنظیمات تایم‌زون رو بهش ندید، باید اختلاف ساعت ایران با گرینویچ رو دستی حساب کنید که اصلا جالب نیست.

حالا اگر بخوایم بگیم "به وقت ایران اجرا شو"، با یه چالش جدید روبرو می‌شیم:

🔸 ویندوز می‌گه: "Iran Standard Time"

🔸 لینوکس/داکر می‌گه: "Asia/Tehran"
اگر این تفاوت هندل نشه، روی سرور لینوکسی یا کانتینر داکر به خطای TimeZoneNotFoundException می‌خورید! 🤯

✅ راه حل نهایی (Cross-Platform):
با این تیکه کد، هم مشکل UTC رو حل کنید و هم کدی بنویسید که روی ویندوز، لینوکس و مک بدون تغییر کار کنه:

using System.Runtime.InteropServices;

// 1. تشخیص خودکار شناسه تایم‌زون بر اساس سیستم‌عامل
// Windows -> "Iran Standard Time"
// Linux/Docker -> "Asia/Tehran"
var tehranId = RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
  ? "Iran Standard Time"
  : "Asia/Tehran";

// 2. تنظیم ساعت به وقت ایران
RecurringJob.AddOrUpdate(
    type.FullName, 
    () => job.ExecuteAsync(), 
    attribute.CronExpression, 
    new RecurringJobOptions
    {
        // خداحافظ UTC، سلام تهران! 👋
        TimeZone = TimeZoneInfo.FindSystemTimeZoneById(tehranId)
    }
);

💡 با این روش، دیگه نگران جلو/عقب کشیدن ساعت‌ها یا تفاوت محیط لوکال و سرور نباشید.

🔗 بحث مرتبط در کامیونیتی هنگ‌فایر:
https://discuss.hangfire.io/t/need-local-time-instead-of-utc/279/7


🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥

#CSharp #DotNet #Hangfire #Docker #Backend #TimeZone #Tips

وصل کردن همه‌چیز به هم (Wiring It All Together) 🔌

در نهایت باید این سرویس‌ها را داخل DI container ثبت کنیم:

builder.Services.AddSingleton<IConnectionMultiplexer>(sp =>
    ConnectionMultiplexer.Connect("<REDIS_CONNECTION_STRING>"));

// Register HybridCache (defaults generally work fine for L1)
builder.Services.AddHybridCache();

// Register our invalidation services
builder.Services.AddSingleton<ICacheInvalidator, RedisCacheInvalidator>();
builder.Services.AddHostedService<CacheInvalidationService>();

حالا وقتی Node A متد
InvalidateAsync("user:123")
را صدا بزند، Redis این پیام را به Node B، Node C و بقیه می‌فرستد. همه‌ی آن‌ها متد
hybridCache.RemoveAsync("user:123")
را اجرا می‌کنند و تضمین می‌شود که درخواست بعدی داده‌ی تازه را از منبع اصلی (یا از L2 مشترک) بگیرد. 🔄✨

یک راه بهتر: FusionCache 🧠🔥

اگر ساختن backplane اختصاصی حس «reinventing the wheel» به شما می‌دهد، بهتر است نگاهی به FusionCache بیندازید.

ءFusionCache یک کتابخانه‌ی بالغ و battle-tested است که سال‌هاست دقیقاً همین مشکل را حل کرده. این کتابخانه یک backplane داخلی دارد که به صورت خودکار Pub/Sub را مدیریت می‌کند.

حتی بهتر از آن: FusionCache اخیراً یک پیاده‌سازی از abstract class مربوط به HybridCache اضافه کرده است. یعنی می‌توانید تقریباً بدون تغییر زیاد در کد فعلی، آن را جایگزین کنید. 😍

// Using FusionCache's implementation of HybridCache
builder.Services.AddFusionCache()
    .WithBackplane(
        new RedisBackplane(new RedisBackplaneOptions { Configuration = "<REDIS_CONNECTION_STRING>" }))
    .AsHybridCache();

جمع‌بندی 📝

ءHybridCache یک اضافه‌شدن بسیار قدرتمند به اکوسیستم NET. است و عملاً مزایای IMemoryCache و IDistributedCache را با هم ترکیب می‌کند. اما در سناریوهای multi-node که نیاز به consistency بالا دارند، هنوز به یک مکانیزم برای همگام‌سازی کش‌های محلی نیاز دارید.

ءRedis Pub/Sub یک راه‌حل سبک و مؤثر برای این مشکل ارائه می‌دهد. 📡

با پیاده‌سازی یک «bus» ساده برای پیام‌های invalidation، به بهترین حالت ممکن می‌رسید:
هم performance فوق‌العاده‌ی کش محلی را دارید، هم consistency سیستم توزیع‌شده را. ⚡️🌍

موفق باشید😉🚀

🔖هشتگ‌ها:
#DotNet #HybridCache #Redis #DistributedSystems #Caching #SystemDesign #FusionCache

پیاده‌سازی راه‌حل ⚙️

ما به کتابخانه‌ی StackExchange.Redis برای مدیریت پیام‌رسانی نیاز داریم.

بیایید با تعریف یک سرویس ساده برای انتشار (publishing) شروع کنیم. این سرویس مسئول اطلاع دادن به بقیه‌ی سیستم است که یک کلید تغییر کرده است. 🔔

public interface ICacheInvalidator
{
    Task InvalidateAsync(string key, CancellationToken cancellationToken = default);
}

public class RedisCacheInvalidator(
    IConnectionMultiplexer connectionMultiplexer,
    ILogger<RedisCacheInvalidator> logger)
    : ICacheInvalidator
{
    private const RedisChannel Channel = RedisChannel.Literal("cache-invalidation");

    public async Task InvalidateAsync(string key, CancellationToken cancellationToken = default)
    {
        var subscriber = connectionMultiplexer.GetSubscriber();

        await subscriber.PublishAsync(Channel, new RedisValue(key));

        logger.LogInformation("Published invalidation for key: {Key}", key);
    }
}

حالا هر زمان که یک entity را در Command Handler یا Service آپدیت می‌کنید، کافی است متد ICacheInvalidator.InvalidateAsync را صدا بزنید. 🚀

public class UpdateUserProfileHandler(
    AppDbContext dbContext,
    ICacheInvalidator cacheInvalidator,
    ILogger<UpdateUserProfileHandler> logger)
{
    public async Task Handle(int userId, string newName, CancellationToken ct)
    {
        // 1. Update the database
        var user = await dbContext.Users.FindAsync([userId], ct);
        if (user is null)
        {
             return;
        }

        user.Name = newName;
        await dbContext.SaveChangesAsync(ct);

        // 2. Invalidate the cache (Distributed)
        var cacheKey = $"user:{userId}";
        await cacheInvalidator.InvalidateAsync(cacheKey, ct);

        logger.LogInformation("Updated user and invalidated cache for {UserId}", userId);
    }
}

Background Listener 🧵

در مرحله‌ی بعد، به یک background service نیاز داریم که روی هر نود اجرا شود. این سرویس روی کانال Redis مشترک می‌شود و کلیدها را از HybridCache محلی حذف می‌کند.

یک نکته‌ی سریع درباره‌ی self-publishing:
چون Redis Pub/Sub پیام را برای همه‌ی subscriberها ارسال می‌کند، نودی که خودش پیام invalidation را منتشر کرده هم دوباره همان پیام را دریافت می‌کند. در این پیاده‌سازی، ما دوباره همان کلید را حذف می‌کنیم. این کار تکراری ولی بی‌ضرر است و کد را ساده نگه می‌دارد. 🔁

توجه کنید که ما مستقیماً HybridCache را داخل background service تزریق کرده‌ایم. یک جایگزین این است که از IMemoryCache استفاده کنیم، چون همان L1 cache داخل HybridCache است.

public class CacheInvalidationService(
    IConnectionMultiplexer connectionMultiplexer,
    HybridCache hybridCache,
    ILogger<CacheInvalidationService> logger)
    : BackgroundService
{
    private const RedisChannel Channel = RedisChannel.Literal("cache-invalidation");

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        var subscriber = connectionMultiplexer.GetSubscriber();

        await subscriber.SubscribeAsync(Channel, (channel, value) =>
        {
            string key = value.ToString();

            logger.LogInformation("Invalidating local cache for: {Key}", key);

            // This removes the item from the local L1 cache
            var task = hybridCache.RemoveAsync(key, stoppingToken);

            if (!task.IsCompleted)
            {
                task.GetAwaiter().GetResult();
            }
        });
    }
}

چرا فقط مدت زمان کش را کوتاه نکنیم؟ ⏱️🤔

یک راه‌حل «هکی» و رایج برای حل این مشکل این است که مدت زمان کش L1 (TTL) را خیلی کم کنیم. مثلاً تنظیم کنیم که کش محلی هر ۱۰ ثانیه منقضی شود.

در حالی که این کار بازه‌ی ناسازگاری را کمتر می‌کند، اما واقعاً مشکل را حل نمی‌کند؛ فقط آن را پنهان می‌کند. 🎭

این رویکرد دو مشکل جدید ایجاد می‌کند:

1️⃣ افزایش Latency 🚦: حالا اپلیکیشن شما خیلی بیشتر مجبور است به کش توزیع‌شده L2 (مثل Redis) یا حتی دیتابیس درخواست بزند.

2️⃣ از دست رفتن Efficiency 📉: مزیت اصلی کش L1 این است که کلاً از درخواست شبکه جلوگیری می‌کند. اگر داده‌ها خیلی سریع منقضی شوند، برای بخش عمده‌ای از ترافیک، این مزیت performance را از دست می‌دهید.

برای چیزهایی مثل مجوزهای کاربر (user permissions)، feature flagها یا قیمت‌گذاری، «تقریباً درست» معمولاً کافی نیست. شما به سازگاری فوری (immediate consistency) نیاز دارید. ⚡️

راه‌حل: Redis Pub/Sub به‌عنوان Backplane 📡🧩

برای حل این مشکل، به یک backplane نیاز داریم.Backplane یک کانال ارتباطی است که تمام نودهای اپلیکیشن ما را به هم وصل می‌کند.

وقتی یک cache entry روی یک نود حذف یا به‌روزرسانی می‌شود، یک پیام روی backplane منتشر می‌کنیم. تمام نودهای دیگر مشترک (subscribe) این کانال هستند و به محض دریافت پیام، کلید مربوطه را از کش محلی خودشان حذف می‌کنند. 🗑

ءRedis از قبل انتخاب محبوبی برای کش L2 است، بنابراین کاملاً منطقی است که از قابلیت Pub/Sub آن برای این مکانیزم سیگنال‌دهی استفاده کنیم. 🔔

این فرآیند به این شکل کار می‌کند:

🔸️ءPublisher 🧑‍💻: نودی که داده را تغییر می‌دهد، یک پیام invalidation شامل cache key منتشر می‌کند.

🔹️ءSubscriber 👂: تمام نودها روی این کانال گوش می‌دهند.

🔸️ءAction ⚙️: وقتی پیام می‌رسد، متد HybridCache.RemoveAsync(key) را صدا می‌زنند.

حل مشکل Invalidating کش توزیع‌شده با Redis و HybridCache 🧠🚀

سیستم‌های توزیع‌شده برای مقیاس‌پذیری عالی هستند، اما یک کلاس کاملاً جدید از مشکلات را هم معرفی می‌کنند. یکی از سخت‌ترین این مشکلات، cache invalidation است. ⚠️

در NET 9.، مایکروسافت کتابخانه‌ای به نام HybridCache معرفی کرد تا فرآیند caching را ساده‌تر کند. این یک کتابخانه فوق‌العاده است که سرعت کش در حافظه (L1) را با پایداری کش توزیع‌شده (L2) مثل Redis ترکیب می‌کند. همچنین به‌صورت پیش‌فرض از محافظت در برابر cache stampede پشتیبانی می‌کند. 🛡

اما یک نکته وجود دارد. ❗️

وقتی چندین instance از اپلیکیشن خود را اجرا می‌کنید، HybridCache به‌صورت خودکار کش محلی L1 را بین تمام نودها همگام‌سازی نمی‌کند. اگر داده‌ای روی Node A به‌روزرسانی شود، Node B همچنان داده‌ی قدیمی را از کش درون‌حافظه‌ای خودش برمی‌گرداند تا زمانی که آن entry منقضی شود. ⏳

در حالی که HybridCache یک گام بزرگ رو به جلو است، نبود یک backplane داخلی برای invalidation یک محدودیت شناخته‌شده است. در واقع، یک بحث فعال در ریپازیتوری GitHub مربوط به dotnet/extensions وجود دارد که دقیقاً همین feature request را دنبال می‌کند. تا زمانی که این قابلیت ارائه شود، مجبوریم خودمان راه‌حل بسازیم. 🛠

در این خبرنامه بررسی می‌کنیم:

• معضل کش توزیع‌شده 🌍
• چرا HybridCache به‌تنهایی این مشکل را حل نمی‌کند 🤔
• استفاده از Redis Pub/Sub به‌عنوان backplane 📡
• پیاده‌سازی invalidation بلادرنگ کش ⚡️

بیایید شروع کنیم. 👇

معضل کش توزیع‌شده (The Distributed Caching Dilemma)

بیایید یک سناریوی معمول در محیط production را تصور کنیم. شما یک API دارید که روی چندین سرور (یا pod) پشت یک load balancer اجرا می‌شود. ⚙️

برای بهبود performance، از caching استفاده می‌کنید. سرعت حافظه محلی را می‌خواهید، پس از HybridCache استفاده می‌کنید. 🚀

سناریوی شکست به این صورت است:

• کاربر A پروفایل خود را روی Server 1 به‌روزرسانی می‌کند. 👤

• ءServer 1 دیتابیس را آپدیت می‌کند و کش محلی خودش را پاک می‌کند. 🗑

• کاربر A (یا کاربر B) به Server 2 درخواست می‌زند. 🔁

• ءServer 2 هنوز داده‌ی قدیمی پروفایل را در HybridCache محلی خودش نگه داشته است. 🧊

• کاربر اطلاعات قدیمی را می‌بیند، چون کش محلی invalidate نشده است. 😕

یک نکته‌ی ظریف در EF Core که می‌تونه برنامه‌تون رو کرش بده ⚠️

اگه با EF Core کار کرده باشید، احتمالاً خیلی وقت‌ها برای کلید اصلی این مدلو انتخاب کردید:

builder.Property(x => x.Id)
       .ValueGeneratedOnAdd();

یعنی مقدار Id توسط دیتابیس (مثلاً SQL Server با IDENTITY) ساخته می‌شه.

تا اینجا همه‌چیز کاملاً استاندارده.
اما اینجا یه دام خیلی ظریف وجود داره 👇

سناریوی مشکل‌دار 🧨

فرض کنید در Domain Layer اومدید برای Id یک ولیدیشن گذاشتید:

public class Order
{
    public int Id { get; private set; }

    public Order()
    {
        if (Id <= 0)
            throw new DomainException("Id must be positive");
    }
}

یا حتی در setter:

set
{
    if (value <= 0)
        throw new DomainException();
    _id = value;
}

در ظاهر کاملاً منطقیه:
«شناسه نباید منفی یا صفر باشه» ✅

ولی برنامه‌تون موقع ()SaveChanges کرش می‌کنه! 💥

دلیل واقعی چیـه؟ (رفتار داخلی EF) 🧠

ءEF Core وقتی یک entity جدید رو Add می‌کنه، هنوز هیچ Id واقعی‌ای نداره.
اما برای اینکه بتونه Change Tracking و Relationship ها رو مدیریت کنه، مجبور می‌شه:
"یک Temporary Key براش بسازه."
و این کلید موقت معمولاً:
• عدد منفیه
• فقط داخل حافظه است
• هرگز وارد دیتابیس نمی‌شه

مثلاً:

Order.Id = -2147482647

✨️ءEF از این مقدار استفاده می‌کنه تا:

• ءFKها رو ست کنه
• ءGraph از entityها رو track کنه
• بعد از Insert، مقدار واقعی رو جایگزین کنه

پس چرا برنامه کرش می‌کنه؟ 💣

چون شما در Domain گفتید:
«ءId منفی غیرقانونیه»

ولی EF می‌گه:
«من مجبورم موقتاً منفی بذارم»

و این دو تا با هم invariant همدیگه رو می‌شکنن.

💡نتیجه:

EF مقدار منفی ست می‌کنه →
Domain validation تریگر می‌شه →
Exception →
Crash 😬

این دقیقاً چه درسی به ما می‌ده؟ 🎯

این یه مثال عالیه از این اصل مهم در DDD:

ءDomain نباید به مکانیزم‌های زیرساختی وابسته باشه

و مهم‌تر:
ءId دیتابیس نباید identity دامنه باشد

راه‌حل‌های درست (Professional Approaches) 🧩

1️⃣ اصلاً روی Id دیتابیس ولیدیشن نذار 🚫

بهترین و رایج‌ترین راه:

// No validation on Id at all
public int Id { get; private set; }

چون:
ءDomain نباید به persistence concern حساس باشه
ءId دیتابیس یک detail فنیه، نه business rule

2️⃣ از Surrogate Key در دامنه استفاده نکن 🔑

به جای این:

Order.Id (int identity)

از identityهایی استفاده کن که در Domain تولید می‌شوند
(Guid/Ulid/ValueObject)

یعنی:
ءId دامنه = چیزی که خودت می‌سازی
ءId دیتابیس = فقط برای storage

3️⃣ اگر خیلی وسواسی هستی: Validation رو بعد از Persist انجام بده

مثلاً:

public bool IsPersisted => Id > 0;

ولی این عملاً یعنی پذیرفتی که:
ءId قبل از persistence معتبر نیست
که باز هم یعنی validation روش منطقی نیست.

نکته‌ی خیلی عمیق معماری 🧠🔥

این مشکل یه نمونه‌ی کلاسیک از تضاد بین این دو دنیاست:
Domain World ORM World
Invariants Temporary keys
Business meaning Technical identity
Stability Internal mutations

و دقیقاً نشون می‌ده چرا:
نباید مفاهیم دیتابیس رو مستقیم وارد دامنه کنیم

جمع‌بندی طلایی 🏆

اگر از ValueGeneratedOnAdd یا IDENTITY استفاده می‌کنید:

❌ هرگز روی Id در دامنه validation نگذارید
❌ هرگز Id دیتابیس رو business concept در نظر نگیرید

در عوض:

✅ دامنه = با مفاهیم بیزینسی (Value Objects)
✅ دیتابیس = فقط ابزار ذخیره‌سازی

و این جمله رو همیشه یادت باشه:

ءTemporary keys در EF یک persistence concern هستند،
و نباید وارد invariants دامنه شوند.

این دقیقاً همون جاییه که مهندسی نرم‌افزار از «کدنویسی» جدا می‌شه 🚀

🔖هشتگ‌ها:
#EFCore #DDD #CleanArchitecture #ORM #DomainModel #SoftwareEngineering #DotNet

🧩 7️⃣ الگوی Sidecar (Sidecar Pattern) (بخش هفتم)

ءSidecar Pattern یک کامپوننت کمکی را در کنار container اصلی اپلیکیشن شما deploy می‌کند که وظیفه ارائه قابلیت‌های پشتیبان مانند logging، monitoring، configuration یا networking را بر عهده دارد. 🛠

ءSidecar در همان محیط اجرایی اپلیکیشن اصلی اجرا می‌شود و lifecycle مشترکی با آن دارد. این موضوع باعث می‌شود بتوان بدون تغییر کد اپلیکیشن، قابلیت‌های جدیدی به آن اضافه کرد. 🔌

⚙️ نحوه کار (How it works):

یک sidecar container در کنار container اصلی اپلیکیشن و در همان container یا host اجرا می‌شود 🧱

هر دو container از یک network namespace مشترک استفاده می‌کنند و می‌توانند از طریق localhost با هم ارتباط برقرار کنند 🌐

ءSidecar می‌تواند ترافیک ورودی و خروجی را intercept کند و مسئول cross-cutting concern‌هایی مانند logging، جمع‌آوری metrics یا قابلیت‌های service mesh باشد 📊

ارتباط بین اپلیکیشن و sidecar از طریق local network calls انجام می‌شود 🔄

قابلیت‌های sidecar می‌توانند مستقل از اپلیکیشن به‌روزرسانی شوند، بدون نیاز به تغییر یا redeploy کد اصلی ♻️

امکان اتصال چند sidecar به یک اپلیکیشن واحد برای اهداف مختلف وجود دارد 🧩🧩

✅ مزایا (Benefits):

جداسازی دغدغه‌های زیرساختی از کد اپلیکیشن و تمرکز کد بر business logic 🧠

پشتیبانی از polyglot architecture، چون sidecar مستقل از زبان یا framework اپلیکیشن عمل می‌کند 🌍

ساده‌سازی توسعه اپلیکیشن با استفاده از کامپوننت‌های زیرساختی قابل استفاده مجدد ♻️

امکان به‌روزرسانی مستقل قابلیت‌های زیرساختی بدون redeploy اپلیکیشن 🚀

کاهش code duplication بین سرویس‌ها با متمرکز کردن قابلیت‌های مشترک در sidecar 📦

⚠️ معایب (Drawbacks):

افزایش مصرف منابع، چون هر instance اپلیکیشن یک یا چند sidecar اضافی اجرا می‌کند 💾

افزایش پیچیدگی در پیکربندی deployment و orchestration 🧩

احتمال افزایش latency به دلیل hopهای شبکه‌ای اضافی بین اپلیکیشن و sidecar ⏱️

🎯 موارد استفاده (Use cases):

• پیاده‌سازی Service Mesh برای مدیریت ترافیک، امنیت و observability 🔐📈

• ءCentralized logging که در آن sidecar لاگ‌های اپلیکیشن را جمع‌آوری و به سیستم‌های logging ارسال می‌کند 📝

• ءConfiguration management که sidecar پیکربندی‌ها را به‌صورت داینامیک دریافت و به‌روزرسانی می‌کند ⚙️

• یکپارچه‌سازی Event-driven که در آن sidecar مدیریت messaging را از طریق queueهای قابل تعویض (مثل Kafka، RabbitMQ، Azure Service Bus) انجام می‌دهد و امکان تغییر آن‌ها بدون دست زدن به کد اپلیکیشن را فراهم می‌کند (برای مثال با استفاده از Dapr) 🔄

7️⃣ Sidecar Pattern

یه زمانی فکر می‌کردم هرچی async/await تو کدم بیشتر باشه، سیستم مثل مووووشک کار میکنه
یعنی کد رو باز می‌کردی، همه‌جا async، همه‌جا await…
با خودم می‌گفتم: «این دیگه تهشه، این سیستم موشکه.»

بعد سیستم رفت زیر بار…
موشک بوووود ولی همون اول ترکید.

همه‌چی ظاهراً درست بود.
دیدم CPU داره کارشو میکنه، رم هم داشت نفس می‌کشید، لاگ‌ها هم چیز خاصی نمی‌گفتن.
ولی response time داشت زیاد میشد، کاربرها غر می‌زدن، منم داشتم به مانیتور زل می‌زدم که «مگه async نبود؟»

اونجا بود که فهمیدم async قرار نیست بیاد پیشونیتو ماچ کنه و بگه تو نگران نباش همه چی با من.
درواقع async فقط می‌گه: «داداش من منتظرم، اون Thread بیصاحبو ول کن بره یه کار دیگه بکنه.»

ولی مشکل از جایی شروع می‌شه که وسط این asyncهای خوشگیلی موووشگیل،
یه کار CPU-bound بندازی.
یا بدتر…
یه .Result یا .Wait بزنی و بگی: «ستون وایسا کارت دارم.»

اینجاست که Thread Pool میاد بیرون میگه یه لیوان آب به من بده ناموسن

میبینی Threadها یکی‌یکی مفقود الاثر میشن
تمام Requestهای جدید می‌رسن، می‌بینن جا نیست، چهار زانو میشینن دم در سرور.
سیستم از بیرون مثل بنز جی کلاس، از تو شاهین اتومات.

بدترین قسمتش چیه؟
هیچ اروری نمی‌بینی.
نه exception، نه crash، نه هیچی.
فقط کاربره که هر ۵ ثانیه یه بار رفرش می‌زنه و مرده و زندتو مورد دعای خیر قرار میده.

اونجا بود که فهمیدم async بودن به معنی سریع بودن نیست.

اگر منتظر دیتابیس، شبکه یا دیسکی، async عالیه.
اگر داری CPU رو به خاک میدی، async فقط یه اسم قشنگه روش.
و اگر این دوتا رو قاطی کنی، Thread Pool که دیگه واویلا.

از اون روز به بعد، قبل از اینکه async بنویسم، از خودم می‌پرسم:
الان واقعاً منتظرم؟
یا فقط دارم خودمو گول می‌زنم؟

خیلی وقتا مشکل performance این نیست که کدت بده.
مشکل اینه که فکر می‌کنی async یعنی «همه چی حل شد».

نه.
درواقع async ابزار حرفه‌ایه،
ولی اگه نفهمی چی دستته، خیلی سریع تبدیل می‌شه به سلاح کشتار جمعی.

ما ۰.۱ ثانیه توی اجرا صرفه‌جویی کردیم، ولی ۳ روز از عمر تیم رو به باد دادیم!

چند وقت پیش توی پروژه‌ای بودم که یکی از بچه‌ها وسواس عجیبی روی سرعت داشت. ما یه کد تر‌ و تمیز داشتیم که کار میکرد. ولی این همکارم گفتش که: "نه، این تابعی که نوشتی کنده! بذار پرفورمنسش رو ببرم بالا."

شروع کرد به تغییرات عجیب به بهانه‌ی اینکه فراخوانی توابع سربار (Overhead) داره، توابعِ کوچیک و خوانا رو حذف کرد و همه رو ریخت توی یه تابعِ. شرط‌های if/else شفاف رو تبدیل کرد به یک خط محاسبه‌ی ریاضی پیچیده تا CPU کمتری مصرف بشه.

ما اولش هیجان‌زده بودیم و میگفتیم که دمت گرم! الان چون کد کوتاه‌تر شده و تابع کمتر صدا زده میشه، حتما درخواستا خیلی سریع پردازش میشن.

نتیجه؟ کاربر نهایی اصلا متوجه اون سرعت ناچیز نشد (چون گلوگاه اصلا اونجا نبود). اما چند وقت بعد، وقتی بیزینس یه تغییر کوچیک خواست، ما فلج شدیم.

کدی که قبلا توی ۱۰ دقیقه ادیت میشد، حالا شده بود یه میدون مین. هیچ‌کس نمیفهمید اون خط طولانی ریاضی دقیقا داره چی‌کار میکنه. ما خوانایی رو قربانی یه سرعت توهمی کرده بودیم.

اینجا بود که یاد جمله‌ی معروف دونالد کنوث افتادم: "بهینه‌سازی زودهنگام (Premature Optimization)، ریشه‌ی تمام دردسرهاست."

ما داشتیم دقیقا همین مصیبت رو سر خودمون میاوردیم و قانونِ طلایی Uncle Bob رو فراموش کرده بودیم:

قانون ۱۰ به ۱: ما ۱۰ برابر زمانی که کد مینویسیم، صرف خوندن کد میکنیم. اون کدی که دوستمون زد، شاید نوشتن‌ش ۱ ساعت طول کشید، ولی خوندن و دیباگ کردنش ۱۰ ساعت از وقت کل تیم رو گرفت. هر خط کدی که به بهانه‌ی Performance ناخوانا میشه، داره هزینه‌ی نگهداری رو تصاعدی میبره بالا.

ما یاد گرفتیم بهینه‌سازی واقعی این نیست که کد رو فشرده کنی. بهینه‌سازی واقعی اینه که کدی بنویسی که نفر بعدی (یا خود ۶ ماه بعدت) بتونه راحت بخونه و توسعه‌ش بده.

🔄 الگوی (Saga Pattern) Saga (بخش ششم)

الگوی Saga Pattern برای مدیریت distributed transactions در چندین سرویس استفاده می‌شود. این الگو با شکستن یک تراکنش توزیع‌شده به دنباله‌ای از local transactions کار می‌کند.
هر local transaction فقط داده‌های همان سرویس را تغییر می‌دهد و سپس یک event یا message منتشر می‌کند تا مرحله بعدی شروع شود 📣

اگر در هر مرحله خطایی رخ دهد، compensating transactions اجرا می‌شوند تا تغییرات مراحل قبلی را خنثی کنند و data consistency بین سرویس‌ها حفظ شود 🔁

⚙️ ءSaga چگونه کار می‌کند؟

1️⃣ یک Saga زمانی شروع می‌شود که یک فرآیند تجاری نیاز به تغییر داده در چند سرویس داشته باشد
2️⃣ ءSaga coordinator تراکنش توزیع‌شده را به چند local transaction (یکی برای هر سرویس) تقسیم می‌کند
3️⃣ هر سرویس local transaction خودش را اجرا می‌کند و یک event مبنی بر موفقیت یا شکست منتشر می‌کند
4️⃣ ءCoordinator به این eventها گوش می‌دهد و مرحله بعدی را فعال می‌کند 👂
5️⃣ اگر همه مراحل با موفقیت انجام شوند، Saga پایان می‌یابد و تراکنش کامل تلقی می‌شود ✅
6️⃣ اگر هر مرحله‌ای شکست بخورد، compensating transactions به‌ترتیب معکوس اجرا می‌شوند تا تغییرات قبلی undo شوند ♻️
7️⃣ دو رویکرد اصلی برای پیاده‌سازی وجود دارد:

ءChoreography: سرویس‌ها از طریق eventها با هم هماهنگ می‌شوند 🎭

ءOrchestration: یک coordinator مرکزی جریان کار را مدیریت می‌کند 🎼

🌟 مزایا (Benefits)

✔️ امکان اجرای distributed transactions در معماری microservices بدون نیاز به distributed locks یا two-phase commit
✔️ حفظ سازگاری داده‌ها با استفاده از compensating transactions به‌جای rollbackهای سنگین
✔️ مناسب برای long-running business processes با تحمل خطای بالاتر 🛡
✔️ مقیاس‌پذیری بهتر، چون هر سرویس فقط مسئول local transaction خودش است 📈

⚠️ معایب (Drawbacks)

❌ پیچیدگی بالا در طراحی و پیاده‌سازی compensating transaction برای هر مرحله
❌ ایجاد eventual consistency که ممکن است باعث وضعیت‌های موقتاً ناسازگار برای کاربر شود ⏳
❌ سخت‌تر شدن debugging و monitoring چون تراکنش‌ها در چند سرویس و در طول زمان پخش شده‌اند
❌ سناریوهای پیچیده‌ی مدیریت خطا، مخصوصاً زمانی که خود compensating transaction هم شکست بخورد

🎯 موارد استفاده (Use cases)

📌 ءworkflowهای چندمرحله‌ای در سیستم‌های enterprise که هر مرحله توسط یک سرویس جداگانه انجام می‌شود
📌 هر فرآیند تجاری که نیاز به تغییر هماهنگ داده‌ها در چند microservice دارد، بدون استفاده از distributed lock

✨ جمع‌بندی:

ءSaga Pattern یک راه‌حل کلیدی برای مدیریت تراکنش‌های پیچیده در معماری‌های توزیع‌شده است. اگرچه پیاده‌سازی آن ساده نیست، اما برای سیستم‌های microservice-scale تقریباً اجتناب‌ناپذیر است.

6️⃣ Saga Pattern

پند روز جمعه: 🔥 یه نظر متفاوت درباره «دوباره اختراع کردن چرخ»:

شاید… واقعاً اتلاف وقتِ خوبی باشه ⏳😉

ادعای رایج منطقیه؛ مخصوصاً وقتی هدفت، تحویل سریع ارزش به کاربره 🚀
اما بیاید از یه زاویه دیگه نگاه کنیم 👀

برای یادگیری، می‌تونه فوق‌العاده باشه.
به‌خصوص وقتی اول مسیرت هستی 🌱

وقتی چیزی رو از صفر می‌سازی، حتی اگه هزار بار قبلاً ساخته شده باشه، مجبور می‌شی مفاهیم زیرساختی رو عمیقاً بفهمی 🧠

✨ چه اتفاقی می‌افته؟

• با تصمیم‌های طراحی واقعی درگیر می‌شی 🧩

• با چالش‌هایی روبه‌رو می‌شی که اصلاً انتظارش رو نداشتی ⚠️

• و مهم‌تر از همه، واقعاً می‌فهمی چیزها «چطور» کار می‌کنن 🔍

🍳 بهش این‌طوری فکر کن:

هیچ‌کس فقط با خوندن کتاب آشپزی، سرآشپز حرفه‌ای نمی‌شه.

باید دست‌هات رو توی آشپزخونه کثیف کنی! 👨‍🍳🔥

همین موضوع دقیقاً درباره مهندسی نرم‌افزار هم صدق می‌کنه 💻
اگه هدفت یادگیری عمیق‌تر و درک واقعی مفاهیمه، چرا خودت نسازی؟

✅ بهترین روش‌ها برای سازمان‌دهی کدهای Extension در C# 14 🧩✨
🗂 چطور Extension Blockها را سازمان‌دهی کنیم؟

وقتی از کلیدواژه extension استفاده می‌کنید، می‌توانید چندین extension member که روی یک type اعمال می‌شوند را داخل یک extension block قرار دهید.
این کار باعث کاهش تکرار 🔁 و کنار هم ماندن کدهای مرتبط می‌شود 🧠

همچنین می‌توانید در یک static class چند extension block داشته باشید؛
مثلاً برای receiverهای متفاوت یا generic type parameterهای مختلف 👇

public static class CollectionExtensions
{
    extension<T>(IEnumerable<T> source)
    {
        public bool IsEmpty => !source.Any();

        public bool HasItems => source.Any();

        public int Count => source.Count();
    }

    extension(IEnumerable<string> source)
    {
        public string JoinWithComma() => string.Join(", ", source);
        public IEnumerable<string> NonEmpty() => source.Where(s => !string.IsNullOrEmpty(s));
    }

    extension<T>(List<T> list)
    {
        public void AddIfNotExists(T item)
        {
            if (!list.Contains(item))
            {
                list.Add(item);
            }
        }
    }
}

🔄 ترکیب syntax قدیمی و جدید

می‌توانید syntax قدیمی (this) و syntax جدید (extension) را در یک کلاس با هم استفاده کنید 👍

public static class StringExtensions
{
    // Traditional syntax
    public static bool IsEmail(this string value)
    {
        return value.Contains("@");
    }
    
    // New syntax
    extension(string value)
    {
        public bool IsUrl => 
            Uri.TryCreate(value, UriKind.Absolute, out _);
        
        public string ToTitleCase() =>
            CultureInfo.CurrentCulture.TextInfo.ToTitleCase(value.ToLower());
    }
}

🚫 از ساختن Extension Classهای غول‌پیکر اجتناب کنید

یک کلاس بزرگ با extension برای ده‌ها type مختلف، به‌مرور تبدیل به کابوس نگهداری می‌شود 😵‍💫
بهتر است extensionها را بر اساس domain یا کاربرد گروه‌بندی کنید 👇

public static class ProductExtensions
{
    extension(Product product)
    {
        // Product-specific extensions
    }
}

public static class ValidationExtensions
{
    extension(Order value)
    {
        // Validation logic
    }
    extension(OrderItem value)
    {
        // Validation logic
    }
}

📌 انتخاب ساختار مناسب کاملاً به نیاز پروژه بستگی دارد:
یا یک static class برای هر type
یا گروه‌بندی بر اساس functionality

🧮 برای مقادیر محاسباتی از Extension Property استفاده کنید

اگر extensionای دارید که پارامتری نمی‌گیرد و فقط یک مقدار برمی‌گرداند،
بهتر است به‌جای method، آن را property تعریف کنید 👌

extension(Order order)
{
    public decimal TotalPrice => 
        order.Items.Sum(item => item.Price * item.Quantity);
}

✍️ نام‌گذاری معنادار انتخاب کنید

ءExtension propertyها باید طوری خوانده شوند که انگار عضو اصلی type هستند.
از نام‌هایی که «داد می‌زنند extension هستند» پرهیز کنید ❌

// Good
public bool IsEmpty => !source.Any();
public string DisplayPrice => price.ToString("C");

📚 ءExtensionها را مستند کنید

در پروژه‌های بزرگ، حتماً از XML Comment استفاده کنید تا بقیه اعضای تیم دقیقاً بدانند این extension چه کاری انجام می‌دهد 🧑‍💻📖

extension(Product product)
{
    /// <summary>
    /// Gets whether the product is currently available for purchase.
    /// </summary>
    /// <remarks>
    /// A product is available if its stock quantity is greater than zero.
    /// </remarks>
    public bool IsAvailable => product.StockQuantity > 0;
}

🧾 جمع‌بندی

کلیدواژه extension در C# 14 اختیاری است ✅
تمام extension methodهای قبلی شما بدون هیچ تغییری همچنان کار می‌کنند.
اما زمانی که:
می‌خواهید property اضافه کنید 🧩
ءmemberهای static داشته باشید 🏗
یا کدهای مرتبط را تمیزتر و یک‌جا نگه دارید 🧹
ءsyntax جدید تجربه توسعه‌دهنده بسیار بهتری فراهم می‌کند ✨

اگر با C# 14 و NET 10. کار می‌کنید، حتماً extension propertyها را در پروژه‌هایتان امتحان کنید.
به‌زودی متوجه می‌شوید چقدر جا دارد methodها به property تبدیل شوند و کدها طبیعی‌تر و قابل‌فهم‌تر شوند 🧠💡

امیدوارم این مطلب براتون مفید بوده باشه 🙌
تا مطلب بعدی، موفق باشید 👋

🌍 مثال‌های واقعی از Extension Memberها

در Web APIها، معمولاً نیاز داریم اطلاعاتی از HttpContext استخراج کنیم.
به‌جای تکرار کدهای مشابه، می‌توانیم extension بنویسیم تا کد تمیزتر شود ✨

public static class ApiHttpContextExtensions
{
    extension(HttpContext context)
    {
        public string CorrelationId =>
            context.Request.Headers["X-Correlation-ID"].FirstOrDefault()
                ?? Guid.NewGuid().ToString();

        public string ClientIp =>
            context.Request.Headers["X-Forwarded-For"].FirstOrDefault()
                ?? context.Connection.RemoteIpAddress?.ToString()
                ?? "Unknown";

        public bool IsApiRequest =>
            context.Request.Path.StartsWithSegments("/api");

public string? GetBearerToken()
        {
            var authHeader = context.Request.Headers["Authorization"].FirstOrDefault();
            if (authHeader?.StartsWith("Bearer ") == true)
            {
                return authHeader.Substring("Bearer ".Length).Trim();
            }
            return null;
        }

        public T? GetQueryParameter<T>(string key)
        {
            if (context.Request.Query.TryGetValue(key, out var value))
            {
                try
                {
                    return (T?)Convert.ChangeType(value.ToString(), typeof(T));
                }
                catch
                {
                    return default;
                }
            }
            return default;
        }

        public void AddResponseHeader(string key, string value)
        {
            context.Response.Headers[key] = value;
        }
    }

    extension(HttpContext)
    {
        public static bool IsValidPath(string path) =>
            !string.IsNullOrWhiteSpace(path) && path.StartsWith("/");
    }
}

حالا middleware و controllerها بسیار خواناتر می‌شوند 🧼

public class RequestLoggingMiddleware(
    RequestDelegate next,
    ILogger<RequestLoggingMiddleware> logger)
{
    public async Task InvokeAsync(HttpContext context)
    {
        _logger.LogInformation(
            "Request {Method} {Path} from {ClientIp} with CorrelationId {CorrelationId}",
            context.Request.Method,
            context.Request.Path,
            context.ClientIp,
            context.CorrelationId);
        
        context.AddResponseHeader("X-Correlation-ID", context.CorrelationId);
        
        await _next(context);
    }
}

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    [HttpGet]
    public IActionResult GetOrders(HttpContext httpContext)
    {
        var pageSize = httpContext.GetQueryParameter<int?>("pageSize") ?? 10;
        var pageNumber = httpContext.GetQueryParameter<int?>("page") ?? 1;

        var orders = orderService.GetPaged(pageNumber, pageSize);
        return Ok(orders);
    }
}

📌 نتیجه؟

کد خواناتر 📖، تمیزتر 🧹 و بدون تکرار منطق پیچیده‌ی استخراج header و query parameterها، با defaultهای معقول ✅