آشنایی با متدهای Safe و Idempotent در HTTP
متدهای Safe
در پروتکل HTTP بعضی از متدها به عنوان Safe شناخته میشوند. منظور از Safe متدی است که کاری جز باز گرداندن اطلاعات انجام نمی دهد. متدهای Safe نباید اطلاعات دتابیس را تغییر دهند. اجرای یک متد Safe نباید برای کاربر هیچ عواقبی داشته باشد یا وضعیت سرور را تغییر دهد. متد GET یک متد Safe است و نباید پشت آن کدی بنویسید که اطلاعات را تغییر یا حذف کند.
متدهای Idempotent
منظور از متد Idempotent این است که نتیجه ی اجرای آن در بار N ام باید با نتیجه ی اجرا در بار اول یکسان باشد. متدهای GET و PUT و DELETE شامل آن می شوند. هر وقت کاربر درخواست اجرای یک متد از نوع DELETE میدهد شما می توانید اطلاعات را حذف کنید و نتیجه را به کاربر برگردانید. اما باید برنامه را به شکلی طراحی کنید که وقتی دوباره همان متد را با همان مقادیر اجرا کند خروجی همانند مرحله ی اول به کاربر برگردد.
رعایت کردن قوانین HTTP یک مبنای مشترک به همه ی برنامه نویسان میدهد. به خصوص زمانی که وب سرویس طراحی می کنید و هزاران برنامه نویس دیگر قرار است از آن استفاده کنند باید بیش از همیشه به قوانید آن پایبند باشید تا پروژه ی شما استانداردهای یک سایت خوب را داشته باشد.
متدهای Safe
در پروتکل HTTP بعضی از متدها به عنوان Safe شناخته میشوند. منظور از Safe متدی است که کاری جز باز گرداندن اطلاعات انجام نمی دهد. متدهای Safe نباید اطلاعات دتابیس را تغییر دهند. اجرای یک متد Safe نباید برای کاربر هیچ عواقبی داشته باشد یا وضعیت سرور را تغییر دهد. متد GET یک متد Safe است و نباید پشت آن کدی بنویسید که اطلاعات را تغییر یا حذف کند.
متدهای Idempotent
منظور از متد Idempotent این است که نتیجه ی اجرای آن در بار N ام باید با نتیجه ی اجرا در بار اول یکسان باشد. متدهای GET و PUT و DELETE شامل آن می شوند. هر وقت کاربر درخواست اجرای یک متد از نوع DELETE میدهد شما می توانید اطلاعات را حذف کنید و نتیجه را به کاربر برگردانید. اما باید برنامه را به شکلی طراحی کنید که وقتی دوباره همان متد را با همان مقادیر اجرا کند خروجی همانند مرحله ی اول به کاربر برگردد.
رعایت کردن قوانین HTTP یک مبنای مشترک به همه ی برنامه نویسان میدهد. به خصوص زمانی که وب سرویس طراحی می کنید و هزاران برنامه نویس دیگر قرار است از آن استفاده کنند باید بیش از همیشه به قوانید آن پایبند باشید تا پروژه ی شما استانداردهای یک سایت خوب را داشته باشد.
آشنایی با الگوی MVVM
بسیاری از برنامه نویسان ASP با الگوی MVC آشنایی دارند. اما مدل MVVM که به معنی Model - View - ViewModel است کمتر مورد استفاده قرار میگیرد.
اولین نکته این است که پیاده سازی سایت با الگوی MVVM بر مبنای تکنولوژی ASP ممکن نیست.
در این الگو داده ها بین UI و ViewModel که چیزی شبیه همان کنترلر در mvc است گردش می کنند و بلا فاصله به دیتابیس منتقل نمی شوند.
تمامی سایت های SPA از این الگو استفاده می کنند. هر وقت از ابزای مانند knockout.js یا آنگولار استفاده می کنید یک برنامه ی جاوا اسکریپت وظیفه ی مدیریت و اعتبار سنجی داده ها را بر عهده میگیرد.
در این روش تغییرات در دیتا به صورت ظاهری تغییر میکنند اما در عمل به صورت یک ajax به سرور ارسال می شوند که معمولا در لحظه روی نمی دهد.
وقتی مجبور نیستید برای مدیریت اطلاعات آنها را بعد از هر تغییر به سرور ارسال کنید از ترافیک سرور کم می کنید و کمتر صفحه رفرش میشود. در نتیجه رابط کاربری روانتر کار میکند.
لازم نیست یک سایت برای همه ی قسمت ها از این الگو استفاده کند. بلکه اگر فقط برای صفحاتی که کاربر با آنها زیاد سرو کار دارد هم پیاده شود هم تاثیر بسیار مطلوبی در UX می گذارد.
یکی از بهترین ابزار برای پیاده سازی الگوی MVVM در سایت های ASP Core فریم ورک Vue.js است.
بسیاری از برنامه نویسان ASP با الگوی MVC آشنایی دارند. اما مدل MVVM که به معنی Model - View - ViewModel است کمتر مورد استفاده قرار میگیرد.
اولین نکته این است که پیاده سازی سایت با الگوی MVVM بر مبنای تکنولوژی ASP ممکن نیست.
در این الگو داده ها بین UI و ViewModel که چیزی شبیه همان کنترلر در mvc است گردش می کنند و بلا فاصله به دیتابیس منتقل نمی شوند.
تمامی سایت های SPA از این الگو استفاده می کنند. هر وقت از ابزای مانند knockout.js یا آنگولار استفاده می کنید یک برنامه ی جاوا اسکریپت وظیفه ی مدیریت و اعتبار سنجی داده ها را بر عهده میگیرد.
در این روش تغییرات در دیتا به صورت ظاهری تغییر میکنند اما در عمل به صورت یک ajax به سرور ارسال می شوند که معمولا در لحظه روی نمی دهد.
وقتی مجبور نیستید برای مدیریت اطلاعات آنها را بعد از هر تغییر به سرور ارسال کنید از ترافیک سرور کم می کنید و کمتر صفحه رفرش میشود. در نتیجه رابط کاربری روانتر کار میکند.
لازم نیست یک سایت برای همه ی قسمت ها از این الگو استفاده کند. بلکه اگر فقط برای صفحاتی که کاربر با آنها زیاد سرو کار دارد هم پیاده شود هم تاثیر بسیار مطلوبی در UX می گذارد.
یکی از بهترین ابزار برای پیاده سازی الگوی MVVM در سایت های ASP Core فریم ورک Vue.js است.
چرا جاوا اسکریپت؟
تکنولوژی های سمت سرور برای طراحی رابط کاربری ساخته نشده اند و ابزار مناسبی هم برای اینکار نیستند.
استفاده از جاوا اسکریپت می تواند تجربه ی کاربری سایت را چند برابر بهتر کند.
علاوه بر زیبایی استفاده از جاوااسکریپت از ترافیک سرور و پهنای باند شبکه هم کم میکند. وقتی از javascript استفاده می کنید فقط داده ها را دانلود می کنید که در مقایسه با تمام محتویات صفحه حجم به مراتب کمتری دارد.
وقتی وظایفی از قبیل جستجو، اعتبار سنجی و مرتب سازی را به جاوااسکریپت میسپارید از رم و پردازشگر کاربر کمک می گیرید. این کمک به حدی نیست که روی سیستم کاربر اثر منفی داشته باشد اما حجم بسیار بالایی از منابع سرور را آزاد میکند.
پیاده سازی سایت با ajax و وب سرویس پیچیده تر است و زمان بیشتری میبرد. اما هزینه ای است که در برابر نتیجه ی کار ارزشش را دارد.
تکنولوژی های سمت سرور برای طراحی رابط کاربری ساخته نشده اند و ابزار مناسبی هم برای اینکار نیستند.
استفاده از جاوا اسکریپت می تواند تجربه ی کاربری سایت را چند برابر بهتر کند.
علاوه بر زیبایی استفاده از جاوااسکریپت از ترافیک سرور و پهنای باند شبکه هم کم میکند. وقتی از javascript استفاده می کنید فقط داده ها را دانلود می کنید که در مقایسه با تمام محتویات صفحه حجم به مراتب کمتری دارد.
وقتی وظایفی از قبیل جستجو، اعتبار سنجی و مرتب سازی را به جاوااسکریپت میسپارید از رم و پردازشگر کاربر کمک می گیرید. این کمک به حدی نیست که روی سیستم کاربر اثر منفی داشته باشد اما حجم بسیار بالایی از منابع سرور را آزاد میکند.
پیاده سازی سایت با ajax و وب سرویس پیچیده تر است و زمان بیشتری میبرد. اما هزینه ای است که در برابر نتیجه ی کار ارزشش را دارد.
فرق بین 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 متغیر دینامیک است و پردازش آن زمان بیشتری میگیرد.