آموزش بیش از ۵۰۰ سوال و جواب مصاحبه Entity Framework سال ۲۰۲۶ - آخرین آپدیت

پوشش جامع حوزه‌های آزمون

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

• مبانی Entity Framework (۲۰٪): مدیریت چرخه حیات DbContext و DbSet، بررسی عمیق مکانیسم‌های داخلی Change Tracking، بهینه‌سازی عبارات LINQ to Entities و تفکیک خط‌لوله‌های اجرا از LINQ to Objects.

• معماری دسترسی به داده‌ها (۱۵٪): استراتژی‌های پیاده‌سازی رویکردهای Code-First و Database-First، مهاجرت‌های ایمن Schema در محیط عملیاتی، کنترل دقیق از طریق Data Annotations و نگاشت پیشرفته مدل با استفاده از Fluent API.

• کوئری‌نویسی و بارگذاری (۱۸٪): تحلیل مزایا و معایب Eager Loading، پیکربندی‌های Lazy Loading، بارگذاری Explicit در زمان اجرا، حذف هزینه‌های Tracking از طریق AsNoTracking و استفاده از Compiled Queries برای مسیرهای اجرای تکراری.

• بهینه‌سازی عملکرد (۱۲٪): کاربرد پیشرفته AsNoTracking، کاهش استراتژیک داده‌ها از طریق Projection، معماری‌های Caching صریح، تطبیق ساختار کوئری‌ها با ایندکس‌های دیتابیس و حذف مشکل N+1 Query.

• همزمانی و تراکنش‌ها (۱۰٪): حل شرایط رقابتی (Race Conditions) از طریق توکن‌های Optimistic Concurrency، پیاده‌سازی ساختارهای Pessimistic Concurrency، تراکنش‌های بین-Repository و مدیریت مکانیسم‌های Locking لایه پایین.

• مباحث پیشرفته (۸٪): اتصال به خط‌لوله با استفاده از Interceptors، بهره‌گیری از موتورهای Diagnostics، لاگینگ SQL در زمان اجرا، پیکربندی موجودیت‌های بدون کلید (Keyless Entities) و طراحی انواع سفارشی Query.

• بهترین تجربیات و الگوهای طراحی (۷٪): جداسازی لایه‌های داده با الگوی Repository، مدیریت مرزهای تراکنشی با الگوی Unit of Work، ادغام‌های مدرن Dependency Injection و استراتژی‌های تست واحد (Unit Testing) ایزوله.

• عیب‌یابی و دیباگینگ (۱۰٪): تکنیک‌های گام‌به‌گام دیباگ، مدیریت خطا در سطح دیتابیس، تحلیل گلوگاه‌ها با ابزارهای Profiling و اعتبارسنجی خروجی‌های ترجمه SQL خام.

درباره دوره

کسب جایگاه به عنوان یک توسعه‌دهنده ارشد .NET یا Full Stack مستلزم چیزی فراتر از دانستن نحوه نوشتن کوئری‌های ساده LINQ است. مصاحبه‌کنندگان مدرن به دنبال مهندسانی هستند که بتوانند با اطمینان لایه‌های دسترسی به داده‌های بهینه طراحی کنند، از نشت حافظه ناشی از Change Tracking نادرست جلوگیری کنند و گلوگاه‌های پیچیده دیتابیس را پیش از انتشار کد تشخیص دهند. من این مخزن جامع سوالات را ساختم تا ابزاری ارزیابی واقعی و جامع در اختیار شما قرار دهم که مرزهای دانش شما در Entity Framework را به چالش بکشد.

با ۵۵۰ سوال اصلی و سناریومحور، این دوره از تعاریف سطحی فاصله گرفته و شما را در مرکز تصمیم‌گیری‌های معماری پیچیده قرار می‌دهد. تمرکز من بر واقعیت‌های عملیاتی است: مدیریت تداخلات همزمانی در آپدیت‌های با ترافیک بالا، اصلاح ترجمه‌های ناکارآمد SQL و جداسازی صحیح منطق با استفاده از الگوهای مدرن مانند Unit of Work. هر سوال دارای تحلیل فنی کامل است که مکانیسم‌های دقیق پشت گزینه صحیح را توضیح داده و دلیل ناکارآمد بودن مسیرهای جایگزین در اپلیکیشن‌های .NET با عملکرد بالا را روشن می‌کند. این مطالب آموزشی تضمین می‌کند که شما رفتار زیرساختی فریم‌ورک را درک کنید و با اعتمادبه‌نفس کامل در پنل‌های فنی مصاحبه پذیرفته شوید.

نمونه سوالات تمرینی

این سه نمونه سوال را بررسی کنید تا با فرمت ساختاری عمیق و توضیحات جامعی که در کل بانک سوالات ارائه شده است، آشنا شوید.

سوال ۱: کاهش نشت حافظه در کوئری‌های حجیم Read-Only

یک مهندس متوجه افت عملکرد اپلیکیشن و افزایش مصرف RAM در حین اجرای یک سرویس پس‌زمینه می‌شود که میلیون‌ها رکورد گزارش تاریخی را از طریق یک کانتکست Entity Framework Core پردازش می‌کند. رکوردها واکشی شده، در حافظه ارزیابی می‌شوند و هرگز تغییر نمی‌کنند. کدام رویکرد کارآمدترین راه برای حذف هزینه Tracking که باعث این مشکل شده است؟

• الف) فراخوانی DbContext.Database.EnsureCreated() قبل از شروع حلقه تکرار داده‌ها.

• ب) اعمال متد افزونه .AsNoTracking() روی عبارت اصلی کوئری LINQ.

• ج) فراخوانی صریح DbContext.SaveChanges() در هر تکرار از بلوک خواندن داده‌ها.

• د) تبدیل مجموعه به آرایه با استفاده از .ToArray() بلافاصله قبل از اجرای منطق فیلترینگ.

• ه) قرار دادن تعاریف اشیاء موجودیت زیرساختی در یک مدل ساختاری Keyless تخصصی.

• و) تغییر اسکیمای دیتابیس برای غیرفعال کردن کامل محدودیت‌های کلید خارجی در جداول هدف.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: به طور پیش‌فرض، Entity Framework تمام موجودیت‌های بازگشتی از کوئری‌ها را در Change Tracker خود ردیابی می‌کند که با افزایش حجم داده‌ها، حافظه زیادی مصرف می‌کند. اعمال .AsNoTracking() به موتور دستور می‌دهد که برای عملیات‌های فقط-خواندنی، این مکانیسم ردیابی را دور بزند، که مانع از تورم حافظه شده و سرعت اجرا را افزایش می‌دهد.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه الف نادرست است: این متد صرفاً ساختار اسکیمای دیتابیس را اعتبارسنجی یا ایجاد می‌کند و هیچ تاثیری بر رفتارهای ردیابی کوئری ندارد.

• گزینه ج نادرست است: فراخوانی SaveChanges باعث فشار آوردن آپدیت‌ها به دیتابیس می‌شود که سربار تراکنشی عظیمی ایجاد کرده و حافظه ردیابی انباشته شده را پاک نمی‌کند.

• گزینه د نادرست است: فراخوانی .ToArray() باعث Materialization فوری در حافظه می‌شود که در واقع مصرف حافظه را هنگام پردازش مجموعه‌داده‌های بزرگ تشدید می‌کند.

• گزینه ه نادرست است: موجودیت‌های Keyless برای نگاشت Viewهای سفارشی یا کوئری‌های بدون کلید اصلی استفاده می‌شوند، نه برای تغییر ردیابی تغییرات در مدل‌های استاندارد.

• گزینه و نادرست است: تغییر محدودیت‌های رابطه‌ای در سطح دیتابیس تاثیری بر رفتارهای داخلی ردیابی وضعیت در کانتکست اپلیکیشن .NET ندارد.

سوال ۲: حل شرایط رقابتی داده‌ها با توکن‌های همزمانی (Concurrency Tokens)

دو Thread پس‌زمینه سعی می‌کنند به طور همزمان یک رکورد دیتابیس را تغییر دهند. Thread اول وضعیت ردیف را تغییر می‌دهد، اما وقتی Thread دوم سعی می‌کند آپدیت خود را اعمال کند، لایه داده باید تشخیص دهد که رکوردها از زمان خوانده شدن، تغییر کرده‌اند. این مورد چگونه به صورت بومی از طریق Fluent API در Entity Framework Core پیکربندی می‌شود؟

• الف) تعریف پراپرتی با استفاده از .IsRequired() برای اجباری کردن مقادیر معتبر در حین سریالیزاسیون.

• ب) پیکربندی پراپرتی نسخه تعیین‌شده با استفاده از متد پیکربندی .IsConcurrencyToken().

• ج) تزریق یک DbCommandInterceptor سفارشی برای قفل کردن دستی جداول در حین انتخاب.

• د) نگاشت موجودیت به یک Database View فقط-خواندنی با استفاده از .ToView().

• ه) ثبت نمونه ردیابی وضعیت موجودیت در یک دامنه تزریق وابستگی Transient.

• و) پیاده‌سازی یک الگوی Repository اختصاصی که به طور کامل از اجرای Threadهای ناهمزمان جلوگیری کند.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: استفاده از .IsConcurrencyToken() از طریق Fluent API، پراپرتی را به عنوان یک نقطه ردیابی برای Optimistic Concurrency پیکربندی می‌کند. هنگام اجرای آپدیت، Entity Framework مقدار این توکن را در عبارت SQL WHERE قرار می‌دهد. اگر مقدار در دیتابیس از زمان واکشی تغییر کرده باشد، یک DbUpdateConcurrencyException رخ می‌دهد و سیستم را از شرایط رقابتی داده‌ها آگاه می‌کند.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه الف نادرست است: محدودیت .IsRequired() صرفاً یک قانون ستون غیر-nullable در دیتابیس ایجاد می‌کند و همزمانی نوشتن را مدیریت نمی‌کند.

• گزینه ج نادرست است: Interceptorها می‌توانند دستورات را تغییر دهند اما استفاده از آن‌ها برای قفل دستی در مقایسه با توکن‌های بومی Optimistic Concurrency پیچیدگی زیادی اضافه می‌کند.

• گزینه د نادرست است: Viewهایی که از طریق .ToView() نگاشت می‌شوند معمولاً غیرقابل نوشتن هستند یا برای گزارش‌گیری به کار می‌روند که هدف مدیریت آپدیت‌های همزمان را مختل می‌کند.

• گزینه ه نادرست است: دامنه تزریق وابستگی، طول عمر شیء Context را کنترل می‌کند، نه بررسی‌های اعتبارسنجی آپدیت در سطح ردیف در موتور دیتابیس را.

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

سوال ۳: حذف مشکل عملکرد N+1 در بارگذاری داده‌های رابطه‌ای

یک Endpoint در وب API لیستی از رکوردهای Order را واکشی می‌کند. برای هر سفارش پردازش شده، اپلیکیشن یک کوئری SQL جداگانه برای یافتن جزئیات موجودیت Customer مرتبط اجرا می‌کند که منجر به ده‌ها فراخوانی دیتابیس می‌شود. متدولوژی استاندارد برای حذف این نقص کوئری‌نویسی N+1 چیست؟

• الف) فعال‌سازی Lazy Loading Proxies به صورت سراسری در تنظیمات Startup اپلیکیشن.

• ب) استفاده از متد .Include() در عبارت کوئری ریشه برای اجبار به Eager Loading صریح.

• ج) پیاده‌سازی الگوی Unit of Work برای کش کردن Poolهای اتصال دیتابیس در بین نمونه‌ها.

• د) قرار دادن کل حلقه در یک تراکنش SQL توزیع شده با استفاده از قفل‌های صریح سطح ردیف.

• ه) تعریف مجدد روابط پراپرتی موجودیت هدف برای استفاده از پارامترهای Keyless Entity.

• و) فراخوانی دستی DbContext.Dispose() پس از جمع‌آوری مجموعه اولیه کلیدهای شناسه والد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت: مشکل N+1 زمانی رخ می‌دهد که یک کوئری لیستی از والدها را می‌گیرد و سپس داده‌های مرتبط را ردیف به ردیف به صورت Lazy واکشی می‌کند. استفاده از .Include(o => o.Customer) باعث Eager Loading می‌شود که به Entity Framework دستور می‌دهد یک دستور SQL JOIN بهینه بسازد. این کار باعث می‌شود داده‌های والد و فرزند در یک رفت‌وبرگشت (Round-trip) کارآمد به دیتابیس بازگردانده شوند.

• دلیل نادرست بودن گزینه‌های دیگر:

• گزینه الف نادرست است: فعال کردن Lazy Loading Proxies اغلب علت اصلی باگ‌های N+1 است، زیرا هر بار که یک Navigation Property در یک حلقه دسترسی پیدا کند، داده‌های مرتبط به طور ضمنی واکشی می‌شوند.

• گزینه ج نادرست است: الگوی Unit of Work مرزهای منطق تجاری را ساختاردهی می‌کند اما مسیر اجرای عبارات خاص LINQ را تغییر نمی‌دهد.

• گزینه د نادرست است: اعمال تراکنش‌های صریح دیتابیس، سطوح ایزولاسیون را مدیریت می‌کند اما حجم دستورات کوئری ارسالی را کاهش نمی‌دهد.

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

• گزینه و نادرست است: Dispose کردن کانتکست، ارتباط با دیتابیس را کاملاً قطع می‌کند و باعث می‌شود جستجوهای بعدی Navigation Property با خطاهای Runtime متوقف شوند.

چه انتظاراتی داشته باشید

• به تست‌های سوالات مصاحبه خوش آمدید تا شما را برای ارزیابی سوالات مصاحبه Entity Framework آماده کنیم.

• می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید.

• این یک بانک سوالات عظیم و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق است.

• سازگار با موبایل از طریق اپلیکیشن Udemy.

امیدواریم تا الان متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.