سناریوی ثابت: سیستم مدیریت کتابخانه

برای اینکه تفاوت‌ها را در عمل ببینیم، مدل زیر را در نظر بگیرید:

public class Book
{
    public int Id { get; set; }        // کلید اصلی (Primary Key)
    public string Title { get; set; }   // عنوان کتاب
    public string Isbn { get; set; }    // شابک (باید منحصربه‌فرد باشد)
}

هدف ما در تمام مثال‌ها: دسترسی به کتابی با شناسه (Id) شماره ۵ است.

۱. متد Where: فیلترسازِ صبور

_context.Books.Where(x => x.Id == 5)

متد Where پایه‌ای‌ترین ابزار برای پرس‌وجو است. این متد برخلاف بقیه، مستقیماً به شما "داده" نمی‌دهد، بلکه یک "فیلتر" برمی‌گرداند.

• خروجی: یک IQueryable (مجموعه‌ای از اشیاء).

• زمان اجرا: از نوع Deferred Execution است. یعنی تا زمانی که داده را واقعاً لازم نداشته باشید (مثلاً با ToList یا foreach)، هیچ کدی به دیتابیس فرستاده نمی‌شود.

• رفتار: حتی اگر بداند فقط یک رکورد با این مشخصات وجود دارد، باز هم خروجی را به صورت یک "لیست" در نظر می‌گیرد.

• چه زمانی استفاده کنیم؟ وقتی به دنبال لیستی از آیتم‌ها هستید یا می‌خواهید فیلترهای بعدی (مثل مرتب‌سازی) را روی نتیجه اعمال کنید.

۲. متد First یا FirstOrDefault: شکارچیِ عجول

_context.Books.FirstOrDefault(x => x.Id == 5)

این متد به دیتابیس می‌گوید: «جستجو کن و به محض اینکه به اولین رکوردی رسیدی که در شرط صدق می‌کند، آن را بردار و بیاور.»

• خروجی: یک شیء واحد (Book) یا null.

• SQL تولیدی: در پشت صحنه از دستور SELECT TOP(1) استفاده می‌کند.

• تفاوت First و FirstOrDefault: اگر کتابی با Id ۵ وجود نداشته باشد، First یک Exception پرتاب می‌کند که باعث کرش کردن برنامه می‌شود، اما FirstOrDefault مقدار null برمی‌گرداند.

• چه زمانی استفاده کنیم؟ وقتی می‌دانید ممکن است چندین رکورد وجود داشته باشد اما شما فقط "اولین" را می‌خواهید، یا وقتی از منحصربه‌فرد بودن داده مطمئن هستید و سرعت برایتان اولویت است.

۳. متد Single یا SingleOrDefault: سخت‌گیرِ منطقی

_context.Books.SingleOrDefault(x => x.Id == 5)

این متد بسیار حساس است. او فقط به دنبال اولین نمی‌گردد؛ او می‌خواهد مطمئن شود که فقط و فقط یک مورد در کل دیتابیس با این شرط وجود دارد.

• خروجی: یک شیء واحد یا null.

• رفتار خاص: اگر دیتابیس را بگردد و دو یا چند رکورد با شرط شما پیدا کند، استثنا (Exception) پرتاب می‌کند؛ حتی اگر از SingleOrDefault استفاده کرده باشید!

• SQL تولیدی: برخلاف انتظار، این متد معمولاً SELECT TOP(2) می‌زند. چرا؟ چون باید چک کند که آیا مورد دومی هم هست یا خیر تا بتواند صحت "تک بودن" را تایید کند.

• چه زمانی استفاده کنیم؟ وقتی وجودِ بیش از یک رکورد برای شما یک خطای منطقی (Logic Error) محسوب می‌شود (مثل جستجو بر اساس کد ملی یا ISBN).

۴. متد Find: متخصصِ کلید اصلی

_context.Books.Find(5)

متد Find با بقیه متفاوت است چون مستقیماً با معماری داخلی EF Core و Change Tracker در ارتباط است.

• محدودیت: فقط و فقط مقدار کلید اصلی (Primary Key) را می‌پذیرد.

• هوشمندی: قبل از اینکه سراغ دیتابیس برود، حافظه (Context) را چک می‌کند. اگر در همان Request، قبلاً این کتاب را لود کرده باشید، بدون هیچ تماسی با دیتابیس، همان نسخه موجود در حافظه را به شما می‌دهد.

• SQL تولیدی: اگر داده در حافظه نباشد، یک کوئری ساده بر اساس ID می‌زند.

• چه زمانی استفاده کنیم؟ بهترین و بهینه‌ترین انتخاب برای پیدا کردن یک رکورد بر اساس ID.

مثالی از متد Find:

۱. حالت اول: داده در حافظه موجود است (Cache Hit)

در این سناریو، فرض کنید در ابتدای کد یک بار کتاب را به دلیلی لود کرده‌اید.

// گام ۱: کتاب شماره ۵ را با FirstOrDefault می‌گیریم.
// در این لحظه یک دستور SQL به دیتابیس زده می‌شود.
var book1 = _context.Books.FirstOrDefault(b => b.Id == 5);

// ... کارهای دیگر ...

// گام ۲: حالا از متد Find استفاده می‌کنیم.
var book2 = _context.Books.Find(5);

// بررسی برابری
Console.WriteLine(object.ReferenceEquals(book1, book2)); // خروجی: True

پشت صحنه چه اتفاقی افتاد؟

• در گام ۱: EF Core یک کوئری به دیتابیس زد، کتاب را آورد و یک کپی از آن را در Change Tracker (حافظه موقت Context) نگه داشت.

• در گام ۲: وقتی Find(5) صدا زده شد، EF Core ابتدا حافظه خودش را چک کرد. دید که «کتاب شماره ۵» همین الان موجود است.

• نتیجه: هیچ دستور SQL جدیدی صادر نشد. متد Find دقیقاً همان شیء موجود در رم را برگرداند. (به همین دلیل ReferenceEquals مقدار True می‌دهد؛ چون هر دو متغیر به یک نقطه از حافظه اشاره دارند).

۲. حالت دوم: داده در حافظه نیست (Cache Miss)

در این سناریو، شما برای اولین بار در این Context سراغ کتاب شماره ۵ می‌روید.

// فرض کنید Context تازه ساخته شده و هیچ داده‌ای در حافظه ندارد.

// گام ۱: بلافاصله از Find استفاده می‌کنیم.
var book = _context.Books.Find(5);

پشت صحنه چه اتفاقی افتاد؟

• در گام ۱: متد Find حافظه داخلی (Local) را چک می‌کند و می‌بیند خالی است.

• در گام ۲: حالا که در حافظه چیزی پیدا نکرد، مجبور است دست به دامن دیتابیس شود.

• نتیجه: یک دستور SQL (مانند SELECT ... WHERE Id = 5) ساخته و به دیتابیس ارسال می‌شود. رکورد لود شده و همزمان در حافظه ذخیره می‌شود تا اگر دوباره Find را صدا زدید، سریع‌تر پاسخ دهد.

چرا این موضوع اهمیت حیاتی دارد؟

تصور کنید در حال نوشتن یک متد برای ثبت سفارش هستید که باید ۱۰ بار وضعیت محصولات مختلف را چک کند.

• اگر از FirstOrDefault استفاده کنید، ۱۰ بار به دیتابیس درخواست می‌فرستید.

• اگر از Find استفاده کنید و محصولات تکراری در سفارش باشند، درخواست‌های تکراری حذف شده و فشار روی دیتابیس به شدت کاهش می‌یابد.

نکته ظریف: اگر داده را در دیتابیس توسط برنامه‌ای دیگر (خارج از این Context) تغییر داده باشید، Find متوجه آن نمی‌شود و همان نسخه قدیمی موجود در رم را به شما می‌دهد. در این مواقع خاص، استفاده از FirstOrDefault بهتر است چون مستقیماً از دیتابیس استعلام می‌گیرد.

حالا بیاید «کینگتویی» همه چیزو بهم بریزیم. 

سناریو را معکوس میکنیم: اول Find و بعد FirstOrDefault

// گام ۱: استفاده از Find برای بار اول
var book1 = _context.Books.Find(5); 

// گام ۲: استفاده از FirstOrDefault
var book2 = _context.Books.FirstOrDefault(b => b.Id == 5);

در گام اول چه اتفاقی می‌افتد؟ (Find)

چون این اولین باری است که در این Request سراغ کتاب شماره ۵ می‌روید، حافظه (Context) خالی است. بنابراین Find مجبور می‌شود یک دستور SQL بسازد و به دیتابیس بفرستد. پس تا اینجا یک تماس با دیتابیس داشتیم. بعد از لود شدن، EF Core این کتاب را در Change Tracker ذخیره می‌کند.

در گام دوم چه اتفاقی می‌افتد؟ (FirstOrDefault)

اینجاست که تفاوت اصلی آشکار می‌شود. متد FirstOrDefault (و کلاً متدهای LINQ) طوری طراحی شده‌اند که همیشه پرس‌وجو را به دیتابیس بفرستند. این متد برخلاف Find قبل از ارسال دستور، حافظه محلی را چک نمی‌کند.

نتیجه: دیتابیس دوباره صدا زده می‌شود! هرچند EF Core بعد از دریافت نتیجه از دیتابیس، متوجه می‌شود که این شیء قبلاً در حافظه بوده و همان نمونه قبلی (book1) را به شما برمی‌گرداند، اما هزینه سفر به دیتابیس (Round-trip) پرداخت شده است.

آیا بهتر است همیشه Find را بعد از First/Single استفاده کنیم؟

خیر، اصلاً! در واقع انجام این کار یک اشتباه رایج (Redundancy) است. دلیلش هم خیلی ساده است:

وقتی شما می‌نویسید: var book = _context.Books.FirstOrDefault(x => x.Id == 5); اگر کتابی پیدا شود، آن کتاب در متغیر book ریخته شده است. حالا چرا باید دوباره خط بعدی بنویسید _context.Books.Find(5)؟ شما همین الان آن شیء را در حافظه (در متغیر book) دارید.

استراتژی درست چیست؟ شما باید بر اساس نیازتان فقط یکی از این دو مسیر را انتخاب کنید:

1. مسیر اول (فقط ID): اگر فقط ID را دارید، مستقیماً و فقط از Find استفاده کنید. (سریع‌ترین حالت)

2. مسیر دوم (شرط خاص): اگر شرط پیچیده‌ای دارید (مثلاً کتابی که هم ID آن ۵ است و هم فعال است)، از FirstOrDefault استفاده کنید و نتیجه را در یک متغیر نگه دارید و همان متغیر را در بقیه کد استفاده کنید.

نتیجه: استفاده پشت‌سرهم از این‌ها یعنی کد اضافه و گیج‌کننده.

مقایسه نهایی در یک جدول کاربردی

تحلیل سناریو: کدام را انتخاب کنیم؟

فرض کنید می‌خواهید کتابی با Id = 5 را ویرایش کنید:

1. استفاده از Where: اشتباه است؛ چون باید روی آن ToList بزنید و بعد از لیست، ایندکس صفر را بردارید. کد شلوغ می‌شود.

2. استفاده از SingleOrDefault: انتخاب "امن" از نظر منطقی است. اگر به هر دلیلی دو کتاب با ID یکسان در دیتابیس باشند (که نباید باشند)، برنامه اینجا متوقف می‌شود و شما می‌فهمید که دیتابیس خراب شده است.

3. استفاده از FirstOrDefault: انتخاب "سریع" است. اگر برایتان مهم نیست که رکورد دومی وجود دارد یا نه، این متد کمترین هزینه را به دیتابیس تحمیل می‌کند.

4. استفاده از Find: انتخاب "حرفه‌ای" است. اگر در کدهای قبلی همین درخواست (Request)، این کتاب را برای نمایش در بخشی دیگر صدا زده باشید، Find هیچ فشاری به دیتابیس نمی‌آورد و از رم استفاده می‌کند.

یک نکته طلایی برای Single و First:

همیشه سعی کنید از نسخه OrDefault استفاده کنید، مگر اینکه ۱۰۰٪ مطمئن باشید عدم وجود آن رکورد، یک خطای بحرانی است که باید برنامه را متوقف کند.