https://virgool.ir/feed/@ehsan.tabakhianfa2026-11-11 20:31:09https://files.virgool.ir/upload/users/5570/avatar/avatar.pnghttps://virgool.ir/@ehsan.tabakhianhttps://virgool.ir/@ehsan.tabakhian/شرایط-مسابقه-race-condition-چیست-و-چرا-q5pa36argblrسلام خدمت همه گرامیان و عزیزان که مجموعه مقالات من رو در زمینه EntityFramework Core تا الان دنبال کردن. میدونم خدمتتون قول داده بودم که در ادامه Eager loading براتون توضیحات روش جادویی Lazy Loading رو شرح بدم ولی خب احساس کردم دوپا شیرجه رفتن تو دل این مطلب بدون آشنایی با مقدمات و اصطلاحات کار اشتباهیه ? این شد که تصمیم گرفتم از یه جای تقریبا مناسب که Race Condition باشه شروع کنم به توضیح مطالب تا ایشالا در نهایت برسیم به Lazy Loading ??.برای شروع باید بگم که Race Condition یا Race Hazard شرایطی هست که یک مدار الکترونیکی(منطقی) یا نرم افزار کامپیوتری یا یک سیستم پیچیده رفتار و کارکردی داره که مشخصا متکی به توالی زمانی رخ داد رویداد های غیر قابل کنترل هست.رویداد غیر قابل کنترل یعنی رویدادی که زمان اتفاق افتادنش برای ما نامعلوم هست و باید برای پذیرش این درخواست یا اتفاق هرلحظه آماده باشیم ?معمولا در شرایط مسابقه ای الویت زمانی این رویداد ها برای ما مهمه ? مثلا نرم افزار یک برنامه تلویزیونی رو در نظر بگیرید که هر کس بعد از خوندن سوال توسط مجری زودتر زنگ رو بزنه برای ما مهم تر میشه.احتمالا دارید به این فکر میکنید که ممکنه دو نفر همزمان زنگ رو فشار بدن و دردسر درست بشه ?، بله متاسفانه همینطوره و اگر یک یا چند تا رخ داد برای ما غیر منتظره باشه و نتونیم درست بهشون رسیدگی کنیم, شرایط مسابقه میتونه به راحتی تبدیل به یک باگ بزرگ بشه برای ما ?!اگر دانش آموخته رشته کامپیوتر یا الکترونیک باشید احتمالا این اطلاعات رو قبلا خوندید و براتون آشناست ?! در مدار های منطقی یا سیستم های توزیع شده و یا دارای چند رشته پردازشی که ممکنه چند رویداد همزمان در رشته های مختلف رخ بدن به طور معمول شرایط مسابقه خود به خود پدید میاد !لفظ Race Condition سابقه طولانی در علوم کامپیوتر و الکترونیک داره و حتی از سال 1954 در رساله دکترای دانشمند معروف ? David A. Huffman به نام "The synthesis of sequential switching circuits" هم دیده شده.ما در این مقاله قسمت مربوط به شرایط مسابقه در الکترونیک و مدار های منطقی رو توضیح نمیدیم ولی اگر خودتون خیلی علاقه مند هستید می تونید از منابعی که پایین معرفی کردم دنبال کنید. و اما در توضیح Race Condition در طراحی نرم افزار های کامپیوتری باید بگم این شرایط زمانی رخ میده که یک نرم افزار در کارکردش به توالی و رخ داد زمانی چند تا Thread یا Process متکی و حساس باشه ?!از بین تمام شرایط مسابقه ای که ممکنه در نرم افزار ها رخ بده، بعضی از اون ها وجود دارن که واقعا بحران آفرین هستن(Critical Race Condition) و پتانسیل به فنا دادن برنامه شما و حتی فراتر از اون، جون شما رو دارن ??!همونطور که می دونید هر برنامه ای که از چندین رشته پردازشی تشکیل شده باشه، در حافظه Ram مربوط به برنامه قسمت های حافظه ای مخصوص اطلاعات هر رشته وجود داره و رشته ها در حالت معمول نمیتونن به اطلاعات بقیه رشته ها دسترسی داشته باشن و این در اکثر اوقات مزیت خوبی حساب میشه و برنامه رو از مشکلات همزمانی پردازش ها نجات میده ?! ولی نکته مهم اینجاست که معمولا قسمتی از حافظه وجود داره به نام Shared Memory که اطلاعات سراسری یا همرسانی شده بین رشته ها در اون نگه داری میشه و همه رشته ها قابلیت دسترسی و تغییر این قسمت از رم رو دارن ? و این خیلی ترسناکه وقتی با Race Condition سر و کار داریم. مثلا متغییر های جهانی و سراسری (Global) یا اطلاعات درون هر کلاسی که به صورت استاتیک تعریف شده باشه در این قسمت حافظه جای دارن ?.علاوه بر موضوع حافظه مشترک، این اختلال بین پردازش های مختلف در دسترسی به بعضی از Resource ها(منابع کامپیوتری مثل فایل ها، پرینتر و دی وی دی رایتر) که قابلیت انجام بیش از یک کار همزمان رو ندارن هم ممکنه رخ بده! برای مثال یه پرینتر رو در نظر بگیرید که اگر تا تمام شدن پرینت یک صفحه اطلاعات صفحه جدیدی برای چاپ بفرستید قاطی کنه و روی همدیگه صفحات رو چاپ کنه ?. پس بعضی از منابع هم به صورت مشترک بین پردازش های همزمان قابل دسترس هستن.به این حالت های مشترک بین رشته های پردازشی Shared State میگن !خب مشخصا Race Condition در نرم افزار های چند رشته ای و دارای پردازش همزمان ممکنه وجود داشته باشه ولی در حالتی که هر رشته فقط در محدوده خودش پردازش کنه و به هیچ Shared State ای متکی نباشه همه چی میتونه اوکی باشه ??! ولی امان از روزی که شما یه Race Condition داشته باشید، به صورت خواسته یا ناخواسته چند رشته پردازشی از اون با یک یا چند Shared State سر و کار داشته باشن !!! اینجاعه که اوضاع قاطی پاتی میشه و اگر محافظت نکنید احتمال اینکه رشته ها باعث ایجاد نتایج نامطلوب بشن بسیار بالا میره ??☹️?!به این مدل شرایط مسابقه خطرناک و بحرانی Critical Race Condition میگن!در علوم کامپیوتر نقل شده که برای جلوگیری از این مشکلات عملیات هایی که بر روی Shared State ها انجام میشن(مثل ارسال یه صفحه به پرینتر یا تغییر مقدار یه متغیر سراسری یا استاتیک) Critical Section نام دارن و باید سعی کنید ازشون کمتر استفاده کنید و اگر هم استفاده کردید باید به شکل Mutual exclusion باشن ! در واقع مفهموم دو به دو منفرد بودن یا (Mutual exclusion) که Mutex هم بهش میگن در علوم کامپیوتر به این شکل هست که نباید دو پردازش اجازه داشته باشن همزمان از یه Shared State استفاده کنن! شما باید مکانیزمی رو طراحی کنید که اگر یک پردازش شروع به استفاده یا تغییر یه Shared State کرد بقیه پردازش ها با اینکه رو یه رشته دیگه هستن ولی صبر کنن تا استفاده رشته اول از Shared State تموم بشه و اگر بعد از تموم شدن کار رشته اول، رشته دیگه ای کار خاصی با اون Shared State داشت وارد فرآیند بشه ولی همزمان باهم هرگز! در واقع یه جور لیست برای دسترسی به Shared State ها بین رشته ها ایجاد کنید ??! اینکار معمولا با استفاده از متغیر نگهبانی اتفاق میافته که خودش در Shared State هست و مشخص میکنه که یه Shared State دیگه الان در حال استفاده هست یا نه که به این متغییر Semaphore گفته میشه و در این عملیات اصطلاحا ما اون Shared State رو Lock کردیم و بعد از اتمام پردازش رشته اول Unlock کردیم که توضیحات مخصوص خودش رو داره!حالا داستان برای تعریف کردن زیاده ولی حتما توصیه میکنم چند ساعتی وقت بزارید تو یه زمان خالی از زندگیتون و خودتون مطالب مربوط به Critical Section ،Mutex و Semaphore رو مطالعه کنید و نحوه پیاده سازیشون رو یاد بگیرید هرچند که خودم هم بلد نیستم کامل و فقط مجبور شدم چند باری سریع مطالعشون کنم ?. همچنین یه مفهوم جالب دیگه به اسم Data Race هم وجود داره که نوعی از Race Condition ها حساب میشه و توصیه میکنم اونم دنبال کنید مخصوصا اگر با C و ++C سر و کار دارید.یه نکته همینجا بگم تا یادم نرفته! اگر یک برنامه نویس با تجربه باشید قطعا تا حالا با باگ های هایزنبرگ(Heisenbug) برخورد داشتید و حساب کار دستتون اومده که چه جوونور هایی هستن! اگر هم نمی دونید بگم که باگ Heisenbug در واقع مشکل نرم افزاریه که به محض اینکه برنامه نویس تلاش میکنه تا در حالت Debug Mode یا همون عیب یابی خودمون این مشکل رو بررسی و حل کنه خود مشکل غیب میشه ??! و به این راحتی در حالت غیر از عرضه رسمی محصول(Production) قابل بررسی نیست! متاسفانه معمولا اگر خطای طراحی نرم افزاری رو مرتکب بشید در استفاده از Critical Race Condition این خطا در برنامه باگ هایزنبرگ خواهد بود و فقط در صورتی که تعداد پردازش ها بالا بره در حالت Production شما نتیجه به فنا رفتن رو شاهد خواهید بود ? و در حالت دیباگ متوجه نمیشید مشکل از کدوم قسمت کد شماست! علت هم معمولا اینکه نتیجه اجرای کد قابل پیشبینی نیست و همه چی به زمان اجرای بین رشته های پردازشی بستگی داره.بیایید براتون یه مثال از همین Critical Race Condition بزنم و نتیجه خفت بارش رو از نزدیک ببینید ?! فرض بکنید که دو تا Thread داریم که هر دو میخوان مقدار یه متغییر سراسری(Global) رو همزمان افزایش بدن، در نتیحه ما میل داریم که اتفاقات پایین به ترتیب رخ بدن : ولی نکته اینکه اگر این رشته های پردازشی قرار باشه همزمان اجرا بشن بدون محافظت و لاک شدن نتیجه ممکنه کاملا اشتباه باشه! به این ترتیب :همونطور که میبینید جواب باید 2 باشه بعد از دوبار افزایش ولی همچنان 1 هست ! علت اینکه این دو پردازش Mutually exclusive نیستن و یکی در حین کار اون یکی مزاحمش میشه و مقدار اشتباهی رو میگیره! این از من به شما نصیحت که :نگذارید پردازش هاتون مزاحم همدیگه بشن زمانی که جداگانه مشغول کارن ??!چند تا نکته مهم دیگه هم بگم و رفع زحمت کنم از خدمتتون! تعدادی از باگ های مهم امنیتی که میتونن باعث ورود غیر مجاز به سرویس شما بشن و یا حتی کل سرویس رو بخوابونن از همین طریق Critical Race Condition بوجود میان! برای مثال در حملات سایبری معروف Dos و DDos مهاجم با ارسال تعداد بالایی درخواست به سیستم شما در بخشی از حمله قصد داره باعث بالارفتن تعداد پردازش ها در سیستم بشه و در نتیجه در جایی که شما سوتی داده باشید یک باگ Race Condition از نرم افزار بزنه بیرون و ناک اوت ?!!! و یا حتی مجموعه باگ های مهمی مثل Privilege escalation(تشدید اختیارات و دسترسی) که در یک فقره از این مجموعه مثل Buffer overflow مهاجم میتونه با درخواست پیاپی برای نوشت بر روی قسمتی از حافظه به قسمت های دیگه هم دسترسی بگیره و اطلاعات برنامه ها یا افراد دیگه رو هم بخونه ?! باگ عجیبی مثل time-of-check-to-time-of-use TOCTTOU هم ممکنه در سرویس های Auth شما اتفاق بیافته که نتیجه خیلی دردناک میشه ?!از اونجایی که فایل ها و همینطور شبکه سیستم هم معمولا به صورت Shared State در نرم افزار ها در دسترس رشته های پردازشی هستن باید با روش هایی مثل لاک کردنشون موقع استفاده ازشون در برابر برنامه خودتون ? محافظت کنید!چیز خیلی جالبی که متاسفانه باید بهش اشاره کنم: در سیستم هایی که با جون آدمیزاد سر و کار دارید باید حواستون رو خیلی به همین Critical Race condition ها جمع کنید چون قبلا سابقه کشته دادن داشته ???! دستگاه رادیوتراپی هسته ای Therac-25 که توسط اتحادیه اروپا و فرانسه وارد بازار شده بود! در فاصله سال های 1985 تا 1987 بیش از 6 حادثه آفرید !! این مشکلات در نتیجه یک باگ Critical Race condition بود که مقدار دوز بسیار بالاتری از حد نرمال مواد هسته ای به بدن بیمار وارد میکرد ??☠️! بعدا مشخص شد در نتیجه این حوادث مستقیما 3 بیمار فوت شدن و چندین تن هم صدمات سهمگینی دیدن ?! شاید باورتون نشه ولی در سال 2003 هم در سیستم های مدیریت انرژی شرکت جنرال الکتریک آمریکا، در زیر سیستم مربوط به آلارم اضطراری یک باگ Race Condition وجود داشته که باعث میشده در صورتی که 3 تا از خط های تولید برق همزمان دچار مشکل بشن و بخوان آلارم رو روشن کنن در نتیجه سه درخواست همزمان روشن شدن آلارم، سیستم قاطی کنه و کلا آلارم روشن نشه ?! در نتیجه مشکل شبکه برق از چشم کارمند ها دور بمونه و فاجعه قطعی سراسری برق آمریکا شمالی در سال 2003 رخ بده ?! در این حادثه برق قسمت های وسیعی از کانادا و آمریکا قطع میشه و حتی بعضا تا 3 روز بعد هم وصل نمیشه.خلاصه که دوستان برنامه نویس گلم! این داستان خطرناکه و از خودتون و کدهاتون در مقابل شرایط مسابقه بحرانی مراقبت کنید که خدایی نکرده بحران آفرینی نکنید ?! در تهییه محتوای این مقاله و ترتیب قرار گیری بخش های مختلف توضیحات سعی شده از صفحه رسمی ویکیپدیا انگلیسی Race Condition استفاده بشه. از همینجا از همه نویسندگان آزاد ویکیپدیا در سراسر جهان تشکر میکنم که اطلاعات خودشون رو با ما به اشتراک گذاشتن، میذارن و خواهند گذاشت ?!در صورتی که محتوای این مقاله رو دوست داشتید و لذت بردید من رو در توییتر و ویرگول فالو کنید تا از ادامه آموزش Lazy Loading مطلع بشید و با همین فرمون باهم بریم جلو ???.مهر 1398 محمد احسان طباخیان ❤️Mohammad Ehsan TabakhianMohammad Ehsan TabakhianTue, 08 Oct 2019 01:14:17 +0330https://virgool.ir/@ehsan.tabakhian/eager-loading-در-entityframework-core-af7yqg0pty32Eager Loading در مقاله آغازی براتون به صورت خلاصه هر سه حالت لود اطلاعات NavigationProperty ها رو توضیح دادم!تو این مقاله قصد دارم که داستان لود زودهنگام(Eager Loading) رو براتون تعریف کنم ! همونطور که تو مقاله آغازین هم خدمتتون گفتم لود زودهنگام اولین روش برای دریافت اطلاعات موجود در پراپرتی نویگیشن های یه مدله ! شما با نوشتن کامند Include(Target Navigation Property) در دستورات لینک خودتون که بر روی یک Entity از DatabaseContext شما زده میشه می تونید برای ORM مشخص کنید که قصد دارید تمام اطلاعات مربوط به اون نویگیشن پراپرتی رو هم همزمان در کوئری اولیه که برای دریافت اطلاعات اصل مدل درخواستی به سمت دیتابیس فرستاده میشه ، دریافت کنید !در مثال پایین ما در واقع یه Entity بلاگ داریم که با Entity دیگری به نام پست ارتباط یک به چند داره. و قصد داریم که لیست بلاگ ها رو از دیتابیس دریافت کنیم و همزمان لیست تمام پست های مربوط به هر بلاگ در نویگیشن پراپرتی مربوطه( blog.Posts ) در هنگام دریافت اطلاعات بلاگ ها موجود باشه.خوبیه این داستان اینکلود اینکه محدودیت استفاده نداره ! یعنی شما ممکنه همزمان مشخص کنید که دیتا چند نویگیشن پراپرتی رو در کوئری اولیه نیاز دارید و اصلا و ابدا دوووشششواررری نداریم ???!!یکم ممکنه بد توضیح داده باشم ولی به طور کلی بسیار آسونه و احتمال خیلی زیاد بلد بودید از قبل ! ولی این داستان آقای اینکلود ریزه کاری هایی هم داره که قراره امروز با هم یادشون بگیریم ! فقط همین اول کاریه بزارید یه چیزی رو براتون توضیح بدم که بعدا نیایید بگید چرا ما هنوز اینکلود استفاده نکردیم ولی بعضی از مدل هامون (فرض کنید بعضی از بلاگ های بالا از لیست بلاگ ها) انگار به صورت پیش فرض نویگیشن پراپرتی هاشون دیتا دارن !!!! ????? !!!! همونجور که میدونید وقتی ما میخوایم در کد خودمون از EF استفاده کنیم ، برای ارتباط با دیتابیس روال به این شکله که اول یه آبجکت(اینستنس یا شئ) از کلاس DatabaseContex خودمون میسازیم(ممکنه اینجکتش کرده باشیم ولی خب مهم اینکه یک آبجکت حاضر و زنده ازش داریم)، در مرحله بعد ما برای استفاده یه دات میزنیم بعد این آبجکت و یه کوئری با استفاده از دستورات Linq ایجاد میکنیم! این کاری بود که ما میکنیم برای گرفتن اطلاعات! ولی حالا سوال اینکه خود EF داره برای آوردن اطلاعات تا وسط کد ما چیکار میکنه ؟!؟!خیلی ساده بخوام بگم! بعد از ساختن کوئری ، این کوئری شما اول یه سری مراحل برای تصحیح رو طی میکنه و تبدیل به کامند TSQL میشه و در نهایت به دیتابیس میره! اطلاعات از دیتابیس بازگشت داده میشن ولی به صورت لیست های جنریک نیستن! پس ORM اونا رو براتون کانورت و کست میکنه به فرمت کلاس های مدلی که برای جدول های دیتابیس نوشتین! نکته مهمش اینجاست که در نهایت این دیتاها که در فرمت لیست های جنریک یا آبجکت هایی از EntityModel های شما هستن میان و میرسن به اون آبجکتی که از DatabaseContex داشتیم و کوئری هم توسط اون ارسال کرده بودیم! انگاری اصل خویش رو بازجووییدن ?!و اون آبجکت عزیز هم به شما پس میده اطلاعات کوئری مورد نظرتون رو و شما تو لیستی چیزی ذخیره میکنید! نکته ای که اینجا خیلی مهمه!!!!! اینکه اطلاعات یکبار از این آقای آبجکت DatabaseContext ما عبور کرده قبل از رسیدن به ما و همین کافی بوده تا ایشون زحمت بکشن و کش(ذخیره موقت) بکنن دیتا هارو ! فلذا دفعه بعد که شما درباره اون آبجکت کوئری بفرستید ایشون چک میکنن اول اگر که ببینه تو خودش کش شدش رو داره همون رو بهتون میدن یه جورایی! پس زمانی که شما دیتا یه نویگیشن پراپرتی رو درخواست نمیکنید از EF (اینکلود استفاده نمیکنید). ولی میبینید که به جای نال بودن ، این بنده خدا دیتا داره توش ! برنگردید بگید یاللعجب ??? چرا اینجوری شد! بدانید و آگاه باشید که قبلا با اون آبجکت DatabaseContext یه بار دیتای اون نویگیشن پراپرتی رو درخواست کرده بودید و ایشون دارن از کَش خودشون بهتون میدن ?!آها تا یادم نرفته! یه نکته ای رو همینجا بهتون میگم که بعدا ممکنه دیگه شرایطش پیش نیاد! این از اون نکاتیه که ممکنه هرجایی نبینیدش و اگر بهش دقت نکنید و ندونید که داره چه اتفاقی میافته ! به فنا میرید! من خودم به شخصه چندین روز دنبال باگی میگشتم که این مسئله ایجاد کرده بود! کش کردن اطلاعات توسط این آبجکت DatabaseContext در 90 درصد اوقات باعث بهبود سرعت میشه! ولی در 10 درصد بقیه باعث بدبختی فلذا خاموش کردن حالت کش موقت اصلا درست نیست چون مزایای اون 90 درصد هم از دست میدید! برای اینکه این کش شدن اذیتتون نکنه باید حواستون باشه آبجکت های مهمی که هر چند ثانیه یه بار ممکنه اطلاعاتشون عوض بشه در دیتابیس، توسط DatabaseContext های دیگه ای در جاهای دیگه از برنامه باید حتما قبل از استفاده حیاتی یکبار از دیتابیس ریلود بشن! یعنی ممکنه در دیتابیس اون دیتا تغییر کرده باشه ولی DatabaseContext ما هنوز فکر میکنه تغییری نکرده و کش خودش رو بهمون میده ???! اینجا ما باید وادارش کنیم که یکبار ریلود کنه اطلاعات اون آبجکت به خصوص رو از دیتابیس (این اتفاق در اپلیکیشن های وب بیشتر رخ میده که چندین آبجکت DatabaseContext دارید) !بدانید و آگاه باشید برای ریلود کردن یک آبجکتی که قبلا استفاده کردیم (کش شده) و احتمال میدیم که تغییر کرده در دیتابیس ! باید از متود Reload استفاده کنیم : myDatabaseContextObject.Entry(blog).Reference(b => b.Owner).Reload() ; یا حتی به صورت کلی تر : myDatabaseContextObject.Entry(blog).Reload() ;یکی از نکات دیگه در استفاده از اینکلود ، لود چندین سطحی از اطلاعات هست. به طوریکه میتونید با متد ThenInclude لیست ها و ابجکت ها رو تا جایی که دوست دارید بشکافید و برید پایین و هرکدوم از داده هایی که نیاز دارید رو اینکلود کنید. مثلا در مثال پایین ، ما لیست رکورد های جدول Blogs رو از دیتابیس درخواست میکنیم ! و قصد داریم در همین درخواست اطلاعات لیست Posts از هر رکورد بلاگ هم داشته باشیم(اینکلود اول) و همینطور از داخل اطلاعات Post ها که با اینکلود اول لود کردیم! اطلاعات نویگیشن پراپرتی (نویسنده)Author هر پست که خودش یه آبجکتی به نام Author داره هم لود بشه!همینطور که میبینید هی داریم در اطلاعاتی که با اینکلود اولیه لود کردیم میریم پایین و پایین تر و محدودیتی هم نداره ! مثلا میتونیم تا چندین مرحله دریل کنیم و به سطوح پایین تری بریم و اطلاعات مورد نیازمون رو مشخص کنیم !قبلا گفتیم که میتونستید همزمان از چند اینکلود استفاده کنید ! الان هم مشکلی نیست میتونید همزمان هم چندین Include و هم چندین ThenInclude داشت باشید و لذت ببرید ???!!!فقط به این نکته ریز دقت کنید که هربار شما از ThenInclude استفاده می کند شما رو توی اون داده ای که دفعه قبل اینکلود کردید و الان ThenIclude روش زدید فرو میبره ! یعنی مثلا اگر بخوایید که Photo از نویگیشن پراپرتی Author رو لود کنید چون Photo در درون Author قرار داره و یک سطح فرو میرید حق دارید ThenInclude استفاده کنید(مثل کد بالا) ! ولی مثلا فرض کنید دو تا نویگیشن پراپرتی هم سطح دارید که هر دوتاشون درون Post قرار دارن مثل Author و Tags : Blog -> Posts -> Author و Blog -> Posts -> Tagsدر این شرایط باید طبق نمونه زیر عمل کنید و هر دوتا شاخه هم عرض رو دوباره از ریشه اصلی اینکلود کنید :نکته مهم بعدی هم که باید بهتون بگم در مورد کاربرد اینکلود بر روی مدل ارث برده از یه مدل دیگست ! یکم ممکنه توضیح این قسمت سخت باشه برا همین اول مثال رو میزارم ? که ببینید و بعد توضیح میدم :خب همونجور که میبینید با استفاده از مدل های بالا یه جدول Person در دیتابیس داریم که بعضی از اون ها ممکنه Student باشند و بعضی هم نه! امیدوارم نحوه کار با InheritedEntities رو بلد باشید که چه اتفاقی میافته وقتی که این جوری جداول رو ایجاد میکنید(در واقع خود EF یه پراپرتی بولین میگیره تو جدول People که آیا این رکورد Student هست یا نه و خودش هندل میکنه ...) که خب طبیعتا اینجا واردش نمیشیم ولی در این حد بدونید که الان میخوایم یه حرکتی بزنیم که موقع اینکلود کردن به EF بگیم اگر که اون رکورد مورد نظر از Person که داریم لود میکنیم در لیست ، Student بود شما لطف کن و اون نویگیشن پراپرتی School رو هم دیتاشو برامون لود کن! اینکار توسط یکی از سه روش زیر قابل انجام هست : به عنوان نکته پایانی هم میخوام بحث اینکلود های نادیده گرفته شده ?☹️ رو مطرح کنم ! عزیزان دل توجه کنید که اگه بعد از استفاده از اینکلود بیایید و از Select یا دستورات مشابه که جنس خروجی رو تغییر میده استفاده کنید به طوری که در تایپ خروجی جدید از اطلاعاتی که با اینکلود لود کردید استفاده نشه ! درواقع اون لود کردن شما هیچ استفاده ای نداشته و اشتباه بوده ! در این حالت خود EF زحمت میکشه و به جای شما برای بالا رفتن کارایی و سرعت کوئری ، کلا اینکلود یا اینکلود هایی که نوشتید رو بیخیال میشه و حتی نگاهشون هم نمیکنه و طبیعتا در TSQL کوئری تولیدی اثری هم ازشون پیدا نمیشه! مثال این حرکت خز : در نهایت اینم بدونید که در حالت عادی خود EF این کد زشت ? که توش همچین اتفاقی افتاده رو اگه ببینه براتون تویه Output موقعه کامپایل یه وارنینگ و هشدار بسیار ساده لاگ میکنه که " من اینو نادیده گرفتم ! " اگر قصد دارید که به صورت جدی تر تو نرم افزار اگر همچین اتفاقی افتاده بود براتون وارنینگ درشت تر یا حتی اروری رو ایجاد کنه و پرت کنه تو چشای برنامه نویس ??? (throw کنه) ، میتونید تو DbContext.OnConfiguring یا Startup.cs(اگر از AspNetCore استفاده میکنید) برای کامپایلر مشخص کنید :خوشحال شدم که منو همراهی کردید تا اینجا! این مقالات حداقل دو قسمت دیگه در این زمینه داره که امیدوارم اونم پیگیری کنید! قسمت بعد قراره درمورد Lazy Loading باشه که خیلی جذاب و جالبه ??❤️! به قول خارجی ها ??? Stay tuned for my next articles . مطالب این مجموعه مقالات مستقیم از داکیومنت رسمی مایکروسافت اومده !و سمپل ها رو هم میتونید از اینجا ببینید : AspNetCore GitHubMohammad Ehsan TabakhianMohammad Ehsan TabakhianFri, 01 Mar 2019 20:52:37 +0330https://virgool.ir/@ehsan.tabakhian/loading-related-data-در-entityframework-core-w79iqtia9cz4خب اول از همه باید خدمتتون عرض کنم که EntityFrameworkCore مثل نسخه های قبلی خودش به ما اجازه میده در برقراری رابطه های مختلف بین جداول دیتابیس از NavigationProperties استفاده کنیم . نویگیشن پراپرتی : استفاده یه پراپرتی از جنس مدل اون سر رابطه در مدل خودمون، جهت لود کردن آسون تر اطلاعات رکوردی که از جدول اون سر رابطه در مدل ما وجود داره . مثال پایین رو ببینید . (پراپرتی School در مدل Person مثال واضحی از نویگیشن پراپرتی هست که احتمالا خودتون هم باهاش آشنا بودید ! )کلا سه تا حالت متداول برای لود کردن دیتا یه نویگیشن پراپرتی موقعه استفاده از دیتابیس در کدمون وجود داره ! که تقریبا همه ORM های جهان این سه تا روش رو ارائه میدن به شما . در EF به دلیل استفاده از دستورات Linq جهت ایجاد کوئری به دیتابیس و دریافت اطلاعات شما تفاوت کارکرد این سه روش رو بهتر درک میکنید! ? لینک مقاله اختصاصی هر قسمت بر روی اسم آن موجود است. لود زودهنگام (Eager loading) : به معنی اینکه دیتای نویگیشن پراپرتی به عنوان بخشی از کوئری اولیه برای استفاده vhyjuمستقیم شما از سمت دیتابیس برمیگرده ! که خودتون میتونید تصور کنید که در صورتی که نیاز نداشته باشید به اون دیتا ثانویه چقدر میتونه در سیستم شما پرفورمنس هیت داشته باشه ! لود زودهنگام (Eager loading) لود صریح (Explicit loading) : به معنی اینکه دیتای نویگیشن پراپرتی بعدا به صورت خیلی صریح و مشخص توسط شما لود خواهد شد و در کوئری اول دیتا برای نویگشن پراپرتی به صورت خودکار لود نمیشه ولی شما هر نویگیشن پراپرتی که بخوایید رو انتخاب میکنید و برای اون کوئری جدا میفرستید و اطلاعات اونو دریافت میکنید و روی مدل اولیه ست میکنید ( یه سری داستان در مورد استیت های هر مدل هست که مشخص میکنه دیتای نویگیشن پراپرتی ها در چه زمانی لود شدن ، انشالله در مقاله بعدی در موردش حرف میزنیم ).لود صریح (Explicit loading)لود تنبل(Lazy loading) یا (Lazy Initialization): به معنی اینکه دیتای نویگیشن پراپرتی در کوئری اولیه لود نمیشه و از این جهت اگر ازش استفاده ای هم نداشته باشید بی جهت اطلاعات اضافی لود نکردید ! آآآمااا (ترکی بخونیدش ?) اولین بار که تلاش کنید برای لود کردن دیتا موجود در اون نویگیشن پراپرتی خود ORM براتون کوئری مناسبش رو ایجاد میکنه و در بکگراند اون دیتا رو لود میکنه و نهایتا روی مدلتون ست میکنه ولی شما متوجه این فرآیند نمیشید ! خوبی لیزی لودینگ اینکه پرفرمنس هیت بیخودی نداره ولی خب هرمدلی مزایا و معایب خودش رو داره که در جای مناسب بهش میپردازیم ! لود تنبل (Lazy loading) یا (Lazy Initialization)دقت کنید که پیشفرض EF در نسخه های قبلی روی Laze Loading بود و طبیعتا خود به خود فعال بود این روش ! ولی در نسخه EF Core برای فعال کردن این روش نیازمند استفاده از یک پکیج خاص هستید و باید حتما در هنگام ادد شدن سرویس دیتابیس کانتکس به نرم افزار ذکر کنید که میخوایید از این قابلیت استفاده کنید ! اصلا نگران نباشید ! ددوووشواری نداریم چون قراره خودم در مقاله بعدی که مربوط به lazy loading هست نحوه استفاده و نکاتش رو توضیح بدم ! مطالب این مجموعه مقالات مستقیم از داکیومنت رسمی مایکروسافت اومده !و سمپل ها رو هم میتونید از اینجا ببینید : AspNetCore GitHubMohammad Ehsan TabakhianMohammad Ehsan TabakhianThu, 28 Feb 2019 01:12:57 +0330