NILL Developers

هرجایی رو میبینی نوشته از AsNoTracking استفاده کن همچی سریعتر میشه اما واقعیت پشت پرده Change tracker efcore چیه که همه موقع خوندن داده اینقد باهاش بدن ولی میخوان ذخیره کنن دست به دامنش هستن؟! خب بیایم در این پست گام به گام چرخه کار این جانور چهارپا رو بررسی کنیم!! مقدمه ابتدا بگم که Change Tracker در EF Core مثل یک ناظر دقیق عمل می‌کنه که تغییرات روی entityها رو ردیابی می‌کنه. وقتی entityها رو از دیتابیس لود می‌کنی (مثل با Find یا ToList)، اونا رو track می‌کنه تا ببینه چی تغییر کرده، اضافه شده، حذف شده یا نه. این کار overhead داره (مصرف مموری و CPU برای snapshot گرفتن از حالت اولیه entityها)، واسه همین تو سناریوهای read-only همه می‌گن AsNoTracking بزن تا tracking خاموش بشه و پرفورمنس بهتر شه. اما وقتی می‌خوای تغییرات رو سیو کنی (با SaveChanges)، بدون tracking نمی‌تونی تغییرات رو detect کنی – پس دست به دامن Change Tracker می‌شی! چرخه حیات حالا چرخه کاملش شامل ۴ مرحله (یا بهتر بگم ۴ state اصلی برای entityهای tracked) می‌شه که entityها توشون جابه‌جا می‌شن. این stateها بر اساس مستندات رسمی EF Core هستن: ۱. مرحله Unchanged: این حالت اولیه‌ست وقتی entity رو از دیتابیس لود می‌کنی و هنوز هیچ تغییری روش ندادی. Change Tracker یک snapshot از پروپرتی‌ها می‌گیره و منتظر می‌مونه. اگه تغییری ندی، موقع SaveChanges هیچ کاری نمی‌کنه – entity دست‌نخورده می‌مونه. ۲. مرحله Modified: اگه یکی از پروپرتی‌های entity رو تغییر بدی (مثل user.Name = “NewName”)، state به Modified می‌ره. Change Tracker تغییرات رو با مقایسه snapshot اولیه detect می‌کنه و موقع SaveChanges، فقط فیلدهای تغییرکرده رو آپدیت می‌کنه تو دیتابیس. اینجاست که قدرت tracking مشخص می‌شه! ۳. مرحله Added: وقتی یک entity جدید می‌سازی و به context اضافه می‌کنی (مثل context.Users.Add(new User()))، stateش Added می‌شه. Change Tracker می‌فهمه این رکورد جدیده و موقع SaveChanges، یک INSERT تو دیتابیس اجرا می‌کنه. بعد از سیو، state به Unchanged برمی‌گرده. ۴. مرحله Deleted: اگه entity رو حذف کنی (مثل context.Users.Remove(user))، state به Deleted می‌ره. Change Tracker مارک می‌کنه که این رکورد باید حذف بشه، و موقع SaveChanges یک DELE

اینو تو فیسبوک دیدم، خیلی قشنگ بود: «استاد، من کتاب‌های زیادی خوانده‌ام… اما بیشترشان را فراموش کرده‌ام. پس فایده‌ی خواندن چیست؟» این پرسشِ شاگردی کنجکاو بود از استادش. استاد پاسخی نداد، فقط در سکوت به او نگاه کرد. چند روز بعد، کنار رودخانه‌ای نشسته بودند. پیرمرد ناگهان گفت: «تشنه‌ام. برایم کمی آب بیاور… اما با آن آب‌کش قدیمی که آنجاست.» شاگرد متعجب شد. درخواست عجیبی بود — چطور می‌شد با آب‌کشِ پر از سوراخ، آب آورد؟ اما جرئت نکرد مخالفت کند. آب‌کش را برداشت و تلاش کرد. یک‌بار… دو‌بار… بارها و بارها… سریع‌تر دوید، زاویه‌اش را عوض کرد، حتی سعی کرد سوراخ‌ها را با انگشت‌هایش بپوشاند. هیچ‌کدام کارساز نشد. نتوانست حتی یک قطره آب نگه دارد. خسته و ناامید، آب‌کش را کنار پای استاد انداخت و گفت: «متأسفم، نتوانستم. غیرممکن بود.» استاد با مهربانی به او نگریست و گفت: «تو شکست نخوردی. به آب‌کش نگاه کن.» شاگرد نگاهی انداخت… و چیزی دید. آب‌کشِ قدیمی و سیاه و کثیف، حالا می‌درخشید. آب، هرچند در آن نمانده بود، اما بارها و بارها از آن گذشته و شسته بودش تا براق شده بود. استاد ادامه داد: «خواندن هم همین‌گونه است. مهم نیست اگر هر جزئیات را به خاطر نسپاری، مهم نیست اگر دانسته‌هایت مثل آب از ذهنت بیرون می‌روند… زیرا در هنگام خواندن، ذهنت تازه می‌شود، روحت نیرو می‌گیرد، افکارت نفس می‌کشند، و حتی اگر بلافاصله متوجه نشوی، درونت در حال دگرگونی است.» این است معنای واقعیِ خواندن — نه برای پُر کردن حافظه، بلکه برای شستن و غنی‌ساختنِ روح.

https://www.linkedin.com/posts/mhmdnzr_%DA%86%D9%86%D8%AF-%D9%88%D9%82%D8%AA-%D9%BE%DB%8C%D8%B4-%D8%AF%D8%A7%D8%B4%D8%AA%D9%85-%D8%AF%D8%B1-%D9%85%D9%88%D8%B1%D8%AF-%DB%8C%D9%87-%D8%B3%D8%B1%DB%8C-%D9%85%D8%AA%D8%BA%DB%8C%D8%B1%D9%87%D8%A7%DB%8C-activity-7402965678644854784-9JyV?utm_source=share&utm_medium=member_ios&rcm=ACoAADAxjPcBWUjevaTqQy5s82swxBAYI12rQrU

سال پیش وقتی رفتم مصاحبه شرکت داتین از من سوال پرسیدن که فرق بین dynamic vs object چیه؟ من نمیدونستم تا وقتی که رفتم برای اون کتاب Pro DLR in .NET 4 رو خوندم دانشم رو دوست داشتم با شما به اشتراک بذارم براش یه صفحه بلاگ توضیح دادم: https://mhmdnzr.drl.ink/post/dynamic-vs-object-in-csharp

من یه مقاله به تازگی نوشتم در خصوص چرایی وجود یک سری primitives keyword ها در سی شارپ و چجوری اینا میتونن به توسعه و کاهش latency سیستم به ما کمک کنند با مثال واقعی: https://mhmdnzr.drl.ink/post/concurrent-file-uploader

پارسال رفته بودم مصاحبه Asan Pardakht برای نیروی دات نت یک سوالی اونجا ازم کرد که خیلی برام جالب بود، پرسید فرق بین for vs foreach تووی سی شارپ چیه؟ خب این یه سوال به ظاهر خیلی سادست اما وقتی ترکیب میشه با دیتابیس و فچ دیتا میبینی انگار چوب جادوی هری پاترو انگار پیدا کردی تووی این بلاگ سعی کردم در مورد این موضوع بییشتر صحبت کنم که چیشد اینجوری شد! پ.ن: البته اینم بگم که من قبول نشدم تووی مصاحبه اما هربار که من fail میشم خلاهای بیشتری رو در خودم کشف میکنم و به ظرف دانش یک قسمت دیگه اضافه میکنم تا بهتر از دیروز بشم #csharp #dotnet #software #architecture #pattern #learning https://mhmdnzr.drl.ink/post/for-vs-foreach

دارم روی یه سری پست کار می‌کنم که موضوعش دور و بر همون چیزیه که این روزها خیلی درگیرشم: latency، consistency، و اون لحظه‌هایی که سیستم یه چیزی رو "فکر می‌کنه" داره درست انجام می‌ده ولی در واقع نداره. این پست از دل یه بحث واقعی دراومد — یه سناریوی ساده که همه‌مون یه جایی باهاش برخورد کردیم ولی خیلی‌ها (منم قبلاً) دقیق بهش فکر نکردیم که چرا واقعاً خطرناکه. بذارید مستقیم بریم سراغ صحنه‌ی جرم. https://mhmdnzr.drl.ink/post/distributed-lock

فراتر از Npgsql: راهنمای کامل PgBouncer، Pgpool-II، Odyssey و پروکسی‌های ابری Postgres برای اپلیکیشن‌های C# https://mhmdnzr.drl.ink/post/npgsql-pgbouncer-pgpool-ii-odyssey-postgres-c

یه جایی توی پروژه‌مون به خودمون گفتیم: «بابا Notification که دیگه این همه داستان نداره! یه API می‌زنیم، پیامو می‌فرستیم، تموم.» و واقعاً هم همین کارو می‌شه کرد. ساده‌ست، سریع پیاده می‌شه، Infrastructure خاصی نمی‌خواد و تا وقتی همه‌چی خوب پیش میره، خیلی هم قشنگه :) ولی مشکل از جایی شروع می‌شه که همه‌چی خوب پیش نمی‌ره! مثلاً: پیام توی DB ذخیره شده، ولی سرویس قبل از Publish کردن به RabbitMQ می‌میره. تبریک می‌گم! پیام داری ولی Event نداری :) یا OTP و Campaign رو ریختی توی یه Queue و یهو چند هزار تا پیام Campaign اومده. حالا کاربر منتظر OTPـه و Queue داره با خودش حال می‌کنه! اینجاست که داستان کم‌کم تبدیل می‌شه به یه فاجعه کوچیکِ قابل مدیریت و باید بری سراغ چیزهایی مثل: Outbox Retry Idempotency Queue Isolation Hangfire Critical Workers و کلی چیز دیگه. البته اینجا هم فکر نکنی همه‌چی حل شد! هر راه‌حل جدید خودش یه عالمه پیچیدگی، Monitoring، Failure Mode و در نهایت یه مقدار بگ....یی!! جدید با خودش میاره :)) توی NotificationHub دقیقاً سعی کردم همین مسیر رو بررسی کنم: هر تصمیم معماری چه مشکلی رو حل می‌کنه؟ چه مزیتی داره؟ چه هزینه‌ای ایجاد می‌کنه؟ و مهم‌تر از همه، کِی اصلاً نباید ازش استفاده کنیم؟ اگه با Backend و Distributed Systems سروکله می‌زنی، احتمالاً این داستان برات آشناست. اینجا فقط یه بخش کوچیکشو گفتم. اگه کنجکاو شدی ببینی آخرش این فاجعه رو چطوری جمع کردیم، بنظرم ارزش وقت گذاشتن و خوندن رو داره: 🔗 https://mhmdnzr.drl.ink/post/5086561b #SoftwareArchitecture #Backend #DotNet #DistributedSystems #SystemDesign

این جمله درسته که همیشه دیتای حجیم باعث مرگ سیستم میشه؟ یا یک hot path در لایه infra SQL باعث میشه به ددلاک بخوریم؟ چجوری میشه حلش کرد؟ صرفا چندتا راه همیشگی AsNoTracking, AsSplitQuery, projection, N+1 problem و... یا استفاده از compiled query مارو از این منجلاب بیرون میکشه؟ یا شاید در زبان سی شارپ و ویژگی هاش باید دیپ تر بشیم؟ خب بنظرم گزاره دوم درسته، ما فهم ناقصی از سیستم کارکرد سی شارپ داشتیم تووی این مقاله سعی کردم راه حلمو با for vs foreach ترکیب کنم و بهتون ارائه بدم. میتونین از طریق لینک زیر مطالعه کنید: https://mhmdnzr.drl.ink/post/d0040081

ما اکثرا از FirstOrDefault استفاده کردیم تا بخوایم بر اساس کلید یا یک ستون بریم داخل دیتا بیس پیدا کنیم، اما بقیش چی؟ کلا پنج تابع اصلی داریم برای پیدا کردن. اونا چیکار میکنن؟ تبدیل به چه کوئری میشه در نهایت؟ همه و همه در این مقاله جا شدن: تفاوت در پیدا کردن است! https://mhmdnzr.drl.ink/post/4ff4fb50

چرا وقتی میخوایم بدونیم یه آیتم توی دیتابیس یا یک persistent store هست یا نه، باید از Any استفاده کنیم نه Count() > 0؟ این سؤال رو توی مصاحبه‌ها زیاد میپرسن، چون جوابش فقط سر syntax نیست، سر چیزیه که پشت صحنه اجرا میشه. روی یک IQueryable (مثلاً EF Core): users.Any(u => u.Id == id) users.Count(u => u.Id == id) > 0 اولی به EXISTS یا SELECT TOP(1) ترجمه میشه؛ دیتابیس همین که یه ردیف مچ پیدا کنه متوقف میشه. دومی به COUNT(*) ترجمه میشه؛ دیتابیس مجبوره (بسته به index) همهٔ ردیف‌های مچ رو بشمره، حتی اگه فقط بخوای بدونی حداقل یکی هست. روی دیتاست بزرگ این فرق فقط تئوری نیست؛ رو query plan، I/O، و latency واقعاً اثر میذاره. توی حافظهٔ خود برنامه (نه دیتابیس) هم یه داستان مشابه با جزئیات متفاوت هست: enumerator، closure allocation، و اینکه چرا struct بودن Enumerator باعث میشه فرق اصلی سر heap نباشه، سر تعداد iteration باشه. کل تحلیلش رو با کد، جدول پیچیدگی زمانی، و رسم Stack/Heap توی این پست نوشتم: [لینک مقاله]