اشتراکها
نظرات مطالب
آشنایی با ذخیره سازی در حافظه
سلام و خدا قوت
آیا این درسته؟
آیا این درسته؟
در سیستمهای 32 بیتی Pagedpool توانایی 128 گیگ فضای آدرس دهی مجازی و در سیستمهای 64 بیتی توانایی 128 گیگ فضای آدرس دهی مجازی
نظرات مطالب
استفاده از چاپگرهای مجازی و چاپ فایل Doc
شما بسته به نیاز خود میتوانید هر چاپگری با هر قابلیتی را نصب و استفاده کنید. در این روش برای چاپ مطالب از چاپگر مجازی استفاده میشود. در خط 13-15 کد فوق از سه چاپگر مجازی دیگر استفاده شده که doPDF خروجی pdf تولید میکند.شاید سایت colorpilot و یا gemboxsoftware مفید واقع بشه.
تازهکار هستیم و هنوز از این تکنولوژیها استفاده نمیکنیم.
بهصورت محدود در برخی پروژهها از Kubernetes یا تکنولوژیهای مشابه استفاده میکنیم.
در برخی پروژهها از این تکنولوژیها برای مدیریت Docker استفاده میشود.
Kubernetes یا مشابه آن در پروژههای متعدد دات نت مورد استفاده قرار میگیرد.
در تمامی پروژههای دات نت ما از تکنولوژیهای اورکستراسیون برای مقیاسپذیری و مدیریت Docker استفاده میشود.
بهصورت محدود در برخی پروژهها از Kubernetes یا تکنولوژیهای مشابه استفاده میکنیم.
در برخی پروژهها از این تکنولوژیها برای مدیریت Docker استفاده میشود.
Kubernetes یا مشابه آن در پروژههای متعدد دات نت مورد استفاده قرار میگیرد.
در تمامی پروژههای دات نت ما از تکنولوژیهای اورکستراسیون برای مقیاسپذیری و مدیریت Docker استفاده میشود.
1- نیاز به تواناییهای موجود در برنامههای Desktop را دارید اما همچنین نیاز است تا آنها را تحت وب نیز ارائه دهید.
یکی از دلایل اقبال به برنامههای تحت وب در سازمانها عدم نیاز به نصب آنها و توزیع هر چه سادهتر اینگونه برنامهها در شبکه است. تنها کافی است چند فایل را بر روی سرور به روز رسانی کنید و پس از آن تمام کلاینتها از آخرین نگارش برنامه شما بهرهمند خواهند شد (+). توزیع برنامههای سیلورلایت نیز به همین منوال است. علاوه بر آن استفاده از فناورهایی مانند MEF امکان ماژولار ساختن برنامه و دریافت آخرین ماژولهای تهیه شده (فایلهای XAP مجزای از برنامه به صورت افزونه) را بر اساس انتخاب و سطح دسترسی کاربر نیز میسر میسازد.
2- نیاز است تا یک برنامهی گرافیکی تمام عیار را تحت وب ارائه دهید.
تواناییهای XAML به همراه یکی از زبانهای دات نت جهت خلق جلوههای بصری، پویانمایی و گرافیکی بسیار بسیار فراتر از کتابخانههای جاوا اسکریپتی موجود هستند و نکتهی مهم آنها هم این است که لازم نیست حتما یک متخصص مثلا جاوا اسکریپت باشید تا بتوانید برای مثال پویانمایی را ارائه دهید. امکان استفاده از انواع و اقسام قلمها و قرار دادن آنها در برنامه، امکان استفاده از گرافیک برداری و غیره را نیز لحاظ کنید.
3- برنامهی شما نیاز است تا از طریق وب توزیع شود اما نیاز به سطح دسترسی بیشتری نسبت به یک برنامهی وب معمولی دارد.
تمام برنامههای توزیع شده از طریق مرورگرها محدود به سطوح دسترسی آنها نیز هستند. اما امکان نصب خارج از مرورگر برنامههای سیلورلایت نیز وجود دارد. در این حالت میتوان در صورت نیاز و همچنین تائید صریح کاربر، به سطوح دسترسی بیشتری دست یافت. برای مثال دسترسی به اسکنر در یک برنامهی وب متداول بیمعنا است. اما سیلورلایت 4 در حالت اجرای در خارج از مرورگر امکان تعامل با اشیاء COM را نیز دارد.
4- برنامهی وب شما نیاز است تا مدت زمان زیادی فعال باقی بماند.
یک برنامه دریافت ایمیل یا یک برنامه مونیتورینگ را در نظر بگیرید. اینگونه برنامهها باید مرتبا بدون نیاز به دخالت کاربر، فعال باقی بمانند و با سرور ارتباط داشته باشند. نوشتن اینگونه برنامهها با HTML و جاوا اسکریپت و فناوریهای مشابه واقعا مشکل بوده و نیاز به دانش فنی بالایی دارند. اما این مساله و حیات یک برنامه سیلورلایت تا زمانیکه مرورگر بسته نشده است جزو خواص اولیه اینگونه برنامهها است.
5- از مشکلات مدیریت حالت در برنامههای متداول وب به تنگ آمدهاید.
اگر برای مثال برنامه نویس ASP.NET باشید حتما با مباحث State management آشنایی دارید (از سشن و کوکی گرفته تا ViewState (ایی که همه به نحوی قصد کوچک کردن آنرا دارند!) و غیره). تمام اینها هم برای این است که بتوان تجربهی کاری برنامههای دسکتاپ را در محیط مرورگرها شبیه سازی کرد. این مشکلات در سیلورلایت حل شده است. یک برنامهی سیلورلایت State full است نه Stateless . همچنین اگر از حافظهای هم استفاده میکند این مورد در سمت کاربر است و نه سمت سرور و نه منقضی شدن زود هنگام سشنها و صدها ترفند برای مقیاس پذیری همین مسالهی بسیار کوچک با تعداد کاربران بالا در برنامههای متداول وب.
به عبارتی تصور کنید که برنامهی دسکتاپ سالهای قبل شما هم اکنون داخل مرورگر دارد اجرا میشود و چیزی به نام وب سرور وجود ندارد که پس از نمایش صفحهی وب شما، کلیهی اشیاء مرتبط با آنرا در سمت سرور تخریب کند چون باید پاسخگوی کاربران همزمان بیشماری باشد و منابع سرور هم محدود است. (سیلورلایت یک فناوری سمت کاربر است. بنابراین وب سرور صرفا نقش توزیع آنرا به عهده دارد یا حداکثر ارائهی یک وب سرویس جهت تعاملات بعدی مانند کار با بانک اطلاعاتی)
6- نیاز دارید تا برنامهی وب شما تحت تمام مرورگرها به یک شکل به نظر برسد و همچنین رفتار یکسانی هم داشته باشد.
هیچ وقت روزی را فراموش نمیکنم که حین پرداخت الکترونیکی بانک XYZ به کمک مرورگر فایرفاکس، دکمهی پرداخت در مرحلهی آخر، کار نمیکرد! هر چقدر روی آن کلیک میکردم اتفاقی نمیافتاد! تراکنش برگشت خورد و همین خرید ساده با مرورگر IE به سادگی انجام شد.
با سیلورلایت این مشکلات را نخواهید داشت زیرا کار نمایش برنامه شما توسط افزونهی مربوطه صورت میگیرد و این افزونه مستقل است از نوع مرورگر شما.
7- نیاز است برنامهی وب شما در حالت آفلاین هم کار کند.
برنامههای سیلورلایت تنها زمانیکه نیاز به دریافت یا ثبت اطلاعاتی از سرور داشته باشند، باید آنلاین باشند. همچنین این برنامهها دسترسی به مفهوم جدیدی به نام Isolated Storage دارند که در آن میتوان اطلاعات را به ازای هر کاربر آن هم با ضریب امنیتی بالا بر روی هارد شخص ذخیره کرد و زمان آنلاین شدن برنامه آنها را به سرور انتقال داد.
8- برنامه وب شما نیاز است تا با فایلهای مالتی مدیا تعامل داشته و آنها را پخش کند.
حتی تگ Video در HTML5 نیز به پای تواناییهای مالتی مدیا در Silverlight مانند smooth streaming, multicasting, editing, video brushes نمیرسد. برای مثال با استفاده از video brushes میتوان یک فایل ویدیویی در حال پخش را بر روی یک وجه یک شیء در حال پویانمایی نقاشی و نمایش داد.
9- نیاز به پشتیبانی از multi-touch در برنامهی وب شما وجود دارد.
برخلاف HTML ، تعاملات multi-touch در Silverlight میسر است.
10- نیاز به ایجاد برنامههای بازی تحت وب دارید.
به طور قطع میتوان بازییهایی در حد Pong را با جاوا اسکریپت هم ایجاد کرد، اما اگر نیاز به تولید بازیهایی جدیتر وجود داشت برای مثال انتقال بازی Quake به محیط وب، Silverlight در این زمینه هم حرفهای زیادی برای گفتن دارد (+).
11- نیاز به تولید برنامهی دسکتاپ چند سکویی دارید.
سیلورلایت هم اکنون تحت ویندوز، MAC OS-X ، لینوکس و ... پشتیبانی میشود (+). همچنین برنامههای سیلورلایت قابلیت اجرای در خارج از مرورگر را هم دارند.
با سیلورلایت دیگر نیازی نخواهد بود تا کاربران لینوکسی ابتدا Wine را نصب کنند تا بتوانند از یک برنامهی ویندوزی که انتقال پذیر نیست در لینوکس هم بتوانند استفاده کنند؛ چون پروژهی مون لایت لینوکسی برای این منظور مهیا است.
12- نیاز به تولید برنامههای تحت وب سریع و با کارآیی بالا دارید.
فایلهای نهایی Silverlight با توجه به ماهیت کامپایل شدهی آنها به طور قطع از کدهای جاوا اسکریپتی سمت کلاینت که باید توسط مرورگر تفسیر و پردازش شوند (و هر کدام هم از موتور خاص خودشان استفاده میکنند)، سریعتر اجرا میشوند (+).
13- از پیچیدگیهای پیاده سازی برنامههای متداول وب خسته شدهاید.
هنوز هم با تمام پیشرفتهای حاصل، تولید برنامههای وب پیشرفته مشکل است. از یک طرف ناسازگاری یک سری از مرورگرها با یک سری از قابلیتها را باید در نظر داشت، تا فراگیری فریم ورکهای Ajax و غیره تا مشکل بودن طراحی کنترلهای جدید فراتر از آن چیزی که HTML استاندارد ارائه میدهد. بله، به طور قطع دانش فنی بالایی در این زمینه در طی سالیان تولید شده است، اما باز هم فراگیری و تسلط به آنها زمان قابل توجهی را طلب میکند.
در سیلورلایت کلیه تعاملات با شبکه به صورت پیش فرض غیرهمزمان است (همان ایدهی اصلی Ajax) همچنین با توجه به state full بودن اینگونه برنامهها، عملا برنامه نویسها بدون درگیر شدن با مفاهیم اجکسی و مدیریت حالت، برنامهی پیشرفتهی وبی را در مدت زمان کوتاهی تولید کردهاند و این برنامه در تمام مرورگرهایی که قابلیت بارگذاری افزونهی سیلورلایت را دارند به یک شکل و کیفیت اجرا میشود.
14- در زمینه میزان مصرف پهنای باند ملاحظاتی ویژهای وجود دارد.
یک برنامهی سیلورلایت تنها یکبار باید دریافت شود. پس از آن در سمت کاربر کش خواهد شد (تا زمان به روز رسانی بعدی برنامه در سرور). همین مساله در دفعات بعدی مراجعه کاربر به سایت نقش قابل توجهی را در کاهش میزان مصرف پهنای باند (یا به قولی میزان کمتر data transfer) کلی دارد.
15- فرصت کافی برای فراگیری انبوهی از فناوریهای مختلف را ندارید!
بله! برای ایجاد یک برنامهی تحت وب که کاربر آن پس از مشاهده بگوید WOW نیاز است به HTML ، JS ، CSS ، AJAX ، یکی از فناوریهای سمت سرور و ... مسلط بود (علاوه بر اینکه باید بدانید فلان کد JS در IE کار میکند اما در فایرفاکس خیر. فایرفاکس فلان قسمت CSS را پشتیبانی میکند اما IE خیر! و ...).
اما برای استفاده از سیلورلایت فقط کافی است به XAML و یکی از زبانهای دات نت مانند سی شارپ یا VB.NET مسلط باشید (البته هیچ وقت از دست ASP.NET خلاص نخواهید شد! حداقل در حد راه اندازی یک وب سرویس یا مفاهیم امنیتی آن).
این مورد خصوصا برای افرادی که برنامه نویس دسکتاپ هستند اما علاقمندند تا برنامهی وب نیز تولید کنند بسیار مهم است. با حداقل آموزش میتوانند تواناییهای خود را به وب نیز گسترش دهند. علاوه بر آن عمدهی دانش Silverlight شما جهت تولید برنامههای WPF (با توجه به اینکه Silverlight فرزند WPF محسوب میشود) یا Windows phone 7 و غیره نیز میتواند بکار گرفته شود.
16- نیاز به اجرای کدهای چند ریسمانی در سمت کاربر دارید.
تا این لحظه پشتیبانی رسمی از مباحث چند ریسمانی در JavaScript و استانداردهای مرتبط با آن وجود ندارد. Silverlight به اکثر امکانات Threading موجود در دات نت فریم ورک دسترسی داشته و دانش فعلی شما قابل انتقال است.
و دست آخر باید به نکته اشاره کرد که هدف از Silverlight ساخت وب سایت معمولی نیست. این نوع کارها را با همان ابزارهای متداول انجام دهید. هدف اصلی آن ساخت برنامه است (Application در مقابل Web site). مشتریهای اصلی این نوع برنامهها هم بیشتر سازمانها و اینترانتهای پر سرعت و بستهی آنها هستند که نه نگران حجم افزونهی سیلورلایت هستند و نه مشکلی با حجم برنامهی سیلورلایت شما در یک شبکهی داخلی پر سرعت دارند.
مطالب دورهها
متدهای async تقلبی
تا اینجا مشاهده کردیم که اگر یک چنین متد زمانبری را داشته باشیم که در آن عملیاتی طولانی انجام میشود،
برای نوشتن معادل async آن فقط کافی است که امضای متد را به async Task تغییر دهیم و سپس داخل آن از Task.Run استفاده کنیم:
و ... اگر از آن در یک کد UI استفاده کنیم، ترد آنرا قفل نکرده و برنامه، پاسخگوی سایر درخواستهای رسیده خواهد بود. اما ... به این روش اصطلاحا Fake Async گفته میشود؛ یا Async تقلبی!
کاری که در اینجا انجام شده، استفادهی ناصحیح از Task.Run در حین طراحی یک متد و یک API است. عملیات انجام شده در آن واقعا غیرهمزمان نیست و در زمان انجام آن، باز هم ترد جدید اختصاص داده شده را تا پایان عملیات قفل میکند. اینجا است که باید بین CPU-bound operations و IO-bound operations تفاوت قائل شد. اگر Entity Framework 6 و یا کلاس WebClient و امثال آن، متدهایی Async را نیز ارائه دادهاند، اینها به معنای واقعی کلمه، غیرهمزمان هستند و در آنها کوچکترین CPU-bound operation ایی انجام نمیشود.
در حلقهای که در مثال فوق در حال پردازش است و یا تمام اعمال انجام شده توسط CPU، از مرزهای سیستم عبور نمیکنیم. نه قرار است فایلی را ذخیره کنیم، نه با اینترنت سر و کار داشته باشیم و یا مثلا اطلاعاتی را از وب سرویسی دریافت کنیم و نه هیچگونه IO-bound operation خاصی قرار است صورت گیرد.
زمانیکه برنامه نویسی قرار است با API شما کار کند و به امضای async Task میرسد، فرضش بر این است که در این متد واقعا یک کار غیرهمزمان در حال انجام است. بنابراین جهت بالابردن کارآیی برنامه، این نسخه را نسبت به نمونهی غیرهمزمان انتخاب میکند.
حال تصور کنید که استفاده کننده از این API یک برنامهی دسکتاپ نیست، بلکه یک برنامهی ASP.NET است. در اینجا Task.Run فراخوانی شده صرفا سبب خواهد شد عملیات مدنظر، بر روی یک ترد دیگر، نسبت به ترد اصلی اختصاص داده شده توسط ASP.NET برای فراخوانی و پردازش CalculateXYZAsync، صورت گیرد. این عملیات بهینه نیست. تمام پردازشهای درخواستهای ASP.NET در تردهای خاص خود انجام میشوند. وجود ترد دوم ایجاد شده توسط Task.Run در اینجا چه حاصلی را بجز سوئیچ بیجهت بین تردها و همچنین بالا بردن میزان کار Garbage collector دارد؟ در این حالت نه تنها سبب بالا بردن مقیاس پذیری سیستم نشدهایم، بلکه میزان کار Garbage collector و همچنین سوئیچ بین تردهای مختلف را در Thread pool برنامه به شدت افزایش دادهایم. همچنین یک چنین سیستمی برای تدارک تردهای بیشتر و مدیریت آنها، مصرف حافظهی بیشتری نیز خواهد داشت.
یک اصل مهم در طراحی کدهای Async
استفاده از Task.Run در پیاده سازی بدنه متدهای غیرهمزمان، یک code smell محسوب میشود.
چکار باید کرد؟
اگر در کدهای خود اعمال Async واقعی دارید که IO-bound هستند، از معادلهای Async طراحی شده برای کار با آنها، مانند متد SaveChangesAsync در EF، متد DownloadStringTaskAsync کلاس WebClient و یا متدهای جدید Async کلاس Stream برای خواندن و نوشتن اطلاعات استفاده کنید. در یک چنین حالتی ارائه متدهای async Task بسیار مفید بوده و در جهت بالابردن مقیاس پذیری سیستم بسیار مؤثر واقع خواهند شد.
اما اگر کدهای شما صرفا قرار است بر روی CPU اجرا شوند و تنها محاسباتی هستند، اجازه دهید مصرف کننده تصمیم بگیرد که آیا لازم است از Task.Run برای فراخوانی متد ارائه شده در کدهای خود استفاده کند یا خیر. اگر برنامهی دسکتاپ است، این فراخوانی مفید بوده و سبب آزاد شدن ترد UI میشود. اگر برنامهی وب است، به هیچ عنوان نیازی به Task.Run نبوده و فراخوانی متداول آن با توجه به اینکه درخواستهای برنامههای ASP.NET در تردهای مجزایی اجرا میشوند، کفایت میکند.
به صورت خلاصه
از Task.Run در پیاده سازی بدنه متدهای API خود استفاده نکنید.
از Task.Run در صورت نیاز (مثلا در برنامههای دسکتاپ) در حین فراخوانی و استفاده از متدهای API ارائه شده استفاده نمائید:
در این مثال از همان نسخهی غیرهمزمان متد محاسباتی استفاده شدهاست و اینبار مصرف کننده است که تصمیم گرفته در حین فراخوانی و استفاده نهایی، برای آزاد سازی ترد UI از await Task.Run استفاده کند (یا خیر).
بنابراین نوشتن یک چنین کدهایی در پیاده سازی یک API غیرهمزمان
صرفا خود را گول زدن است. کل این عملیات بر روی CPU انجام شده و هیچگاه از مرزهای IO سیستم عبور نمیکند.
برای مطالعه بیشتر
Should I expose asynchronous wrappers for synchronous methods
class MyService { public int CalculateXYZ() { // Tons of work to do in here! for (int i = 0; i != 10000000; ++i) ; return 42; } }
class MyService { public async Task<int> CalculateXYZAsync() { return await Task.Run(() => { // Tons of work to do in here! for (int i = 0; i != 10000000; ++i) ; return 42; }); } }
کاری که در اینجا انجام شده، استفادهی ناصحیح از Task.Run در حین طراحی یک متد و یک API است. عملیات انجام شده در آن واقعا غیرهمزمان نیست و در زمان انجام آن، باز هم ترد جدید اختصاص داده شده را تا پایان عملیات قفل میکند. اینجا است که باید بین CPU-bound operations و IO-bound operations تفاوت قائل شد. اگر Entity Framework 6 و یا کلاس WebClient و امثال آن، متدهایی Async را نیز ارائه دادهاند، اینها به معنای واقعی کلمه، غیرهمزمان هستند و در آنها کوچکترین CPU-bound operation ایی انجام نمیشود.
در حلقهای که در مثال فوق در حال پردازش است و یا تمام اعمال انجام شده توسط CPU، از مرزهای سیستم عبور نمیکنیم. نه قرار است فایلی را ذخیره کنیم، نه با اینترنت سر و کار داشته باشیم و یا مثلا اطلاعاتی را از وب سرویسی دریافت کنیم و نه هیچگونه IO-bound operation خاصی قرار است صورت گیرد.
زمانیکه برنامه نویسی قرار است با API شما کار کند و به امضای async Task میرسد، فرضش بر این است که در این متد واقعا یک کار غیرهمزمان در حال انجام است. بنابراین جهت بالابردن کارآیی برنامه، این نسخه را نسبت به نمونهی غیرهمزمان انتخاب میکند.
حال تصور کنید که استفاده کننده از این API یک برنامهی دسکتاپ نیست، بلکه یک برنامهی ASP.NET است. در اینجا Task.Run فراخوانی شده صرفا سبب خواهد شد عملیات مدنظر، بر روی یک ترد دیگر، نسبت به ترد اصلی اختصاص داده شده توسط ASP.NET برای فراخوانی و پردازش CalculateXYZAsync، صورت گیرد. این عملیات بهینه نیست. تمام پردازشهای درخواستهای ASP.NET در تردهای خاص خود انجام میشوند. وجود ترد دوم ایجاد شده توسط Task.Run در اینجا چه حاصلی را بجز سوئیچ بیجهت بین تردها و همچنین بالا بردن میزان کار Garbage collector دارد؟ در این حالت نه تنها سبب بالا بردن مقیاس پذیری سیستم نشدهایم، بلکه میزان کار Garbage collector و همچنین سوئیچ بین تردهای مختلف را در Thread pool برنامه به شدت افزایش دادهایم. همچنین یک چنین سیستمی برای تدارک تردهای بیشتر و مدیریت آنها، مصرف حافظهی بیشتری نیز خواهد داشت.
یک اصل مهم در طراحی کدهای Async
استفاده از Task.Run در پیاده سازی بدنه متدهای غیرهمزمان، یک code smell محسوب میشود.
چکار باید کرد؟
اگر در کدهای خود اعمال Async واقعی دارید که IO-bound هستند، از معادلهای Async طراحی شده برای کار با آنها، مانند متد SaveChangesAsync در EF، متد DownloadStringTaskAsync کلاس WebClient و یا متدهای جدید Async کلاس Stream برای خواندن و نوشتن اطلاعات استفاده کنید. در یک چنین حالتی ارائه متدهای async Task بسیار مفید بوده و در جهت بالابردن مقیاس پذیری سیستم بسیار مؤثر واقع خواهند شد.
اما اگر کدهای شما صرفا قرار است بر روی CPU اجرا شوند و تنها محاسباتی هستند، اجازه دهید مصرف کننده تصمیم بگیرد که آیا لازم است از Task.Run برای فراخوانی متد ارائه شده در کدهای خود استفاده کند یا خیر. اگر برنامهی دسکتاپ است، این فراخوانی مفید بوده و سبب آزاد شدن ترد UI میشود. اگر برنامهی وب است، به هیچ عنوان نیازی به Task.Run نبوده و فراخوانی متداول آن با توجه به اینکه درخواستهای برنامههای ASP.NET در تردهای مجزایی اجرا میشوند، کفایت میکند.
به صورت خلاصه
از Task.Run در پیاده سازی بدنه متدهای API خود استفاده نکنید.
از Task.Run در صورت نیاز (مثلا در برنامههای دسکتاپ) در حین فراخوانی و استفاده از متدهای API ارائه شده استفاده نمائید:
private async void MyButton_Click(object sender, EventArgs e) { await Task.Run(() => myService.CalculateXYZ()); }
بنابراین نوشتن یک چنین کدهایی در پیاده سازی یک API غیرهمزمان
await Task.Run(() => { for (int i = 0; i != 10000000; ++i) ; });
برای مطالعه بیشتر
Should I expose asynchronous wrappers for synchronous methods
Auto Render Mode، آخرین حالت رندری است که به Blazor 8x اضافه شدهاست. اگر از Blazor Server استفاده کنیم، به یک آغاز سریع در برنامه خواهیم رسید، به همراه مقداری تاخیر جزئی، برای به روز رسانی UI؛ از این جهت که تعاملات صورت گرفته باید از طریق اتصال وبسوکت SignalR به سرور ارسال شده و منتظر نتیجهی نهایی، برای اعمال آن به صفحه شد و یا باید به مقیاس پذیری این اتصالات همزمان با تعداد کاربران بالا هم اندیشید. اگر از Blazor WASM استفاده کنیم، آغاز آن، اندکی کند خواهد بود تا فایلهای فریمورک و برنامه، به درون مرورگر کاربر منتقل شوند. اما پس از آن همهچیز بسیار سریع است؛ از این جهت که تعاملات با DOM، توسط مرورگر و در همان سمت کاربر مدیریت میشود.
اما ... چقدر خوب میشد که امکان ترکیب هردوی اینها با هم در یک برنامه وجود میداشت؛ یعنی داشتن یک آغاز سریع، به همراه تعاملات سریع با DOM. به همین جهت Auto Render Mode به Blazor 8x اضافه شدهاست.
نحوهی عملکرد حالت رندر تعاملی خودکار در Blazor 8x
زمانیکه از قرار است از Auto Render Mode استفاده شود، یعنی در نهایت به سراغ حالت رندر وباسمبلی رفتن؛ اما به شرطیکه که فریمورک، مطمئن شود میتواند تمام فایلهای مرتبط را خیلی سریع و در کمتر از 100 میلیثانیه تامین کند که عموما یک چنین حالتی به معنای از پیش دریافت کردن این فایلها و کش شده بودن آنها در مرورگر است. اما اگر یک چنین تضمینی وجود نداشته باشد، از همان ابتدای کار تصمیم میگیرد که باید کامپوننت را از طریق نگارش Blazor Server آن ارائه دهد، تا آغاز سریعی را سبب شود. در این بین هم در پشت صحنه (یعنی زمانیکه کاربر مشغول به کار با نگارش Blazor Server کامپوننت است)، شروع به دریافت فایلهای مرتبط با نگارش وباسمبلی کامپوننت و برنامه میشود تا آنها را کش کرده و برای بار بعدی بارگذاری صفحه و نمایش اطلاعات آن، به سرعت از آنها استفاده کند.
یک چنین حالتی برای کاربران به این معنا است که به محض گشودن برنامه و صفحهای، قادر به استفادهی از آن هستند و برای بارهای بعدی استفاده، دیگر نیازی به اتصال دائم SignalR یک جزیرهی تعاملی Blazor Server نداشته و در نتیجه بار کمتری به سرور تحمیل خواهد شد (مقیاس پذیری بیشتر) و همچنین پردازش DOM بسیار سریعتری را نیز شاهد خواهند بود (کار با نگارش Blazor WASM درون مرورگر).
همانطور که در این تصویر هم مشخص است، برای بار اول نمایش یک چنین جزیرههایی، یک اتصال وبسوکت برقرار میشود که به معنای فعال شدن حالت جزیرهای Blazor Server است که در قسمت پنجم بررسی کردیم. در این بین فایلهای Blazor WASM این جزیره هم دریافت و کش میشوند که در کنسول توسعه دهندههای مرورگر، لاگ شدهاست. این اتصال وبسوکت، در بار اول نمایش این کامپوننت، بسته نخواهد شد؛ تا زمانیکه کاربر به صفحهای دیگر مراجعه کند. در دفعهی بعدی که درخواست نمایش این صفحه را داشته باشیم، چون اطلاعات نگارش وباسمبلی آن کش شدهاست، از همان ابتدای کار نگارش وب اسمبلی را بارگذاری و راهاندازی میکند.
تفاوت قالب پروژههای Auto Render Mode با سایر حالتهای رندر در Blazor 8x
برای ایجاد قالب ابتدایی پروژهی یک چنین حالت رندری، از دستور dotnet new blazor --interactivity Auto استفاده میشود که حالت تعاملی آن به Auto تنظیم شدهاست. در نگاه اول، Solution ایجاد شدهی آن، بسیار شبیه به Solution جزیرههای تعاملی Blazor WASM است که در قسمت هفتم به همراه یک مثال کامل بررسی کردیم؛ یعنی از دو پروژهی سمت سرور و سمت کلاینت تشکیل میشود و دارای این تفاوتها است:
در فایل Program.cs پروژهی سمت سرور آن، افزوده شدن هر دو حالت جزایر تعاملی Blazor Server و همچنین Blazor WASM را مشاهده میکنیم:
یک چنین قالبی میتواند تمام موارد زیر را با هم در یک Solution پشتیبانی کند:
الف) امکان تعریف صفحات فقط SSR در پروژهی سمت سرور
ب) امکان داشتن جزیرههای تعاملی فقط Blazor Server در پروژهی سمت سرور
ج) امکان داشتن جزیرههای تعاملی فقط Blazor Wasm در پروژهی سمت کلاینت
د) به همراه امکان تعریف جزیرهای تعاملی Auto Render Mode در پروژهی سمت کلاینت
یک نکته: در این تنظیمات، متد AddAdditionalAssemblies، امکان استفاده از کامپوننتهای قرار گرفتهی در سایر اسمبلیها و پروژهها را میسر میکند.
نحوهی تعریف کامپوننتهایی که قرار است توسط Auto Render Mode ارائه شوند
باتوجه به اینکه این نوع کامپوننتها در نهایت قرار است به صورت وباسمبلی رندر شوند، آنها را باید در پروژهی سمت کلاینت قرار داد و به نکات مرتبط با توسعهی آنها که در قسمت هفتم پرداختیم، توجه داشت.
همچنین مانند سایر حالتهای رندر، به دو طریق میتوان مشخص کرد که یک کامپوننت باید به چه صورتی رندر شود:
الف) استفاده از دایرکتیو حالت رندر با مقدار InteractiveAuto در ابتدای تعریف یک کامپوننت
ب) مشخص کردن حالت رندر، در زمان استفاده از المان کامپوننت
البته به شرطیکه using static زیر را به فایل Imports.razor_ پروژه اضافه کرد:
اما ... چقدر خوب میشد که امکان ترکیب هردوی اینها با هم در یک برنامه وجود میداشت؛ یعنی داشتن یک آغاز سریع، به همراه تعاملات سریع با DOM. به همین جهت Auto Render Mode به Blazor 8x اضافه شدهاست.
نحوهی عملکرد حالت رندر تعاملی خودکار در Blazor 8x
زمانیکه از قرار است از Auto Render Mode استفاده شود، یعنی در نهایت به سراغ حالت رندر وباسمبلی رفتن؛ اما به شرطیکه که فریمورک، مطمئن شود میتواند تمام فایلهای مرتبط را خیلی سریع و در کمتر از 100 میلیثانیه تامین کند که عموما یک چنین حالتی به معنای از پیش دریافت کردن این فایلها و کش شده بودن آنها در مرورگر است. اما اگر یک چنین تضمینی وجود نداشته باشد، از همان ابتدای کار تصمیم میگیرد که باید کامپوننت را از طریق نگارش Blazor Server آن ارائه دهد، تا آغاز سریعی را سبب شود. در این بین هم در پشت صحنه (یعنی زمانیکه کاربر مشغول به کار با نگارش Blazor Server کامپوننت است)، شروع به دریافت فایلهای مرتبط با نگارش وباسمبلی کامپوننت و برنامه میشود تا آنها را کش کرده و برای بار بعدی بارگذاری صفحه و نمایش اطلاعات آن، به سرعت از آنها استفاده کند.
یک چنین حالتی برای کاربران به این معنا است که به محض گشودن برنامه و صفحهای، قادر به استفادهی از آن هستند و برای بارهای بعدی استفاده، دیگر نیازی به اتصال دائم SignalR یک جزیرهی تعاملی Blazor Server نداشته و در نتیجه بار کمتری به سرور تحمیل خواهد شد (مقیاس پذیری بیشتر) و همچنین پردازش DOM بسیار سریعتری را نیز شاهد خواهند بود (کار با نگارش Blazor WASM درون مرورگر).
همانطور که در این تصویر هم مشخص است، برای بار اول نمایش یک چنین جزیرههایی، یک اتصال وبسوکت برقرار میشود که به معنای فعال شدن حالت جزیرهای Blazor Server است که در قسمت پنجم بررسی کردیم. در این بین فایلهای Blazor WASM این جزیره هم دریافت و کش میشوند که در کنسول توسعه دهندههای مرورگر، لاگ شدهاست. این اتصال وبسوکت، در بار اول نمایش این کامپوننت، بسته نخواهد شد؛ تا زمانیکه کاربر به صفحهای دیگر مراجعه کند. در دفعهی بعدی که درخواست نمایش این صفحه را داشته باشیم، چون اطلاعات نگارش وباسمبلی آن کش شدهاست، از همان ابتدای کار نگارش وب اسمبلی را بارگذاری و راهاندازی میکند.
تفاوت قالب پروژههای Auto Render Mode با سایر حالتهای رندر در Blazor 8x
برای ایجاد قالب ابتدایی پروژهی یک چنین حالت رندری، از دستور dotnet new blazor --interactivity Auto استفاده میشود که حالت تعاملی آن به Auto تنظیم شدهاست. در نگاه اول، Solution ایجاد شدهی آن، بسیار شبیه به Solution جزیرههای تعاملی Blazor WASM است که در قسمت هفتم به همراه یک مثال کامل بررسی کردیم؛ یعنی از دو پروژهی سمت سرور و سمت کلاینت تشکیل میشود و دارای این تفاوتها است:
در فایل Program.cs پروژهی سمت سرور آن، افزوده شدن هر دو حالت جزایر تعاملی Blazor Server و همچنین Blazor WASM را مشاهده میکنیم:
// ... builder.Services.AddRazorComponents() .AddInteractiveServerComponents() .AddInteractiveWebAssemblyComponents(); // ... app.MapRazorComponents<App>() .AddInteractiveServerRenderMode() .AddInteractiveWebAssemblyRenderMode() .AddAdditionalAssemblies(typeof(Counter).Assembly);
الف) امکان تعریف صفحات فقط SSR در پروژهی سمت سرور
ب) امکان داشتن جزیرههای تعاملی فقط Blazor Server در پروژهی سمت سرور
ج) امکان داشتن جزیرههای تعاملی فقط Blazor Wasm در پروژهی سمت کلاینت
د) به همراه امکان تعریف جزیرهای تعاملی Auto Render Mode در پروژهی سمت کلاینت
یک نکته: در این تنظیمات، متد AddAdditionalAssemblies، امکان استفاده از کامپوننتهای قرار گرفتهی در سایر اسمبلیها و پروژهها را میسر میکند.
نحوهی تعریف کامپوننتهایی که قرار است توسط Auto Render Mode ارائه شوند
باتوجه به اینکه این نوع کامپوننتها در نهایت قرار است به صورت وباسمبلی رندر شوند، آنها را باید در پروژهی سمت کلاینت قرار داد و به نکات مرتبط با توسعهی آنها که در قسمت هفتم پرداختیم، توجه داشت.
همچنین مانند سایر حالتهای رندر، به دو طریق میتوان مشخص کرد که یک کامپوننت باید به چه صورتی رندر شود:
الف) استفاده از دایرکتیو حالت رندر با مقدار InteractiveAuto در ابتدای تعریف یک کامپوننت
@rendermode InteractiveAuto
<Banner @rendermode="@InteractiveAuto" Text="Hello"/>
@using static Microsoft.AspNetCore.Components.Web.RenderMode
نظرات اشتراکها
معرفی jQuery EasyUI
البته تم پذیری یکپارچه ای نداره
یه سری فایلهای عکس خارج از تم و امثالهم
یه سری فایلهای عکس خارج از تم و امثالهم