فرق بین Async و Sync
در برنامه نویسی وب همیشه توصیه میشود از متدهای Async استفاده کنید. معمولا پیاده سازی متدهای Async پیچیده تر است و کد نویسی آن زمان بیشتری می برد. در این روش منابع سرور به سرعت آزاد میشود و می تواند به Request های بیشتری پاسخ دهد.
استفاده از Async لزوما به معنی سریعتر شدن اجرای برنامه نیست. تضمینی وجود ندارد که متدهای Async در Thread مجزا اجرا شوند. در واقع Async یا برنامه نویسی موازی فرق دارد. در برنامه نویسی موازی سیستم عامل را مجبور می کنید از چند Thread مجزا برای اجرای چند عملیات استفاده کند اما در Async این انتخاب به عهده ی سیستم عامل است و اجباری وجود ندارد.
فرق اساسی Async با Sync در زمان اجرای دستورات است. در Sync یک درخواست بلافاصله اجرا می شود و بقیه سیستم باید منتظر پایان آن بماند. اما در Async درخواست به سیستم ارسال میشود و سیستم تضمین میدهد که پایان آن را در سریعترین زمان ممکن برگرداند اما اینکه دقیقا کی اجرا میشود را اعلام نمی کند.
از آنجا که زمان پایان در Async مشخص نیست Thread بعد از ارسال درخواست به سیستم بلافاصله آزاد میشود و می تواند Request جدیدی را دریافت کند. در واقع می توان گفت در سرور Sync منابع سیستم بعد از پایان یک Request آزاد میشود اما در Async بعد از شروع Request آزاد میشود. با این روش درخواستها زودتر در صف پیش میروند و احتمال اینکه درخواستی به علت زمان طولانی انتظار برگشت بخورد کمتر میشود.
در Async کار آهسته و پیوسته پیش میرود و همیشه حرکت رو به جلو وجود دارد. اما در Sync پیشرفت مقطعی است. وقتی ترافیک سرور بالا باشد عدم پیشرفت به خطای Server Time Out منجر میشود. در سرور Sync این حالت تا چند برابر (ضریب توانی) زودتر پیش می آید.
در برنامه نویسی وب همیشه توصیه میشود از متدهای Async استفاده کنید. معمولا پیاده سازی متدهای Async پیچیده تر است و کد نویسی آن زمان بیشتری می برد. در این روش منابع سرور به سرعت آزاد میشود و می تواند به Request های بیشتری پاسخ دهد.
استفاده از Async لزوما به معنی سریعتر شدن اجرای برنامه نیست. تضمینی وجود ندارد که متدهای Async در Thread مجزا اجرا شوند. در واقع Async یا برنامه نویسی موازی فرق دارد. در برنامه نویسی موازی سیستم عامل را مجبور می کنید از چند Thread مجزا برای اجرای چند عملیات استفاده کند اما در Async این انتخاب به عهده ی سیستم عامل است و اجباری وجود ندارد.
فرق اساسی Async با Sync در زمان اجرای دستورات است. در Sync یک درخواست بلافاصله اجرا می شود و بقیه سیستم باید منتظر پایان آن بماند. اما در Async درخواست به سیستم ارسال میشود و سیستم تضمین میدهد که پایان آن را در سریعترین زمان ممکن برگرداند اما اینکه دقیقا کی اجرا میشود را اعلام نمی کند.
از آنجا که زمان پایان در Async مشخص نیست Thread بعد از ارسال درخواست به سیستم بلافاصله آزاد میشود و می تواند Request جدیدی را دریافت کند. در واقع می توان گفت در سرور Sync منابع سیستم بعد از پایان یک Request آزاد میشود اما در Async بعد از شروع Request آزاد میشود. با این روش درخواستها زودتر در صف پیش میروند و احتمال اینکه درخواستی به علت زمان طولانی انتظار برگشت بخورد کمتر میشود.
در Async کار آهسته و پیوسته پیش میرود و همیشه حرکت رو به جلو وجود دارد. اما در Sync پیشرفت مقطعی است. وقتی ترافیک سرور بالا باشد عدم پیشرفت به خطای Server Time Out منجر میشود. در سرور Sync این حالت تا چند برابر (ضریب توانی) زودتر پیش می آید.
منظور از I/O Bound چیست ؟
فرض کنید برای تعوض کارت به بانک مراجعه می کنید. در بانک یک باجه برای تعویض کارت در نظر گرفته شده است. اول صبح است و شما اولین مشتری هستید. متصدی بانک قبل از انجام هر کاری به شما یک فرم می دهد که پر کنید. پر کردن فرم 5 دقیقه زمان می برد. در این مدت متصدی بیکار است . بعد از تکمیل فرم و تحویل آن به متصدی در کمتر از 1 دقیقه اطلاعات شما وارد سیستم شده و امور آن انجام میشود. سپس 5 دقیقه دیگر باید منتظر بمانید تا کارت جدید شما چاپ و آماده شود. در این مدت هم متصدی بانک بیکار است. کارت شما بعد از 11 دقیقه آماده میشود و می توانید بانک را ترک کنید.
در اینجا در دو مرحله متصدی بانک بیکار بود و منتظر ورود (پر کردن فرم) و یا خروج اطلاعات (چاپ کارت) بود. اما خود عملیات بانکی زمان بسیار کمتری گرفت. وقتی ورود و خروج اطلاعات از پردازش آن زمان به مراتب بیشتری میگیرد عملیات Input/Output Bound است. یعنی مدت زمان اجرای عملیات به مدت زمان ورود و خروج اطلاعات بستگی بیشتری دارد تا خود پردازش.
وقتی عملیات I/O Bound باشد استفاده از تکنیک Async می تواند بهره وری سیستم را افزایش دهد. فرض کنید در مثال بالا 4 نفر دیگر جهت تعویض کارت به بانک مراجعه کنند. اگر متصدی بانک از روش Sync استفاده کند همه ی آن 4 نفر باید منتظر پایان کار شما و افراد جلوتر در صف باشند. یعنی کل کارها در 55 دقیقه انجام میشود.
اما اگر کارها به روش Async انجام شود متصدی بانک بلافاصله بعد از آنکه فرم را به شما داد آزاد می شود و می تواند در مدت زمانی که شما فرم را پر می کنید درخواستهای 4 نفر دیگر را بررسی کند .
با روش Async کل کار در مدتی حدود 15 دقیقه انجام میشود و همه ی کارتها با اخلاف زمانی 1 دقیقه از هم تحویل میشود. در این روش مدت زمان واحد هر کار ثابت است و عملیات تعویض کارت همیشه 11 دقیقه طول میکشد. اما از آنجایی که متصدی بانک بجای بیکار بودن درخواستهای بعدی صف را شروع می کند در 4 برابر سرعت بیشتر کارها را انجام می دهد.
روش Async در عملیات های I/O Bound فوق العاده موثر عمل می کند. کار با دیتابیس و فایل در سرور از نوع I/O Bound است و همیشه می توانید از تکنیک Async برای بالا بردن بازدهی سرور استفاده کنید.
وقتی عملیات از نوع CPU Bound باشد استفاده از Async کمک زیادی نمی کند. در مثال بالا پردازش اطلاعات یعنی کاری که توسط متصدی بانک انجام میشود CPU bound است. معمولا عملیات های محاسباتی که درون CPU انجام میشود به خودی خود سریع است. در واقع CPU سریعترین بخش رایانه است و سخت بتوان از آن فراتر رفت یا آن را دور زد. بهترین راه بالا بردن بازدهی در این موارد استفاده از پردازشگرهای چند هسته ای است.
فرض کنید برای تعوض کارت به بانک مراجعه می کنید. در بانک یک باجه برای تعویض کارت در نظر گرفته شده است. اول صبح است و شما اولین مشتری هستید. متصدی بانک قبل از انجام هر کاری به شما یک فرم می دهد که پر کنید. پر کردن فرم 5 دقیقه زمان می برد. در این مدت متصدی بیکار است . بعد از تکمیل فرم و تحویل آن به متصدی در کمتر از 1 دقیقه اطلاعات شما وارد سیستم شده و امور آن انجام میشود. سپس 5 دقیقه دیگر باید منتظر بمانید تا کارت جدید شما چاپ و آماده شود. در این مدت هم متصدی بانک بیکار است. کارت شما بعد از 11 دقیقه آماده میشود و می توانید بانک را ترک کنید.
در اینجا در دو مرحله متصدی بانک بیکار بود و منتظر ورود (پر کردن فرم) و یا خروج اطلاعات (چاپ کارت) بود. اما خود عملیات بانکی زمان بسیار کمتری گرفت. وقتی ورود و خروج اطلاعات از پردازش آن زمان به مراتب بیشتری میگیرد عملیات Input/Output Bound است. یعنی مدت زمان اجرای عملیات به مدت زمان ورود و خروج اطلاعات بستگی بیشتری دارد تا خود پردازش.
وقتی عملیات I/O Bound باشد استفاده از تکنیک Async می تواند بهره وری سیستم را افزایش دهد. فرض کنید در مثال بالا 4 نفر دیگر جهت تعویض کارت به بانک مراجعه کنند. اگر متصدی بانک از روش Sync استفاده کند همه ی آن 4 نفر باید منتظر پایان کار شما و افراد جلوتر در صف باشند. یعنی کل کارها در 55 دقیقه انجام میشود.
اما اگر کارها به روش Async انجام شود متصدی بانک بلافاصله بعد از آنکه فرم را به شما داد آزاد می شود و می تواند در مدت زمانی که شما فرم را پر می کنید درخواستهای 4 نفر دیگر را بررسی کند .
با روش Async کل کار در مدتی حدود 15 دقیقه انجام میشود و همه ی کارتها با اخلاف زمانی 1 دقیقه از هم تحویل میشود. در این روش مدت زمان واحد هر کار ثابت است و عملیات تعویض کارت همیشه 11 دقیقه طول میکشد. اما از آنجایی که متصدی بانک بجای بیکار بودن درخواستهای بعدی صف را شروع می کند در 4 برابر سرعت بیشتر کارها را انجام می دهد.
روش Async در عملیات های I/O Bound فوق العاده موثر عمل می کند. کار با دیتابیس و فایل در سرور از نوع I/O Bound است و همیشه می توانید از تکنیک Async برای بالا بردن بازدهی سرور استفاده کنید.
وقتی عملیات از نوع CPU Bound باشد استفاده از Async کمک زیادی نمی کند. در مثال بالا پردازش اطلاعات یعنی کاری که توسط متصدی بانک انجام میشود CPU bound است. معمولا عملیات های محاسباتی که درون CPU انجام میشود به خودی خود سریع است. در واقع CPU سریعترین بخش رایانه است و سخت بتوان از آن فراتر رفت یا آن را دور زد. بهترین راه بالا بردن بازدهی در این موارد استفاده از پردازشگرهای چند هسته ای است.
آشنایی با فیلترهای ASP Core MVC
فیلترهای بخشی از فریم ورک MVC هستند و شامل خود ASP Core نمی شوند. قبل از اینکه درخواست به اکشن درون کنترلر برسد از فیلترها عبور می کند . فیلترهای به صورت Attribute به متدهای اکشن اضافه می شوند و می توانند جلوی اجرای اکشن را بگیرند یا داده های آن را تغییر دهند. همچنین فیلترها یی برای بعد از خروج اطلاعات از اکشن وجود دارد و می توانند ویو یا داده های خروجی از اکشن را تغییر دهند.
فیلتر Authorizetion
این فیلتر جهت امنیت و دسترسی استفاده میشود و قبل از سایر فیلترها اجرا میشود. در صورتی که کاربر دسترسی به اکشن مربوطه را نداشته باشد آن را به صفحه ی ورود Redirect می کند. معمولا از Identity برای تشخیص هویت استفاده میشود و نیازی به پیاده سازی این نوع فیلترها وجود ندارد.
فیلتر Resource
این فیلتر اطلاعات بعد از Authorization اجرا میشود و داده های خام درخواست و پاسخ را داراست. می توانید اطلاعات را قبل از آنکه وارد Model Binding شوند تغییر دهید. مثلا اگر اطلاعات مشخصات کاربر جاری را در مدل پر کنید اینجا جای خوبی است.
فیلتر Action
یکی از پر کاربرد ترین فیلترهاست. همه ی اطلاعات بلافاصله قبل و بعد از اکشن به این فیلتر میرود. اگر میخواهید اطلاعات را لوگ یا اعتبار سنجی کنید این گزینه ی شماست.
فیلتر Exception
هر وقت خطایی در اکشن یا فیلتر روی میدهد در این فیلتر می توانید آن را مدیریت کنید. در غیر این صورت اجرا نمی شود.
فیلتر Result
این فیلتر روی اطلاعات خروجی از اکشن اعمال میشود. مثلا می توانید فیلتری بنویسید که با توجه به درخواست کاربر اطلاعات خروجی را به صورت json یا xml یا فایل csv برگرداند بدون اینکه کدهای درون اکشن را تغییر دهید.
فیلترها قابلیت تزریق وابستگی دارند و می توانید درون فیلتر به دیتابیس دسترسی پیدا کنید. همچنین همه ی فیلترها به دو روش Async و Sync قابل پیاده سازی هستند.
استفاده از فیلترها روش خوبی برای حذف کدهای تکراری است و بخشی از معماری aspect-oriented programming است و خوب است تا می توانید از آنها بهره ببرید. با استفاده از فیلترها کدهای درون اکشن کم میشود و مدیریت کنترلرها ساده تر میشود.
فیلترهای بخشی از فریم ورک MVC هستند و شامل خود ASP Core نمی شوند. قبل از اینکه درخواست به اکشن درون کنترلر برسد از فیلترها عبور می کند . فیلترهای به صورت Attribute به متدهای اکشن اضافه می شوند و می توانند جلوی اجرای اکشن را بگیرند یا داده های آن را تغییر دهند. همچنین فیلترها یی برای بعد از خروج اطلاعات از اکشن وجود دارد و می توانند ویو یا داده های خروجی از اکشن را تغییر دهند.
فیلتر Authorizetion
این فیلتر جهت امنیت و دسترسی استفاده میشود و قبل از سایر فیلترها اجرا میشود. در صورتی که کاربر دسترسی به اکشن مربوطه را نداشته باشد آن را به صفحه ی ورود Redirect می کند. معمولا از Identity برای تشخیص هویت استفاده میشود و نیازی به پیاده سازی این نوع فیلترها وجود ندارد.
فیلتر Resource
این فیلتر اطلاعات بعد از Authorization اجرا میشود و داده های خام درخواست و پاسخ را داراست. می توانید اطلاعات را قبل از آنکه وارد Model Binding شوند تغییر دهید. مثلا اگر اطلاعات مشخصات کاربر جاری را در مدل پر کنید اینجا جای خوبی است.
فیلتر Action
یکی از پر کاربرد ترین فیلترهاست. همه ی اطلاعات بلافاصله قبل و بعد از اکشن به این فیلتر میرود. اگر میخواهید اطلاعات را لوگ یا اعتبار سنجی کنید این گزینه ی شماست.
فیلتر Exception
هر وقت خطایی در اکشن یا فیلتر روی میدهد در این فیلتر می توانید آن را مدیریت کنید. در غیر این صورت اجرا نمی شود.
فیلتر Result
این فیلتر روی اطلاعات خروجی از اکشن اعمال میشود. مثلا می توانید فیلتری بنویسید که با توجه به درخواست کاربر اطلاعات خروجی را به صورت json یا xml یا فایل csv برگرداند بدون اینکه کدهای درون اکشن را تغییر دهید.
فیلترها قابلیت تزریق وابستگی دارند و می توانید درون فیلتر به دیتابیس دسترسی پیدا کنید. همچنین همه ی فیلترها به دو روش Async و Sync قابل پیاده سازی هستند.
استفاده از فیلترها روش خوبی برای حذف کدهای تکراری است و بخشی از معماری aspect-oriented programming است و خوب است تا می توانید از آنها بهره ببرید. با استفاده از فیلترها کدهای درون اکشن کم میشود و مدیریت کنترلرها ساده تر میشود.
کانال Codehaks با 50 هزار بازدید در سالی که گذشت.
در سال جدید هم با ما در آپارات همراه باشید .
http://www.aparat.com/codehaks
در سال جدید هم با ما در آپارات همراه باشید .
http://www.aparat.com/codehaks
زنگ خطر برای مایکروسافت با آمدن Node.js به صدا در آمد. هر تکنولوژی ایراداتی دارد و ASP هم از این جدا نبود. گوگل با بازاریابی هوشمندانه موفق شد Node.js را بین برنامه نویسان وب به خصوص آنهایی که به سورس باز علاقه داشتند محبوب کند . خیلی از برنامه نویسان قدیمی ASP شروع به مهاجرت به Node کردند.
نود سبک بود و روی هر سیستم عاملی کار می کرد . فقط لازم بود جاوا اسکریپت بلد باشید تا کدهای سرور و کلاینت را بنویسید. گوگل با ترویج برنامه نویسی MEAN یا چهارگانه ی (MongoDb- ExpressJS- Angular- Nodejs ) سعی کرد پایه گذار روش جدیدی در طراحی سایت شود و PHP و ASP را پشت سر بگذارد.
اما برای خیلی ها که از ASP به Node رفتند تجربه ی موفقی حاصل نشد. در ASP بار اصلی به دوش Visual Studio به عنوان کاملترین IDE است. اما برای Node حتی Notepad هم کفایت می کند. چیزی که هم خوب است و هم بد. در Node ابزار خوبی برای کد نویسی روزانه وجود ندارد. کارهایی که در ASP به راحتی انجام میدهید در Node تبدیل به کابوس می شود. جاوا اسکریپت به عنوان زبانی که Strongly Typed نیست ، خطایابی را بسیار مشکلتر می کند. چیزی که در پروژه های بزرگ سمت سرور به وضوح خودش را نشان میدهد. برای پروژه های بزرگ باید TypeScript استفاده کنید که باز هم از محصولات مایکروسافت است.
برای برنامه نویسان تازه کار و آنهایی که با PHP سالها کار می کردند Nodejs بسیار جالب بود و ناگهان همه به سوی آن رو آوردند. با وجود اینکه ASP امتحان خود را پس داده بود و همه می دانستند در بزرگترین پروژه ها می توان روی ASP حساب کرد اما Node نو رسیده ای بود که همه دوستش داشتند.
اینجا بود که مایکروسافت تصمیم به پیاده سازی MVC 6 گرفت. قرار بود همه ی خوبی های Node را کنار امکانات ASP قرار دهند و نو رسیده ی تازه ای درست کنند. اولین قدم سورس باز شدن بود. بعد نوبت باز نویسی موتور پایه ASP رسید. اگر قرار بود تکنولوژی جدید مانند نود روی همه ی سیستم عامل ها کار کند باید دات نت جاری را کنار می گذاشتند.
بعد از دو سال کار اولین نسخه ی ASP جدید با نام Core منتشر شد. نام جدید هم به این معنی بود که تغییرات آنقدر زیاد هست که نمی توان آن را نسخه ی 6 نامید . در عین تازگی محصول جدید شباهت های زیادی با نسخه های قبلی داشت و ساختار در خیلی از جاها حفظ شده بود. از این رو آن را ASP Core نامیدند.
نود سبک بود و روی هر سیستم عاملی کار می کرد . فقط لازم بود جاوا اسکریپت بلد باشید تا کدهای سرور و کلاینت را بنویسید. گوگل با ترویج برنامه نویسی MEAN یا چهارگانه ی (MongoDb- ExpressJS- Angular- Nodejs ) سعی کرد پایه گذار روش جدیدی در طراحی سایت شود و PHP و ASP را پشت سر بگذارد.
اما برای خیلی ها که از ASP به Node رفتند تجربه ی موفقی حاصل نشد. در ASP بار اصلی به دوش Visual Studio به عنوان کاملترین IDE است. اما برای Node حتی Notepad هم کفایت می کند. چیزی که هم خوب است و هم بد. در Node ابزار خوبی برای کد نویسی روزانه وجود ندارد. کارهایی که در ASP به راحتی انجام میدهید در Node تبدیل به کابوس می شود. جاوا اسکریپت به عنوان زبانی که Strongly Typed نیست ، خطایابی را بسیار مشکلتر می کند. چیزی که در پروژه های بزرگ سمت سرور به وضوح خودش را نشان میدهد. برای پروژه های بزرگ باید TypeScript استفاده کنید که باز هم از محصولات مایکروسافت است.
برای برنامه نویسان تازه کار و آنهایی که با PHP سالها کار می کردند Nodejs بسیار جالب بود و ناگهان همه به سوی آن رو آوردند. با وجود اینکه ASP امتحان خود را پس داده بود و همه می دانستند در بزرگترین پروژه ها می توان روی ASP حساب کرد اما Node نو رسیده ای بود که همه دوستش داشتند.
اینجا بود که مایکروسافت تصمیم به پیاده سازی MVC 6 گرفت. قرار بود همه ی خوبی های Node را کنار امکانات ASP قرار دهند و نو رسیده ی تازه ای درست کنند. اولین قدم سورس باز شدن بود. بعد نوبت باز نویسی موتور پایه ASP رسید. اگر قرار بود تکنولوژی جدید مانند نود روی همه ی سیستم عامل ها کار کند باید دات نت جاری را کنار می گذاشتند.
بعد از دو سال کار اولین نسخه ی ASP جدید با نام Core منتشر شد. نام جدید هم به این معنی بود که تغییرات آنقدر زیاد هست که نمی توان آن را نسخه ی 6 نامید . در عین تازگی محصول جدید شباهت های زیادی با نسخه های قبلی داشت و ساختار در خیلی از جاها حفظ شده بود. از این رو آن را ASP Core نامیدند.
آشنایی با ViewData ، ViewBag و TempData
در محیط ASP Core هم مانند ASP MVC سه روش برای انتقال اطلاعات از کنترلر به ویو وجود دارد.
روش ViewData
این روش از قدیمی ترین تکنیک های گردش اطلاعات از کنترلر به ویو است. در این روش اطلاعات به صورت Weakly-Typed است و موقع تایپ کردن کدها از طرف VS راهنمایی دریافت نمی کنید (Intellisense). اطلاعات به صورت جفتهای Key-Value است و با فراخوانی کلید می توانید مقدار آن را مشاهده کنید. همه ی داده های Model هم درون ViewData قرار می گیرد. در حقیقا مدل در View ها از درون ViewData خوانده میشود. با این تفاوت که مدل Strongly-Typed است و شهروند درجه اول در محیط ویو است.
روش ViewBag
داده های درون ViewBag آینه تمام نما یا کپی کامل اطلاعات درون ViewData است. با این تفاوت که این کپی روی یک شی dynamic انجام گرفته است. شی dynamic در #C می تواند بعد از کامپایل تغییر کند و خصوصیات جدید دریافت کند. به همین دلیل نیاز نیست که خصوصیات مدل یا کلیدها را قبلا در کد تعریف کنید و می توانید آن را مستقیما بخوانید.
روش TempData
اطلاعات در این روش مانند دو روش قبل به صورت Key-Value دخیره میشود و می توانید هر نوع داده ای را ذخیره کنید اما حجم داده دارای محدودیت است و بهتر است از 500 بایت فراتر نرود. اطلاعات TempData در ASP Core رمز گذاری شده و درون Cookie ذخیره میشود. به این معنی که با تغییر مرورگر توسط کاربراز بین میرود. نکته ی مهم در مورد TempData این است که بلافاصله بعد از آنکه اطلاعات آن خوانده شد پاک میشود. از این روش برای ارسال اطلاعاتی که نیاز به نگه داری بلند مدت و یا هنگام Redirect استفاده میشود.
در نسخه Razor Pages امکان استفاده از ViewBag وجود ندارد و این امکان قرار نیست به آن اضافه شود. به طور کلی توصیه میشود همیشه از ViewData استفاده کنید چون ViewBag متغیر دینامیک است و پردازش آن زمان بیشتری میگیرد.
در محیط ASP Core هم مانند ASP MVC سه روش برای انتقال اطلاعات از کنترلر به ویو وجود دارد.
روش ViewData
این روش از قدیمی ترین تکنیک های گردش اطلاعات از کنترلر به ویو است. در این روش اطلاعات به صورت Weakly-Typed است و موقع تایپ کردن کدها از طرف VS راهنمایی دریافت نمی کنید (Intellisense). اطلاعات به صورت جفتهای Key-Value است و با فراخوانی کلید می توانید مقدار آن را مشاهده کنید. همه ی داده های Model هم درون ViewData قرار می گیرد. در حقیقا مدل در View ها از درون ViewData خوانده میشود. با این تفاوت که مدل Strongly-Typed است و شهروند درجه اول در محیط ویو است.
روش ViewBag
داده های درون ViewBag آینه تمام نما یا کپی کامل اطلاعات درون ViewData است. با این تفاوت که این کپی روی یک شی dynamic انجام گرفته است. شی dynamic در #C می تواند بعد از کامپایل تغییر کند و خصوصیات جدید دریافت کند. به همین دلیل نیاز نیست که خصوصیات مدل یا کلیدها را قبلا در کد تعریف کنید و می توانید آن را مستقیما بخوانید.
روش TempData
اطلاعات در این روش مانند دو روش قبل به صورت Key-Value دخیره میشود و می توانید هر نوع داده ای را ذخیره کنید اما حجم داده دارای محدودیت است و بهتر است از 500 بایت فراتر نرود. اطلاعات TempData در ASP Core رمز گذاری شده و درون Cookie ذخیره میشود. به این معنی که با تغییر مرورگر توسط کاربراز بین میرود. نکته ی مهم در مورد TempData این است که بلافاصله بعد از آنکه اطلاعات آن خوانده شد پاک میشود. از این روش برای ارسال اطلاعاتی که نیاز به نگه داری بلند مدت و یا هنگام Redirect استفاده میشود.
در نسخه Razor Pages امکان استفاده از ViewBag وجود ندارد و این امکان قرار نیست به آن اضافه شود. به طور کلی توصیه میشود همیشه از ViewData استفاده کنید چون ViewBag متغیر دینامیک است و پردازش آن زمان بیشتری میگیرد.
کتاب مختصر و مفید درباره ASP Core
این کتاب به زبان انگلیسی و در 124 صفحه تهیه شده و به صورت مختصر مفید شما را با مبانی برنامه نویسی در محیط ASP Core آشنا می کند. این کتاب به صورت رایگان است و شامل قوانین کپی رایت نمی شود. می توانید آن را از وبلاگ شخصی نویسنده دانلود کنید.
https://www.recaffeinate.co/book/
این کتاب به زبان انگلیسی و در 124 صفحه تهیه شده و به صورت مختصر مفید شما را با مبانی برنامه نویسی در محیط ASP Core آشنا می کند. این کتاب به صورت رایگان است و شامل قوانین کپی رایت نمی شود. می توانید آن را از وبلاگ شخصی نویسنده دانلود کنید.
https://www.recaffeinate.co/book/
recaffeinate.co
The Little ASP.NET Core Book
A friendly introduction to web programming and ASP.NET Core
در دنیای وب HTTP یک محیط State-less است و محلی برای ذخیره سازی موقعیت جاری ندارد. اطلاعات HTTP بین دو درخواست حفظ نمی شود. از این رو برای انتقال اطلاعات به Request های بعدی نیاز به ابزار کمکی داریم .
در ASP Core مانند نسخه های قبل امکان استفاده از Session وجود دارد. به طور پیش فرض اطلاعات Session در کوکی ذخیره میشود. مدت زمان پیش فرض برای نگه داری اطلاعات 20 دقیقه است که می توانید تغییر دهید. همچنین از آنجا اطلاعات در کوکی مرورگر نگه داری میشود اگر کاربر مرورگر خود را هنگام کار عوض کند اطلاعات Session از بین میرود.
روش دیگر ذخیره ی Session استفاده از حافظه ی سرور است. در این روش اطلاعات به صورت محلی در سرور ذخیره میشود. این روش بار بیشتری به سرور وارد می کند و آپدیت کردن و بروز رسانی سرور را مشکلتر میکند.
نباید اطلاعات محرمانه را در Session ذخیره کرد. همچنین اطلاعات آن مختص به یک کاربر نیست و ممکن است کاربر دیگر با استفاده از همان مرورگر بتواند از Session قبلی استفاده کند.
بر خلاف گذشته اطلاعات Session قفل نمی شود و هر درخواست جدید می تواند آن را تغییر دهد. در واقع اگر چند درخواست بخواهند اطلاعات Session را تغییر دهند آخرین درخواست برنده میشود.
استفاده از Session به طور کلی توصیه نمی شود و بهتر است تا می توانید از آن صرف نظر کنید. اما در ASP Core ابزار خوبی برای مدیریت Session وجود دارد.
در ASP Core مانند نسخه های قبل امکان استفاده از Session وجود دارد. به طور پیش فرض اطلاعات Session در کوکی ذخیره میشود. مدت زمان پیش فرض برای نگه داری اطلاعات 20 دقیقه است که می توانید تغییر دهید. همچنین از آنجا اطلاعات در کوکی مرورگر نگه داری میشود اگر کاربر مرورگر خود را هنگام کار عوض کند اطلاعات Session از بین میرود.
روش دیگر ذخیره ی Session استفاده از حافظه ی سرور است. در این روش اطلاعات به صورت محلی در سرور ذخیره میشود. این روش بار بیشتری به سرور وارد می کند و آپدیت کردن و بروز رسانی سرور را مشکلتر میکند.
نباید اطلاعات محرمانه را در Session ذخیره کرد. همچنین اطلاعات آن مختص به یک کاربر نیست و ممکن است کاربر دیگر با استفاده از همان مرورگر بتواند از Session قبلی استفاده کند.
بر خلاف گذشته اطلاعات Session قفل نمی شود و هر درخواست جدید می تواند آن را تغییر دهد. در واقع اگر چند درخواست بخواهند اطلاعات Session را تغییر دهند آخرین درخواست برنده میشود.
استفاده از Session به طور کلی توصیه نمی شود و بهتر است تا می توانید از آن صرف نظر کنید. اما در ASP Core ابزار خوبی برای مدیریت Session وجود دارد.