مقایسه معماری ASP.NET Web Forms و Blazor در توسعه وب اپلیکیشن ها

با قسمت پنجم از آموزش متنی و رایگان فریم ورک که Blazor از وب سایت پرووید در خدمت شما عزیزان هستیم .در ابتدای کار توصیه می‌کنیم که اگر قسمت های قبلی از این آموزش و مطالعه نکرده‌اید؛ حتماً این کار را انجام بدهید چرا که مطالعه کردن این مطالب برای درک هرچه بهتر مطالب این مقاله و مقاله های بعدی ضروری می باشند و قسمت‌های قبلی کمی در رابطه با فریم ورک ASP.NET Web Forms و ارتباط آن با Blazor صحبت کردیم. در این مقاله قصد داریم در رابطه با معماری فریم ورک های ASP.NET Web Forms و تفاوت آن با معماری فریم ورک Blazor کمی با یکدیگر صحبت کنیم. علاوه بر این توصیه می کنیم که در صورت تمایل از بسته ی آموزش ویدئویی شروع به کار با Blazor در ASP.NET Core و بسته ی آموزش ویدئویی بلیزر (Blazor) پیشرفته و ساخت برنامه های تجاری و بسته ی آموزش ویدئویی Authentication و Authorization در بلیزر (Blazor) وب سایت پرووید دیدن کنید.

علیرغم اینکه فریم ورک ASP.NET Web Forms و Blazor مفاهیم مشترک و مشابه بسیار زیادی دارند، تفاوت‌هایی نیز در آنها وجود دارد که در این مقاله می‌خواهیم در رابطه با معماری و عملکرد این دو فریم ورک صحبت کنیم .

بررسی فریم ورک ASP.NET Web Forms

همانطور که احتمالاً می‌دانید فریم ورک ASP.NET Web Forms یک فریم ورک مبتنی بر Page و یا اصطلاحاً Page-Centric می باشد، معماری اپلیکیشن های نوشته شده با استفاده از این فریم ورک نیز کاملاً به صورت Page-Centric عمل می‌کند. در رابطه با این فریم ورک می توانید از بسته ی آموزش ویدئویی ASP.NET Web Forms و Entity Framework در قالب پروژه دیدن کنید. درمعماری های Page-Centric هر Http Request برای یک Page منحصر به فرد در برنامه ارسال می گردد و با درخواست شدن هر کدام از این Page ها محتوای مربوطه به مرورگر ارسال شده و جایگزین محتوا می گردد که پیش‌تر در مرورگر قرار داده شده است. به طور کلی Page های مربوط به فریم ورک که ASP.NET از Component ها یا اجزای تشکیل دهنده زیر تشکیل گردیده اند:

  • HTML Markup
  • کدهای نوشته شده با زبان سی شارپ و ویژوال بیسیک
  • یک کلاس Code-Behind که شامل Logic و قابلیت‌های مربوط به این Event-Handling می باشد.
  • کنترل‌ها

احتمالاً می‌دانید که منظور از کنترل ها، واحدهای قابل استفاده مجدد است که با استفاده از آنها می توانید UI و یا واسط کاربری برنامه را ایجاد کنید تا کاربر بتواند با آنها تعامل برقرار کند. Page ها از فایل هایی با پسوند aspx تشکیل می گردند. این Page ها و یا فایل هایی که پسوند aspx دارند شامل Markup و کنترل‌ها و همچنین بخشی از کد برنامه هستند، علاوه بر این موضوع کلاسهای Code-Behind نیز فایل هایی هستند که در آنها کدهای سی شارپ و یا ویژوال بیسیک نوشته می شود. این فایل ها بر اساس زبان برنامه نویسی انتخاب شده پسوند .aspx.cs و .aspx.vb دارند. جالب است بدانید که وب سرور محتوای فایل های aspx را درک کرده و آنها را هر زمان که تغییر کنند کامپایل می‌کند، این کامپایل دوباره حتی اگر وب سرور در حال اجرا شدن باشد نیز رخ می دهد. علاوه بر این موضوع باید بدانید که کنترل ها با استفاده از Markup و یا همان کد های HTML نوشته می‌شوند و در قالب User Control های ارائه می‌گردند. در رابطه با HTML توصیه می‌کنیم که حتماً از بسته ی آموزش ویدئویی HTML5 دیدن کنید.

یک User Control از کلاس اصلی User Control ارث بری کرده و یک ساختار مشابه شبیه به یک Page را دارند. در رابطه با وراثت نیز توصیه می‌کنیم حتماً از بسته ی آموزش ویدئویی شی گرایی در سی شارپ وب سایت دیدن کنید. کدهای مربوط به Markup برای User Control ها در یک فایل با پسوند ascx ذخیره می‌شوند علاوه بر این یک کلاس Code-Behind در کنار این فایل ها قرار می گیرد که پسوند ascx.cs و یا ascx.vb خواهد داشت. کنترل ها می توانند به طور کامل توسط کد نوشته بشوند و یا با ارث بری از کلاس های Web Control و یا Composite Control ایجاد بگردند.

علاوه بر این موضوع ها Page ها یک Event Lifecycle و یا چرخه حیات Event ها را نیز در خود دارند. هر Page در زمان ایجاد شدن و یا Initialization ، بارگذاری و یا Load، پیش Render و یا PreRender در و Unload شدن اقدام به ایجاد کردن Event های می‌کند که توسط Runtime مربوط به ASP.NET اجرا گردیده و کدهای مختلفی در پاسخ به آن ها اجرا می شوند. در رابطه با این موضوع توصیه می‌کنیم حتماً از رویدادها (Event ها) در سی شارپ دیدن کنید.

کنترل های موجود بر روی یک Page به طور معمول به همان Page یکسان اصطلاحاً Post-Back می‌کردند و اطلاعاتی را در قالب یک Payload و درون یک فیلد به نام View State که به سمت سرور ارسال می‌کند. فیلد View State شامل اطلاعاتی در رابطه با State و یا حالت کنترل ها در زمان Render شدنشان و همچنین بارگذاری شدن ‌Page می باشند. اطلاعات در آن View State به فریم ورک ASP.NET Web Forms و Runtime مربوطه به کمک می‌کند تا تغییرات ایجاد شده را تشخیص داده و محتوای مربوط به داده های سرور را به روز رسانی کند.

فریم ورک Blazor

حال که با معماری ASP.NET Web Forms آشنا شدیم بهتر است که کمی نیز در رابطه با فریم ورک به Blazor صحبت کنیم. همانطور که در قسمت های قبلی نیز خدمتتان عرض شد فریم ورک Blazor یک Client-Side Web UI می باشد، به عبارت دیگر از Blazor برای ساخت واسط کاربری برنامه های وب در سمت کلاینت استفاده می‌شود. از این جهت فریم ورک Blazor شبیه به زبان برنامه نویسی JavaScript و فریم ورک هایی از قبیل Angular و React عمل می‌کند. برای یادگیری Angular و React توصیه می‌کنیم از بسته ی آموزش ویدئویی شروع به کار با Angular 2 و بسته ی آموزش ویدئویی شروع به کار با React.js دیدن کنید.

بلازرها تعاملات کاربر را Handle کرده و به روزرسانی های لازم را بر روی UI برنامه انجام می‌دهند. دقت کنید که Blazor مبتنی بر مدل Request-Reply نیست، در واقع تعاملات کاربر با برنامه‌هایی که با Blazor ایجاد شده اند در قالب Event هایی مدیریت می‌شوند که Event ها بخشی از Context مربوط به هیچ Http Request خاصی نیست.

به طور کلی برنامه هایی که با Blazor ایجاد می شوند شامل Root Components می باشند؛ در واقع Root Component ها مکان هایی هستند که یک Page از نوع HTML در آنها قرار می‌گیرند. تصویر زیر این موضوع را نشان می‌دهد:

این که چگونه یک کاربر مشخص کند که Component ها چگونه باید UI برنامه را Render کنند توسط Hosting Model و یا مدل میزبانی که در قسمت های بعدی از آن صحبت می‌کنیم، اتفاق می افتند. علاوه بر این در Blazor مفهوم Component را نیز داریم که از ترجمه کردن این واژه در این قسمت جلوگیری می‌کنیم؛ چرا که در فضای برنامه نویسی با Blazor این واژه بهتر است که ترجمه نگردد، در واقع در Blazor مفهوم Component چیزی به جز کلاس های ساده .Net که نمایانگر یک جزء قابل استفاده مجدد واسط کاربری برنامه هستند، نمی باشند. هر Component State خاص خود را دارد و Rendering logic منحصر به فرد خود را نیز، در خود قرار داده است. در واقع Componentها می توانند Componentهای دیگر را نیز Render کنند.

در Component ها می توان Event handlers برای تعاملات خاص کاربر لحاظ کرد و State مربوط به Component را با استفاده از آنها به روزرسانی نمود. زمانی که یک Component یک Event را Handle می‌کند در واقع Blazor Component مورد نظر را Render کرده و تغییرات رخ داده در خروجی را رصد می‌کند. دقت کنید که Component ها به طور مستقیم بر روی DOM و یا Document Object Model رندر نمی شوند، در عوض آنها به یک نمایش درون حافظه از DOM به نام Render Tree رندر می‌شوند، این موضوع باعث می‌شود تا Blazor بتواند به سادگی تغییرات رخ داده بر روی برنامه را رصد کند. Blazor محتوای Render شده جدید را با محتوای قبلی مقایسه کرده و یک UI Diff و یا تفاوت واسطه کاربری را کشف کرده و آنها را به صورت مؤثر و کارآمد و سریع بر روی DOM اعمال می کند. این موضوع در تصویر زیر نشان داده شده است:

علاوه بر این موضوع یک Component می‌تواند تصمیم بگیرد که زمانیکه State آن خارج از یک UI Event معمول تغییر می‌کند یک بار دیگر Render بشود. در Blazor از یک Synchronization Context به منظور ایجاد کردن یک Thread Of Execution منطقی تک استفاده می شود، منظور از Thread Of Execution همان نخ اجرا است که در بحث فرایندهای سیستم عامل اهمیت پیدا می‌کند. متدهای مربوط به چرخه حیات و یا Lifecycle یک Component و البته Event Callback هایی که توسط Blazor اصطلاحاً Raised می شوند بر روی این Synchronization Context ایجاد می‌کردند. در رابطه با تمامی این مفاهیم در قسمت های بعدی از این آموزش به طور مفصل تری صحبت خواهیم کرد. در پایان نیز توصیه می کنیم که در صورت تمایل از بسته ی آموزش ویدئویی شروع به کار با Blazor در ASP.NET Core و بسته ی آموزش ویدئویی بلیزر (Blazor) پیشرفته و ساخت برنامه های تجاری و بسته ی آموزش ویدئویی Authentication و Authorization در بلیزر (Blazor) وبسایت پرووید دیدن کنید.