اپلیکیشن هایی که با استفاده از Blazor تولید می‌شوند می‌توانند به دو صورت زیر میزبانی بشوند:

• به صورت Client-Side و اجرا شدن در مرورگر کاربر بر اساس استاندارد WebAssembly

• به صورت Server-Side در یک اپلیکیشن ASP.NET Core

در ادامه بررسی روش اول میزبانی اپلیکیشن‌های Blazor خواهیم پرداخت و روش بعدی را در قسمت بعدی بررسی خواهیم کرد.

اپلیکیشن‌های Blazor WebAssembly

اپلیکیشن‌های Blazor WebAssembly به طور مستقیم در مرورگر کاربر و بر اساس .NET Runtime مبتنی بر استاندارد WebAssembly اجرا می‌شوند. اپلیکیشن‌های Blazor WebAssembly عملکردی مشابه با اپلیکیشن های ایجاد شده به وسیله فریم ورک های جاوا اسکریپت از قبیل Angular و یا React دیگر خواهند داشت. در رابطه با این دو تکنولوژی می توانید از بسته ی آموزش ویدئویی شروع به کار با Angular 2 و بسته ی آموزش ویدئویی شروع به کار با React.js استفاده کنید.

با این وجود طبیعتاً در اپلیکیشن‌های Blazor به جای نوشتن کدهای جاوا اسکریپت کدهای سی شارپ نوشته می شوند در این نوع از اپلیکیشن ها .NET Runtime به طور مستقیم به همراه اسمبلی های مربوط به اپلیکیشن و دیگری Dependency به درون مرورگر کاربر دانلود می شود. برای اجرایی کردن این نوع از اپلیکیشن ها نیاز به پلاگین و یا Extension خاصی در مرورگر نداریم. این موضوع را با سیلورلایت که تکنولوژی سابق مایکروسافت بود مقایسه کنید، در سیلورلایت نیاز به نصب کردن پلاگین اضافه داشتیم. در رابطه با این تکنولوژی می توانید از بسته ی آموزش ویدئویی سیلورلایت 5 استفاده کنید.

اسمبلی های دانلود شده در واقع اسمبلی های معمول .NET می باشند به عبارت دیگر هر گونه اسمبلی که به سادگی می توانید در دیگر اپلیکیشن‌های .NET ایجاد کنید شبیه به چنین اسمبلی هایی خواهند بود از آنجایی که Runtime به سادگی از .NET Standard پشتیبانی می‌کند، می‌توانید از کتابخانه‌های از قبل وجود .NET Standard در اپلیکیشن‌های Blazor WebAssembly استفاده کنید. با این وجود این اسمبلی ها هنوز هم در Sandbox امنیتی مرورگر اجرا خواهند شد، این موضوع بدین معناست که در بعضی از موارد و در صورت تمایل به دسترسی پیدا کردن به برخی از قابلیت های سیستم کاربر از قبیل فایل سیستم و یا ارتباطات شبکه یک Exception از نوع Platform Not Supported Exception دریافت خواهید کرد. به منظور درک هرچه بهتر مکانیزم‌های مدیریت استثنا می توانید از بسته ی آموزش ویدئویی مدیریت خطاها در سی شارپ با Exception Handling استفاده کنید.

زمانی که اپلیکیشن‌های Blazor WebAssembly بارگذاری می شوند .NET Runtime کار خود را آغاز کرده و به اسمبلی اپلیکیشن مورد نظر اشاره می کند، پس از آن کد مربوط به Startup اپلیکیشن اجرا شده و Root Component ها به سادگی Render خواهند شد و در نهایت به Blazor به روزرسانی های مربوط به جای برنامه را بر اساس خروجی های Render شده محاسبه کرده و این آپدیت ها را بر روی DOM اعمال خواهد کرد این موضوع در تصویر زیر نشان داده شده است :

دقت کنید که اپلیکیشن‌های Blazor WebAssembly می‌توانند به طور کامل به صورت Client-Side اجرا بشوند چنین اپلیکیشن‌هایی می‌توانند به سادگی در که به صورت Static میزبانی را انجام می دهند نیز بارگذاری شوند. دو مثال از این موارد را به GitHub Pages و Azure Static Website Hosting می‌باشند. در رابطه با GitHub می توانید از بسته ی آموزش ویدئویی گیت هاب (GitHub) و مبانی استفاده کردن از آن استفاده کنید.

دقت کنید که در این نوع از اپلیکیشن ها به هیچ وجه نیاز به داشتن .Net در سرور ندارید علاوه بر این عملیات Deep Linking به قسمت های مختلف اپلیکیشن نیاز به پیاده‌سازی کردن یک سیستم Routing بر روی سرور است این سیستم Routing می‌تواند Request ها را به Root مربوط به اپلیکیشن ارسال کند. برای مثال عملیات Redirection می‌تواند با استفاده از قوانین URL Rewrite در IIS پیاده‌سازی بشود. برای به دست آوردن تمامی مزیت های مربوط به تکنولوژی Blazor و توسعه نرم‌افزارهای و به صورت Full-Stack با استفاده از .Net به سادگی می بایست که اپلیکیشن‌های Blazor WebAssembly را در یک اپلیکیشن از نوع ASP.NET Core قرارداد با استفاده از .Net بر روی Client و Server شما می توانید بسادگی کدهای مشترک را استفاده کرده و اپلیکیشن را با استفاده از مجموعه ای از زبان‌ها، فریم ورک ها و ابزارهای یکسان ایجاد کنید؛ ضمناً Blazor الگوهای ساده ای را برای راه اندازی کردن یک Solution که هم شامل Blazor WebAssembly و هم شامل ASP.NET Core باشد را در اختیار شما قرار می دهد. زمانی که این Solution ایجاد بشود Static File های مربوط به اپلیکیشن Blazor در اپلیکیشن ASP.NET Core میزبانی می شوند و علاوه بر این مکانیزم Fallback Routing نیز در آنها پیاده‌سازی خواهند شد. بحث ما در این قسمت را به پایان می رسانیم و در قسمت بعدی در رابطه با اپلیکیشن های Blazor Server صحبت خواهیم کرد.

علیرغم اینکه فریم ورک 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) وبسایت پرووید دیدن کنید.

استاندارد WebAssembly چیست؟

در سال ۲۰۱۵ کمپانی های مطرح ایجاد مرورگرهای وب در W3C Community Group گرد هم آمدند و یک استاندارد وب باز و یا اصطلاحاً Open Web Standard را به نام به WebAssembly مطرح نمودند. در واقع WebAssembly شبیه به Byte Code برای وب عمل می کند اگر شما بتوانید کد خود را به WebAssembly تبدیل کنید سپس می توانید آن را بر روی پلتفرم های مختلف و مرورگرهای مختلف به سادگی اجرا کنید. تلاش های اولیه در استاندارد WebAssembly برای زبان های C و C++ بود. با استفاده از WebAssembly شما می توانید بدون نیاز به نصب کردن پلاگین اضافه در مرورگر خود کدهای مورد نظرتان را اجرا کنید. این موضوع را می‌توان با تکنولوژی سیلورلایت که برای استفاده کردن از آن نیاز به نصب‌کردن پلاگین اضافه داشتید، مقایسه کرد. ضمناً در این رابطه توصیه می کنیم از بسته ی آموزش ویدئویی سیلورلایت 5 دیدن کنید.

از زمان مطرح شدن WebAssembly تا به اکنون این استاندارد در حال استانداردسازی و پیاده سازی در تمامی مرورگرهای اصلی می باشد. بنابراین کار کردن با WebAssembly و اجرا کردن کد های .Net در مرورگر های مختلف در اواخر سال ۲۰۱۷ آغاز شد، هم اکنون به سادگی می‌توان کدهای .Net را در مرورگر اجرا نمود. پیش‌بینی می‌شود که با مطرح شدن و انتشار .Net ۵ در سال ۲۰۲۰ این قابلیت تکمیل بگردد بنابراین با استفاده از این موضوع امکان توسعه نرم افزارهای وب به صورت Full-Stack وجود خواهد داشت . در این رابطه توصیه می کنیم از بسته ی آموزش ویدئویی تبدیل شدن به یک توسعه دهنده Full-stack در دات نت سری اول و بسته ی آموزش ویدئویی تبدیل شدن به یک توسعه دهنده Full-stack در دات نت سری دوم و بسته ی آموزش ویدئویی تبدیل شدن به یک توسعه دهنده Full-stack در دات نت سری سوم دیدن بفرمایید.

معرفی Blazor : توسعه نرم افزار های وب به صورت Full-Stack با استفاده از دات نت

به طور کلی قابلیت اجرا کردن کدهای .Net در یک مرورگر تجربه توسعه نرم افزار های وب سمت کلاینت را برای ما رقم نمیزند. به همین دلیل است که فریم ورک Blazor مطرح شد. در واقع فریم ورک Blazor یک Client-Side Web UI است ، که مبتنی بر زبان برنامه نویسی سی شارپ و نه جاوا اسکریپت عمل می‌کند. به عبارت دیگر با استفاده از Blazor و زبان برنامه نویسی سی شارپ؛ شما می توانید کدهای مربوط به واسط کاربری برنامه را در سمت Client این بار با زبان برنامه نویسی سی شارپ ایجاد کنید. برای اجرا کردن کدهای Blazor نیازی به نصب کردن هیچ پلاگین اضافه در مرورگر ندارید و این کدها با استفاده از استاندارد به WebAssembly اجرا خواهند شد. بطور جایگزین اپلیکیشن هایی که با استفاده از Blazor نوشته می‌شوند، می‌توانند به صورت Server-Side بر روی .Net Core نیز اجرا بشود و تمامی تعاملات کاربر با این نوع از برنامه های Blazor توسط یک Connection از نوع SignalR به سمت سرور ارسال می گردد. در رابطه با SignalR توصیه می‌کنیم از بسته ی آموزش ویدئویی شروع به کار با ASP.NET Core و SignalR دیدن بفرمایید.

خوشبختانه فریم ورک که به Blazor به صورت کامل در ویژوال استودیو و ویژوال استودیو کد پشتیبانی می شود. برای یادگیری ویژوال استودیو توصیه می‌کنیم از لینک بسته ویژوال استودیو دیدن کنید. علاوه بر این موضوع Component های متعددی برای ساختن UI ی مربوط به اپلیکیشن های وب در Blazor وجود دارد که برخی از آنها شامل موارد زیر می باشد:

• ایجاد کردن فرم ها و پیاده سازی validation
• پیاده سازی Dependency injection
• پیاده سازی Client-side routing
• کار کردن با Layouts
• پیاده‌سازی In-browser debugging
• قابلیت JavaScript interop

بلزرها مشترکات زیادی با فریم ورک و تکنولوژی ASP.NET Web Forms دارند. هر دو این فریم ورک ها به صورت Component-Based, Event-Driven و البته Stateful عمل می‌کند. در این قسمت از ترجمه کردن این سه واژه جلوگیری می‌کنیم؛ چرا که هر سه از واژه‌های فنی توسعه نرم افزارهای تحت وب به حساب می آیند . علاوه بر این هر دو این تکنولوژی ها با استفاده از یک واسط کاربری و یا UI کار برنامه را پیش می‌برند. تفاوت اصلی در فریم ورک ASP.NET Web Forms و Blazor از لحاظ معماری آنها می باشد، به عبارت دیگر بر اینکه ASP.NET Web Forms فقط بر روی سرور اجرا می‌شود و این در حالی است که برنامه های Blazor می تواند هم در مرورگر و هم در سرور اجرا شود. اما به طور کلی اگر تجربه کار کردن با فریم ورک ASP.NET Web Forms را دارید خواهید دید که در تکنولوژی Blazor همه چیز تقریباً شبیه به ASP.NET Web Forms می باشند. در واقع بر اینکه Blazor یک راه حل کاملاً طبیعی برای برنامه نویسی ASP.NET Web Forms می‌باشد که تلاش می‌کنند از Client-Side Development و همچنین Open-Source بودند و Cross-Platform بودن .Net استفاده کنند.

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

شروع به کار با Blazor

ضمناً برای شروع به کار با فریم ورک Blazor به سادگی می توانید به آدرس http://blazor.net بروید و .Net Core SDK و البته پروژه Template های مربوط به پروژه‌های Blazor را نصب کنید. دستورالعمل های راه اندازی Blazor در ویژوال استودیو و ویژوال استودیو کد نیز در همین وب سایت قرار داده شده اند.

توسعه تحت وب در سمت کلاینت

احتمالاً می‌دانید که تمامی فریم ورک های توسعه نرم‌افزارهای به مبتنی بر .Net از قبل ASP.NET Web Forms یک موضوع مشترک داشتند و آن هم این که اصطلاحاً همگی آنها Server-Rendered بودند، حال در رابطه با ماهیت Server-Rendered بودن صحبت خواهیم کرد. در اپلیکیشن‌های وبه صورت Server-Rendered عمل می‌کنند زمانی که یک مرورگر یک Request را به سمت سرور ارسال می‌کند کدهایی در سمت سرور اجرا خواهد شد. برای مثال کدهایی که با فریم ورک .Net و تکنولوژی ASP.NET Web Forms نوشته شدند، این موضوع باعث ایجاد شدن یک Response و یا پاسخ می گردد؛ حال این Response به مرورگر کاربر ارسال می شود در چنین مدل فرآیندی مرورگر به عنوان یک موتور Render کردن خروجی و یا اصطلاحاً Rendering Engine ایفای نقش می‌کند. علاوه بر این ذکر این موضوع نیز ضروری است که کار اصلی ایجاد کردن UI و یا واسط کاربری برنامه و سپس از اجرا کردن Business Logic و همچنین مدیریت کردن state، همگی در سمت سرور اتفاق می‌افتند. حال قرار است که کمی در رابطه با توسعه نرم‌افزارهای وب سمت Client صحبت کنیم.

احتمالاً می‌دانید که امروز مرورگرهای وب رفته‌رفته پیشرفته تر شدند و بسیاری از قابلیت های جدید را در خود پیاده سازی نمودند. قابلیت های جدید از قبیل استانداردهای باز وب امکان دسترسی پیدا کردن یک وب اپلیکیشن را به بسیاری از قابلیت های ماشین Client می دهند، بنابراین چرا نباید از موضوعاتی از قبیل قدرت محاسباتی، فضای ذخیره سازی، حافظه و دیگر منابع مربوط به دستگاه Client استفاده کرد. به عبارت دیگر قابلیت‌های مربوط به UI Interaction و یا تعاملات کاربر با واسط کاربری برنامه می‌تواند در سمت Client اتفاق بیفتند و یا بخشی از آن در سمت سرور و بخشی از آن در سمت Client مدیریت و Handle بگردد. در واقع به طور کلی می‌توان Logic و Data ی مربوطه به آن را در سرور نگهداری کرد و اصطلاحاً Server-Side عمل نمود و علاوه بر این Web API ها و فراخوانی های مربوطه با استفاده از تکنولوژی‌های از قبیل Web Sockets را مورد استفاده قرار داد. این مزیت‌ها می‌توانند به برنامه نویسان وب انعطاف‌پذیری بیشتری بدهند. احتمالاً می دانید که در این راستا زبان جاوا اسکریپت یکی از محبوب ترین زبان ها به حساب می‌آیند. ضمناً در رابطه با این موضوع می توانید از آموزش متنی جاوا اسکریپت و برنامه نویسی وب و بسته ی آموزش ویدئویی جاوا اسکریپت دیدن کنید.

علاوه بر جاوا اسکریپت امروزه فریم ورک های مختلفی برای مدیریت کردن UI ی سمت Client مطرح شدند از آنها شامل Angular و React و Vue.js می باشند که برای تمامی این ها آموزش‌های بر روی وبسایت پرووید از قبیل آموزش ویدئویی توسعه وب با انگولار جی اس (AngularJS) و بسته ی آموزش ویدئویی شروع به کار با React.js و بسته ی آموزش ویدئویی شروع به کار با Vue.js روی او منتشر شدند. این ابزارها به شما کمک می کند تا بتوانید توسعه سمت Client را به طور بهتر و دقیق تر انجام بدهیم.

برنامه نویسانی که با تکنولوژی ASP.NET Web Forms عمل می‌کنند می‌توانند از نوشتن کدهای که در سمت Client اجرا می شوند نیز استفاده کنند. برخی از این قابلیت ها در ASP.NET Ajax که به عنوان یکی از فریم ورک های جاوا اسکریپت در ASP.NET Web Forms قرار داده شده است ، قابل پیاده سازی هستند. اما حقیقت موضوع این است که مرتبط کردن دو فریم ورک کاملا مختلف یعنی .Net و جاوااسکریپت هزینه زیادی را خواهد داشت. برای مثال برنامه نویسان باید به طور موازی در هر دوی این پلتفرم ها و زبان ‌های مربوطه و البته ابزارها، مهارت ها و تجارب کافی داشته باشند کدهای نوشته شده نمی‌تواند به طور مشترک بین Client و Server به اشتراک گذاشته شوند و این موضوع خود می‌تواند باعث Code Duplication و یا کدهای تکراری و همچنین سربار مهندسی بگردند. در رابطه با Code Duplication و موضوعات مربوط به آن توصیه می‌کنیم که از بسته ی آموزش ویدئویی ریفکتورینگ در سی شارپ استفاده کنید.

بنابراین برای ما کمی دشوار است که فریم ورک .Net را با فضای مربوط به جاوا اسکریپت که یک سابقه طولانی را در پشت سر خود دارد مرتبط کنیم. فریم ورک های توسعه نرم‌افزارهای وب front-end و ابزارهای مورد استفاده در آنها امروزه به طور مرتب در حال تکامل و تغییر هستند، برای مثال هایی از قبیل Grunt و Gulp و Angular و React و Vue.js هم یکی از ابزارهایی هستند که امروز برای توسعه وب سمت Client از آنها استفاده می شوند. ابزارهای دیگری از قبیل jQuery و Knockout نیز از این قضیه مستثنی نیستند. در رابطه با jQuery و Knockout نیز توصیه می کنیم از آموزش ویدئویی توسعه وب با جی کوئری (jQuery) برای آموزش ویدئویی شروع به کار و ساخت پروژه عملی با Knockoutjs استفاده کنید.

ممکن است که از خود بپرسید آیا به جای استفاده کردن از جاوا اسکریپت در فضای یک مرورگر امکان دیگری نیز وجود دارد؟ خوشبختانه امروز جواب این سوال بله است چرا که با استفاده از Blazor و دانش شما در سی شارپ و فریم ورک .Net می توانید کدهای را بنویسید که در مرورگر کاربر اجرا بشوند در رابطه با این موضوع و موضوعات مرتبط با آن در قسمت بعدی از این آموزش به طور مفصل صحبت خواهیم کرد.

نسخه Open-Source و Cross-Platform .Net فریم ورک

زمانی که اولین بار فریم ورک که .Net و ASP.NET Web Forms توسط مایکروسافت معرفی شدند به طور کلی توسعه نرم افزارهای تحت وب و تحت ویندوز توسط محصولات مایکروسافت قبضه می شدند، دیگر پلتفرم ها از قبیل macOS و لینوکس شبیه به امروز محبوب نبودند بنابراین ASP.NET Web Forms به همراه .Net فریم ورک به عنوان یک ابزار برای توسعه نرم افزارهای تحت وب در ویندوز معرفی شد، این بدان معناست که برنامه هایی که با استفاده از ASP.NET Web Forms توسعه داده می شوند فقط امکان اجرا شدن بر روی ماشین های ویندوز سرور را دارند. بسیاری از محیط های مدرن امروزه از دیگر پلتفرم های مشابه برای سرورها و ماشین های توسعه استفاده می کند به همین دلیل داشتن ابزارهایی برای توسعه Cross-Platform و یا چند سکویی یک موضوع بسیار مهم به حساب می آیند. در این رابطه توصیه می کنیم از این بسته ی آموزش ویدئویی .NET Core برای برنامه نویسان ویندوز استفاده کنید.

بسیاری از فریم ورک های توسعه نرم افزارهای تحت وب امروز به صورت Open-source عمل می‌کنند متن باز بودن و یا همان Open-Source بودن مزایای متعددی را دارد، یکی از این مزایا این است که برنامه نویسان دیگر توسط یک مالک تک یعنی همان شرکت توسعه دهنده فریم ورک محدود نمی‌شوند و منتظر نمی ماند که ویژگی ها و قابلیت های جدیدی توسط آن شرکت اضافه گردد. پروژه‌های Open-Source می‌توانند به سادگی پیشرفت‌های خود را از جامعه برنامه نویسانی که بر روی آن فریم ورک کار می‌کنند دریافت کنند و این بدان معناست که روند رشد پروژه های Open-Source سریعتر از پروژه های معمولی است.البته در پروژه های Open-source نیز چالش ها و موضوعات دیگری مطرح می شوند که می‌بایست به طور ویژه به آنها دقت کرد تا بتوان به صورت ایمن و قابل درک پروژه Open-Source مورد نظر را پیشرفت داد، برای مثال بحث‌های مربوط به License Agreement و Friendly License ها و Pedigree Scans ها و موضوعاتی از این دست مباحثی هستند که در توسعه نرم افزارها به صورت Open-Source مطرح می‌شوند.

جامعه نویسان .Net مفاهیم مربوط به پروژه‌های Open-Source و Cross-Platform را به طور ویژه پشتیبانی کرده و هم اکنون فریم ورک .NET Core یک پیاده سازی Cross-Platform و Open-Source از .Net فریم ورک می باشد که می تواند بر روی پلتفرم های مختلف از قبیل ویندوز و macOS و لینوکس اجرا بگردد. در این رابطه توصیه می‌کنیم از آموزش ویدئویی مباحث مقدماتی و شروع به کار ASP.NET Core MVC استفاده کنید.

علاوه بر این می دانید که فریم ورک Xamarin این با استفاده از Mono که یک نسخه Open-Source از .Net می باشد. امروزه می‌تواند پروژه‌های را ایجاد کند که بر روی اندروید و iOS و دیگر دستگاه‌های موبایل اجرا بشوند. در رابطه با Xamarin و Xamarin Forms نیز آموزش‌های زیادی بر روی وبسایت پرووید قرار گرفتند که برای مثال می توانید از بسته ی آموزش ویدئویی پروژه محور ساخت اپلیکیشن پیشرفته موبایل با Xamarin.Forms دیدن کنید.

مایکروسافت با معرفی کردن نسخه پنجم از .Net این موضوع را بیان کرد که .Net Core و Mono تبدیل به یک فریم ورک بر Runtime تک خواهند شد که می‌توانند به طور ویژه برای ساخت نرم‌افزارهای Open-Source و Cross-Platform مورد استفاده قرار بگیرند. حال سوالی که مطرح می‌شود این است که آیا فریم ورک ASP.NET Web Forms نیز می تواند از این روند رو به رشد در پروژه های Open-Source و Cross-Platform استفاده کند؟ متأسفانه پاسخ این سوال خیر است، چرا که در حال حاضر امکان انجام این کار وجود ندارد. تیم توسعه .Net امروزه اعلام کرده است که ASP.NET Web Forms به .NET Core و یا .NET Framework 5 منتقل نخواهد شد. سوالی که اینجا ممکن است پیش بیاید این است که چرا؟ دقت کنید که تلاش‌های زیادی در ابتدای ظهور .NET Core برای منتقل کردن ASP.NET Web Forms به آن صورت گرفت، اما نیاز به تغییرات کلی و بسیاری موضوعات دیگر باعث شد که مایکروسافت تصمیم بگیرد که عملاً این اتفاق رخ ندهد. علاوه بر این موضوع ممکن است که برنامه نویسان جامعه .Net به طور داوطلبانه اقدام به منتقل کردن کدهای ASP.NET Web Forms به .NET Core کنند. احتمالاً می‌دانید که Source-Code فریم ورک ASP.NET Web Forms امروزه به صورت عمومی منتشر شده و کاملا Open-source می باشند. ضمناً در این رابطه توصیه می‌کنیم حتماً از بسته ی آموزش ویدئویی گیت هاب (GitHub) و مبانی استفاده کردن از آن استفاده بفرمایید. اما در حال حاضر فریم ورک ASP.NET Web Forms فقط یک فریم ورک ویندوزی باقی خواهد ماند و هیچ قابلیت Open-Source خاصی در آن پیاده سازی نخواهد شد.

اگر به طور ویژه پیاده سازی پروژه به صورت Open-Source و Cross-Platform برای شما اهمیت دارد، نیاز است که به نسخه های دیگر این فریم ورک فکر کنید. حال سوالی که در پایان مطرح می‌شود این است که آیا فریم ورک ASP.NET Web Forms عمر خود را کرده است و حال دیگر نمی توان از آن استفاده کرد؟ البته که پاسخ این سوال خیر است تا زمانی که فریم ورک دادن به عنوان یک جزء تشکیل دهنده و یا Component با ویندوز منتشر بشود فریم ورک ASP.NET Web Forms به هم در کنار آن منتشر خواهد شد. برای بسیاری از برنامه نویسان وب نداشتن قابلیت Cross-Platform و Open-Source مشکلی را ایجاد نخواهد کرد. بنابراین اگر شما عملاً نیاز به Cross-Platform و یا Open-Source پروژه ندارید و یا به قابلیت های .NET Core و یا .NET Framework 5 اهمیت نمی دهید، استفاده کردن از فریم ورک ASP.NET Web Forms برای ویندوز یک انتخاب عاقلانه خواهد بود. فریم ورک ASP.NET Web Forms به روشی پایدار برای توسعه نرم افزار های وب تا سال‌های دیگر به عمر خود ادامه خواهد داد. در قسمت بعد از این آموزش در رابطه با اهمیت اجرا شدن بخشی از کد برنامه در سمت کلاینت صحبت خواهیم کرد.

احتمالاً می‌دانید که با استفاده از فریم ورک ASP.NET Web Forms به‌سادگی می‌توان Web Page ها را با استفاده از کنترل های واسط کاربری و یا اصطلاحاً UI Controller های قابل استفاده مجدد ایجاد کرد. قابلیت استفاده مجدد یکی از موضوعات بسیار مهم است که با پیاده‌سازی الگوهای طراحی می توان به آن دستیافت و برای یادگیری الگوهای طراحی نیز توصیه می کنیم از بسته ی آموزش ویدئویی Design Pattern ها در سی شارپ استفاده کنید.

علاوه بر راحتی در توسعه واسط کاربری برنامه های تحت وب با استفاده از ASP.NET Web Forms، به سادگی تعاملات مربوط به کاربر در قالب Event ها مدیریت می شدند. در رابطه با Event ها نیز می توانید از آموزش ویدئویی کار با رویدادها (Event) در سی شارپ استفاده کنید.

احتمالاً می‌دانید که برای فریم ورک ASP.NET Web Forms کنترل‌های متعدد و متنوعی به منظور توسعه UI برنامه توسعه داده شدند، این کنترل ها به سادگی می توانند کارهای معمول مربوط به نرم افزار های تحت وب از قبیل کار کردن با Data Source ها و نشان دادن داده های مختلف و البته اعتبارسنجی را برای ما انجام بدهند. ضمناً برای آن دسته از برنامه نویسانی که بیشتر به صورت ویژوال و یا بصری توسعه نرم‌افزار را دنبال می‌کنند، این موضوع که می‌توان به صورت درگ و دراپ یا Drag and Drop واسط کاربری را ساخت که یک موضوع جالب و البته راحت به حساب می آیند. اما پس از گذشت سال‌ها مایکروسافت دات نت فریمورک های مختلف دیگری را برای توسعه نرم افزارهای تحت وب که مبتنی بر ASP.NET Web Forms بودند معرفی کرد. برخی از این فریم ورک های توسعه نرم‌افزارهای وب شامل ASP.NET MVC و ASP.NET Web Pages و ASP.NET Core می‌باشند. در رابطه با یادگیری ASP.NET MVC می توانید از بسته ی آموزش ویدئویی ASP.NET MVC و Entity Framework در قالب پروژه استفاده کنید. ضمناً برای یادگیری ASP.NET Core نیز آموزش های زیادی بر روی وب سایت پرووید قرار گرفتند که دو مورد از مهمترین آنها، آموزش ویدئویی مباحث مقدماتی و شروع به کار ASP.NET Core MVC و بسته بسته ی آموزش ویدئویی ساخت اولین وب اپلیکیشن با ASP.NET Core MVC می باشد.

علی رغم این که فریم ورک های مختلفی برای توسعه نرم افزارهای تحت وب موجود بودند فریم‌ورک ASP.NET Web Forms توانست به روند رشد خود و مورد استفاده قرار گرفتند ادامه بدهد. البته بسیاری پیش بینی می کردند که تعداد زیادی از برنامه نویسان ASP.NET Web Forms به عنوان یک Version ساده و پایدار برای توسعه نرم‌افزارهای وب استفاده خواهند کرد. در حال حاضر که این مقاله را می نویسیم تقریباً بیش از نیم میلیون از توسعه دهندگان برنامه های وب از فریم ورک ASP.NET Web Forms استفاده می‌کنند. فریم ورک ASP.NET Web Forms بسیار پایدار است و دارای مستندات، کتاب ها، نمونه کد ها و بسیاری مطالب آموزشی دیگر می باشد که بسیار حائز اهمیت هستند.

برای بسیاری از توسعه دهندگان وب ASP.NET هنوز هم به معنی تکنولوژی ASP.NET Web Forms است. البته در رابطه با مزایا و معایب تکنولوژی ASP.NET Web Forms با دیگر تکنولوژی های توسعه نرم افزار های وب می‌توان به طور مفصل صحبت کرد که فعلاً وارد آن نمی شویم اما فقط این را بدانید که فریم ورک ASP.NET Web Forms به عنوان یک فریم ورک محبوب برای توسعه نرم افزارهای تحت وب مورد استفاده قرار می گیرد. البته موضوع بسیار مهم این که امروزه با محبوب شدن فریم ورک Open-Source و Cross-Platform و البته تمایل به اجرا کردن حجمی از کد مربوط به برنامه در Client اتفاق های متعددی برای فریم ورک های توسعه نرم‌افزارهای وب رخ داده است که در قسمت بعدی در رابطه با آن صحبت خواهیم کرد.

فریم ورک Blazor چیست؟

 همانطور که احتمالاً می‌دانید Blazor به شما اجازه می دهد تا بتوانید UI های مربوط به برنامه‌های وب خود را به صورت تعاملی و interactive با استفاده از زبان برنامه نویسی سی شارپ به جای استفاده کردن از زبان برنامه نویسی جاوا اسکریپت ایجاد کنید. این موضوع به تمامی برنامه نویسانی که تجربه توسعه دادن نرم افزار با استفاده از زبان برنامه نویسی سی شارپ را دارند یک خبر بسیار خوب خواهد بود. با استفاده از اپلیکیشن های Blazor شما می توانید کدهای مربوط به برنامه وب خود را به صورت reusable و یا قابل استفاده مجدد ایجاد کنید. این موضوع با لحاظ کردن کامپوننت ها با استفاده از کدهای زبان برنامه نویسی سی شارپ و  HTML و CSS ایجاد خواهد شد. در واقع با استفاده از Blazor هم کدهای سمت Server و هم کدهای سمت Client با زبان سی شارپ نوشته خواهند شد. این موضوع به شما این امکان را می دهد تا کدها و کتابخانه های خود را به ساده ترین شکل ممکن به اشتراک بگذارید.

فریم ورک Blazor یکی از قابلیت های ASP.NET به عنوان یک فریم ورک محبوب توسعه اپلیکیشن های وب به حساب می آید. این فریم ورک با استفاده از ابزارها و کتابخانه‌ های خود امروزه توانسته است به عنوان یکی از محبوب ترین ابزارهای ساخت اپلیکیشن های وب مورد استفاده قرار بگیرد. برای یادگیری ASP.NET Web Forms می توانید از بسته ی آموزش ویدئویی ASP.NET Web Forms و Entity Framework در قالب پروژه استفاده کنید.

اجرا کردن Blazor بر روی WebAssembly و یا بر روی سرور

جالب است که بدانید می توانید به سادگی اپلیکیشن‌های Blazor را به‌صورت client-side و با استفاده از کدهای سی شارپ و به صورت کاملاً درونی در مرورگر اجرا کنید. این موضوع با استفاده از WebAssembly اتفاق می افتد. در واقع با استفاده از این کار شما می توانید کدهای خود را مورد استفاده مجدد قرار داده و همچنین بخش هایی از کدهای سمت سرور برنامه را در سمت کلاینت استفاده کنید. این موضوع شبیه به تصویر زیر اتفاق می افتد.

علاوه بر این روش، اپلیکیشن های Blazor می‌توانند بر روی سرور نیز اجرا بگردند. در این روش، UI event هایی که در سمت کلاینت رخ می‌دهند با استفاده از یک اتصال SignalR در لحظه و به صورت real-time به سمت سرور ارسال می شوند. برای یادگیری SignalR می توانید از بسته ی آموزش ویدئویی شروع به کار با ASP.NET Core و SignalR استفاده کنید. زمانی که این UI event ها به سمت سرور ارسال شدند، تغییرات مربوط به UI تشخیص داده خواهند شد و به سمت کلاینت ارسال شده و سپس در DOM لحاظ می گردند. این موضوع در تصویر زیر نشان داده شده است.

علاوه بر این دوره آموزشی که به صورت متنی در این قسمت از وب سایت پرووید به شما تقدیم می گردد می توانید از بسته ی آموزش ویدئویی شروع به کار با Blazor در ASP.NET Core و بسته ی آموزش ویدئویی بلیزر (Blazor) پیشرفته و ساخت برنامه های تجاری و بسته ی آموزش ویدئویی Authentication و Authorization در بلیزر (Blazor) وبسایت پرووید نیز دیدن بفرمایید. امیدواریم که این دوره آموزشی نیز مورد توجه تمامی علاقمندان قرار بگیرد.

مخاطبین این دوره آموزشی

تمامی علاقه مندان به یادگیری فریم ورک Blazor و تمامی دوستانی که قصد دارند بتوانند از این تکنولوژی در توسعه وب اپلیکیشن ها استفاده کنند. می‌توانند از این آموزش استفاده نمایند. با استفاده از این آموزش مفاهیم مربوط به توسعه اپلیکیشن های وب با استفاده از Blazor را در وجوه مختلف، آموزش خواهید دید.

پیش نیازها

برای درک بهتر مباحث مطرح شده در این آموزش متنی می بایست تا حدودی با Blazor آشنا باشید. در این رابطه توصیه می کنیم از بسته ی آموزش ویدئویی شروع به کار با Blazor در ASP.NET Core دیدن کنید. علاوه بر این، می‌توانید از آموزش متنی Blazor برای توسعه دهندگان ASP.NET Web Forms نیز استفاده کنید. تجربه شما در توسعه وب اپلیکیشن ها با استفاده از تکنولوژی‌های مختلف مایکروسافت از قبیل ASP.NET Web Forms نیز بسیار مفید خواهد بود. در این رابطه نیز توصیه می کنیم از لینک بسته ی آموزش ویدئویی ASP.NET Web Forms و Entity Framework در قالب پروژه  استفاده نمایید.

استفاده کردن از بانک های اطلاعاتی NoSQL

بانک های اطلاعاتی NoSQL از قبیل MongoDB یک روش متفاوت را برای ذخیره کردن آبجکت ها در دیتابیس دارند. دقت کنید که در بانک‌های اطلاعاتی رابطه ای یک آبجکت در قالب یک جدول و یا چندین جدول ذخیره شده و پروپرتی های مختلف مربوط به آن در قالب field ها و یا ستون های جداول ذخیره سازی می شوند. این موضوع در بانک‌های اطلاعاتی NoSQL متفاوت است. در بانک‌های اطلاعاتی NoSQL یک object graph کامل serialize شده و نتایج در بانک اطلاعاتی ذخیره می‌گردند. در رابطه با serialize کردن آبجکت ها می توانید از بسته ی آموزش ویدئویی سریالیزیشن در سی شارپ استفاده کنید. مزیت‌های استفاده کردن از این روش سادگی و Performance بالای آن است. ذخیره کردن یک آپدیت تک serialize شده به مراتب ساده تر از تجزیه کردن یک آبجکت به چندین جدول و relationship می باشد. علاوه بر این موضوع در ذخیره کردن داده ها به طور رابطه‌ای و در بانک‌های اطلاعاتی از قبیل SQL Server اغلب نیاز است که در بازیابی اطلاعات، دستورات پیوند لحاظ بشوند که از لحاظ Performance بسیار ضعیف عمل می کند. علاوه بر این موضوع به بروزرسانی کردن داده های مربوط به جداول نیز می‌تواند کارایی کمی را داشته باشد. این در حالی است که بازیابی کردن و سپس deserialize کردن یک آبجکت تک از یک بانک اطلاعاتی NoSQL که بر اساس کلید کار می کند به مراتب سریعتر و همچنین آسان تر می باشد. از این جهت بانک‌های اطلاعاتی NoSQL نسبت به بانک‌های اطلاعاتی رابطه ای از قبیل SQL Server امروز در بسیاری از برنامه های نوشته شده برای دنیای وب مورد استفاده قرار می گیرند. علاوه بر این موضوع عدم وجود lock و یا ماهیت ترنزکشن ها و یا حتی وجود نداشتن یک schema یک شکل باعث می‌شود تا بانک‌های اطلاعاتی NoSQL بتوانند در ماشین های مختلف به صورت کاملا مقیاس پذیر مورد استفاده قرار بگیرند و از دیتاست های بسیار بزرگ پشتیبانی کنند.

با این وجود بانک‌های اطلاعاتی رابطه ای نسبت به بانک‌های اطلاعاتی NoSQL مزیت های بیشماری دارند. برای مثال در بانک‌های اطلاعاتی رابطه ای از مفهوم normalization به منظور ایجاد کردن consistency و جلوگیری کردن از تکراری بودن داده ها استفاده می شود. این موضوع باعث می‌شود تا حجم بانک اطلاعاتی به مراتب کاهش پیدا کند و تعداد دستورات آپدیت بر روی داده های مشترک در دیتابیس کمتر بشود. در یک بانک اطلاعاتی جداول می توانند با یکدیگر رابطه داشته باشند و از همین جهت تغییر در هر جدول می‌تواند بازتاب خود را در جدولی که با آن در ارتباط هستند ثبت کند. این موضوع می‌تواند و به روزرسانی کردن و حتی بازیابی کردن داده ها به مراتب بهتر باشد. از طرفی در بانک‌های اطلاعاتی NoSQL به دلیل عدم وجود هیچ گونه رابطه ای و البته Serialize شدن object graphs به طور کامل گاهی ممکن است که برای به روز رسانی کردن نیاز باشد که آبجکت های متعددی را به روز رسانی کنیم تا داده‌ها به صورت یک شکل و یا Consistent دربیایند. این موضوع به مراتب Performance کمتری نسبت به بانک‌های اطلاعاتی رابطه ای خواهد داشت. علاوه بر این موجود در بانک های اطلاعاتی رابطه ای موضوعاتی از قبیل relational integrity با لحاظ کردن قوانینی از قبیل foreign key ها نیز پیاده سازی خواهد شد بانک‌های اطلاعاتی NoSQL چنین مفاهیم و قیودی را بر روی داده های خود نخواهند داشت.

یکی دیگر از پیچیدگی‌های بانک‌های اطلاعاتی NoSQL مکانیسم versioning می باشد. زمانی که پروپرتی های مربوط به یک آبجکت تغییر می کنند نمی توان از ورژن های قبلی آن آبجکت استفاده کرد و یا حتی آنها را Deserialized نمود بنابراین تمامی آبجکت های از قبل موجود می بایست که به روز رسانی بشوند تا schema مربوط به ورژن جدید آن آبجکت را دریافت کند. این موضوع در بانک‌های اطلاعاتی رابطه نیز اتفاق می‌افند. در بانک‌های اطلاعاتی رابطه ای تغییرات schema گاهی نیازمند ارسال update script ها و همچنین گاهی نیازمند بروز رسانی کردن اسکریپت ها و mapping ها می باشد. با این وجود تعداد رکوردهایی که می بایست در بانک‌های اطلاعاتی نویسی NoSQL به روزرسانی بشوند به مراتب بیشتر از تعداد رکوردهای نیازمند به روز رسانی در بانک‌های اطلاعاتی رابطه هستند. دلیل این موضوع نیز در این است که بانک‌های اطلاعاتی NoSQL دارای حجم زیادی از داده های تکراری می باشند.

موضوع دیگر اینکه که در بانک‌های اطلاعاتی NoSQL می توان چندین ورژن مختلف از آبجکت ها را ذخیره سازی کرد. این قضیه در بانک‌های اطلاعاتی رابطه ای که schema آنها به طور یک شکل و غیر قابل تغییر است امکان پذیر نخواهد بود. در چنین شرایطی برنامه باید در رابطه با وجود ورژن های مختلف و یا قدیمی تر از آبجکت ها مکانیزم مناسبی را اتخاذ کند و این موضوع خود باعث افزایش پیچیدگی برنامه خواهد شد.

مورد آخر اینکه که بانک‌های اطلاعاتی NoSQL اغلب مفاهیم ACID را در بانک‌های اطلاعاتی پیاده سازی نمی‌کنند. این موضوع باعث می‌شود تا بانک‌های اطلاعاتی NoSQL نسبت به بانک های اطلاعاتی رابطه ای Performance و Scalability بالاتری داشته باشند. به طور کلی از بانک‌های اطلاعاتی NoSQL در شرایطی استفاده می‌کنیم که دیتاست و آبجکت ها بسیار حجیم و بزرگ هستند و نمی‌توانند در ساختار نرمال شده بانک‌های اطلاعاتی رابطه ای ذخیره شوند. علاوه بر این موارد شما می توانید در یک نرم‌افزار هم از بانک‌های اطلاعاتی رابطه ای استفاده کنید و هم در کنار آنها از بانک‌های اطلاعاتی NoSQL بهره مند شوید. عبارت دیگر نرم افزار بر اساس نیازمندیهای که تعریف می‌کند می‌تواند در جایگاه صحیح از هر کدام از این دو گزینه بهره مند شود.

بررسی بانک اطلاعاتی Azure Cosmos DB

یک مثال بسیار مناسب برای بانک‌های اطلاعاتی NoSQL که برنامه نویسان فریم ورک .Netمی توانند از آن استفاده کنند Azure Cosmos DB می باشد. با استفاده از Azure Cosmos DB شما می توانید یک بانک اطلاعاتی مبتنی بر Cloud و از لحاظ schema کاملا انعطاف پذیر را دریافت کنید. Performance ،Azure Cosmos DB بسیار بالایی دارد و از قابلیت هایی از قبیل Availability بالا و elastic scaling و global distribution بهره مند می باشد. علیرغم اینکه بانک اطلاعاتی Azure Cosmos DB یک بانک اطلاعاتی NoSQL به حساب می‌آید، برنامه نویسان می توانند با دستورات و قابلیت‌های SQL به صورتی کاملاً آزادانه بر روی داده های JSON خود کار کنند. تمامی Resource های موجود در بانک اطلاعاتی Azure Cosmos DB در قالب فایل های JSON ذخیره می‌شوند. دو واژه بسیار مهم در کار کردن با Azure Cosmos DB را بهتر است که بشناسید. واژه items نمایانگر Resource هایی هستند که در اختیار شما قرار می گیرد و در واقع شامل متادیتا در رابطه با داکیومنت های مربوط به بانک اطلاعاتی NoSQL خواهند بود. واژه بعدی feeds است که در واقع به معنی مجموعه‌ای از آیتم ها خواهد بود. برای درک هر چه بهتر ارتباط ماهیت های مختلف در Azure Cosmos DB می توانید از تصویر زیر بهره مند شوید. به تصویر زیر نگاه کنید:

زبان پرس و جوی داده ها در Azure Cosmos DB بسیار ساده اما قدرتمند است. با استفاده از این زبان شما می توانید فایل های JSON خود را مورد پرس و جو قرار بدهید. زبان پرس و جوی Azure Cosmos DB زیر مجموعه از ANSI SQL می باشد و یکپارچگی کامل آبجکت ها و آرایه ها و object construction و function invocation و دیگر مفاهیم مربوط به JavaScript را شامل می‌شود.

دیگر گزینه‌های ذخیره‌سازی کردن داده ها

علاوه بر بانک‌های اطلاعاتی Relational و NoSQL که تا به اینجای کار بررسی شده‌اند، برنامه های نوشته شده با Asp.Net Core می‌توانند از سرویس Azure Storage به منظور ذخیره کردن داده های خود در قالب ها و فایلهای مبتنی بر Cloud که به صورت کاملا انعطاف پذیر و مقیاس پذیر عمل می‌کنند نیز بهره‌مند شوند. سرویس Azure Storage کاملاً Scalable و یا مقیاس پذیر است و از این جهت شما می توانید با حجم بسیار ناچیزی از داده‌ها کار را آغاز کرده و به مرور تا حد چندصد ترابایت داده را ذخیره سازی کنید. سطح ذخیره سازی کنید. سرویس Azure Storage به طور کلی از چهار نوع داده پشتیبانی می کند که لیست آنها را در قسمت زیر برای شما قرار داده ایم:

• از Blob Storage به منظور ذخیره کردن داده های متنی بدون ساختار و یا حتی ذخیره کردن داده های باینری مورد استفاده قرار می‌گیرد. واژه دیگری که به جای Blob Storage استفاده می‌شود object storage است.
• از Table Storage برای ذخیره کردن دیتاست های ساختارمند مورد استفاده قرار می‌گیرد.
• از Queue Storage به منظور ذخیره کردن پیام های مبتنی بر Queue مورد استفاده قرار می گیرند.
• از File Storage به منظور برقرار کردن دسترسی به فایل ها به صورت مشترک بین virtual machine ‌های Azure و برنامه‌های on-premise پشتیبانی می‌شود.

فریم ورک Entity Framework Core دو ویژگی منحصر به فرد دارد که آن را از Dapper بسیار متمایز کرده و البته بر روی Performance آن تاثیر کمی منفی نیز خواهد گذاشت. اولین ویژگی ترجمه شدن خودکار دستورات LINQ به دستورات متناظر SQL به منظور اجرا شدن در دیتابیس میباشند. این جملات هرچند که در حافظه کش قرار می‌گیرند اما در اولین اجرا شدن دچار سرباری می‌شوند که بر روی Performance برنامه نیز تأثیر منفی خواهد گذاشت. ویژگی دوم Entity Framework Core ردگیری کردن Entity ها توسط Change tracker می باشد که این موضوع باعث می‌شود جملات Update برای بروز رسانی کردن رکوردهای دیتابیس با سرعت و بهینگی بالاتری تولید بشوند. البته می‌توان برای برخی از کوئری های ارسال شده به سمت دیتابیس از یک Extension method به نام AsNotTracking استفاده کرد تا Entity های بازیابی شده از دیتابیس ردگیری نشوند. علاوه بر این موضوع Entity Framework اغلب دستورات SQL خود را با بهینه سازی کامل ایجاد کرده و از این لحاظ Performance بسیار بالایی را نیز خواهند داشت. اگر برنامه‌نویس تمایل به داشتن کنترل بیشتری بر روی جملات ارسال شده به سمت دیتابیس داشته باشد می‌تواند از دستورات سفارشی و خام SQL و یا procedure stored های تعریف شده در دیتابیس استفاده کرده و با لحاظ کردن آنها در Entity Framework Core سرعت برنامه را افزایش بدهد. از این نقطه نظر Dapper از لحاظ کارایی از Entity Framework Core بهتر عمل می‌کند. اما این Performance بالا خیلی چشمگیر نیست و می‌توان در سناریوهایی از آن چشم پوشی کرد. ضمنا برای بررسی و مقایسه Syntax مربوط به کار کردن با Dapper و Entity Framework Core میتوان کد زیر را بررسی نمود.

علاوه بر این موضوع اگر نیاز به ایجاد کردن object graphs های پیچیده تر با استفاده از Dapper دارید می‌توانید کوئری های مورد نظر خود را ایجاد کرده و به صورت سفارشی آنها را لحاظ نماید این موضوع در Entity Framework Core با استفاده از متد Include اتفاق می‌افتد. برای به دست آوردن داده ها با استفاده از Dapper ‌ گزینه های بیشتری نیز در پیش روی ما قرار گرفته اند. برای مثال قابلیت Multi Mapping در Dapper اجازه می‌دهد تا یک سطر در دیتابیس به چندین آپدیت مختلف نگاشت شود. برای مثال فرض کنید که یک کلاس به نام Post دارید که در آن یک پروپرتی به نام Owner از نوع یک کلاس به نام User تعریف شده است. کدی که در قسمت زیر مشاهده می کنید تمامی داده های مورد نیاز را برای ما برخواهد گرداند.

هر سطر برگردانده شده توسط دستور بالا هم شامل داده‌های مربوط به User می باشند و هم شامل داده‌های مربوط به Post است. از آنجایی که داده‌های مربوط به User می بایست به داده‌های مربوط به Post متصل بشود و این اتفاق از طریق پروپرتی Owner رخ می‌دهد یک تابع به شکل زیر نوشته خواهد شد.

علاوه بر این کد کامل برای برگرداندن مجموعه‌ای از Post ها به همراه پروپرتی Owner آنها و البته قرار داده شدن داده‌های مربوط به User در پروپرتی Owner شبیه به کد زیر خواهد بود.

از آنجایی که سطح کپسوله کردن جزئیات مربوط به بانک اطلاعاتی در استفاده کردن از Dapper به مراتب کمتر از Entity Framework Core می باشد برنامه نویسان اغلب نیاز دارند که ساختار مربوط به ذخیره شدن داده ها در دیتابیس را بدانند تا بتوانند به بهترین شکل ممکن با آنها کار کنند و کدهای مناسبی را لحاظ نمایند. زمانی که Model برنامه تغییر می‌کند به جای ایجاد کردن یک migration جدید که یکی از قابلیت های Entity Framework Core است نیاز است که تک تک کوئری های نوشته شده با استفاده از Dapper به‌روزرسانی بشود. دقت کنید که این موضوع در مقایسه با Entity Framework Core که به صورت کاملا خودکار mapping های مربوط به کلاس ها را در DbContext به‌روزرسانی می‌کند کمی دردسر ساز خواهد شد. کوئری های نوشته شده با استفاده از Dapper در زمان کامپایل مشکلی نخواهند داشت اما این موضوع ممکن است که در زمان اجرا شدن برنامه، نرم‌افزار را دچار مشکل کند و کشف خطا های ایجاد شده را دشوارتر نمایند. در کنار این پیچیدگی‌ها Dapper با سرعت فوق العاده خود در کار کردن با بانک‌های اطلاعاتی گوی سبقت را از Entity Framework Core ربوده است.

در بسیاری از نرم‌افزارها، تکنولوژی‌ Entity Framework Core با Performance قابل قبولی می تواند به عنوان گزینه اول کار کردن با بانک‌های اطلاعاتی مورد استفاده قرار بگیرد. بنابراین برنامه نویسان می توانند از ویژگی های منحصر به فرد Entity Framework Core از قبیل migration ها و change tracking و البته ترجمه شدن جملات LINQ به دستورات SQL بهره‌مند شوند. علاوه بر این موضوع اگر قرار است که یک کوئری با سرعت فوق العاده بالائی اجرا بشود می توانید به سادگی یک Stored procedure تعریف شده در دیتابیس را توسط Entity Framework Core اجرا نمایید. در قسمت بعد از این آموزش در رابطه با تفاوت SQL و NoSQL صحبت خواهیم کرد.

بازیابی کردن و ذخیره کردن داده ها با استفاده از Entity Framework Core

به منظور بازیابی کردن داده ها با استفاده از EF Core شما می بایست پروپرتی مورد نظرتان را از کلاس DbContext انتخاب کرده و سپس با استفاده از LINQ کارهای متفاوتی از قبیل فیلتر کردن و یا انتخاب کردن پروپرتی های مختلفی از درون یک Entity را انجام بدهید. در رابطه با این موضوع در بسته ی آموزش ویدئویی LINQ در سی شارپ و بسته ی آموزش ویدئویی مباحث پیشرفته LINQ در سی شارپ صحبت کرده ایم. علاوه بر این موضوع با استفاده از دستورات LINQ شما می‌توانید projection نیز انجام بدهید. منظور از projection تغییر دادن نتایج از یک تایپ به یک تایپ دیگر می‌باشد. مثالی که در قسمت زیر مشاهده می کنید CatalogBrand های مربوطه را از بانک اطلاعاتی بازیابی کرده و آنها را بر اساس نام مرتب کرده است. علاوه بر این با استفاده از پروپرتی Enabled مربوط به هر کدام از CatalogBrand ها آنها را فیلتر نموده و نهایتاً به یک تایپ جدید به نام SelectListItem اصطلاحا project کرده است.

یکی از ویژگی‌های دستورات LINQ ، differed execution و یا اجرا شدن به تعویق افتاده می باشد که در بسته های آموزشی مختلف وب سایت پروید از آن صحبت کرده‌ایم. این بدان معناست که در زمان تعریف کردن یک کوئری با استفاده از LINQ عملاً آن دستور اجرا نمی‌شود مگر اینکه از یکی از Execution Method ها استفاده کنید. منظور از Execution Method ها دستوراتی که از قبیل ToListAsync می باشند که در مثال بالا مشاهده شد. با استفاده از متود ToListAsync شما میتوانید کوئری نوشته شده توسط LINQ را فوراً اجرا کنید. اگر این کار انجام نشود دستور نوشته شده با استفاده از LINQ در واقع یک IQueryable از نوع SelectListItem را برمی گرداند و تا زمانی که در یک حلقه تکرار از قبیل foreach اقدام به پیمایش آن نکرده‌اید اجرا نمی‌شود. برگرداندن یک IQueryable به عنوان خروجی یک متد مزایا و معایب خاص خود را دارند که در بسته ی آموزش ویدئویی نکات و ترفندهای کالکشن ها و جنریک ها در سی شارپ بیشتر از آن صحبت کرده ایم. با استفاده از اینترفیس IQueryable تکنولوژی Entity Framework Core می‌تواند در صورت تمایل کوئری ایجاد شده را تغییر داده و دیگر قابلیت ها از قبیل فیلتر کردن و مرتب سازی را به آن اضافه کند با این وجود یکی از مشکلات استفاده کردن از این روش، رخ دادن خطاهایی در زمان اجرا شدن برنامه می باشد. این خطاها از این موضوع ریشه می گیرند که Entity Framework Core احتمالاً نمی تواند برخی از دستورات موجود در LINQ را به دستورات T-SQL ترجمه کند. بنابراین به طور کلی توصیه می‌شود که عملیات مورد نظر از قبیل فیلتر کردن نتایج را در متدی که دارد به داده ها دسترسی پیدا می‌کند انجام شود و خروجی کار در قالب یک Collection درون حافظه ای برای مثال یک لیست جنریک به عنوان نتیجه برگردانده بشود.

موضوع دیگر اینکه تکنولوژی Entity Framework Core تغییراتی که بر روی Entity های بازیابی شده از درون بانک اطلاعاتی رخ می دهند را اصطلاحاً ردگیری و یا Track می کند. این کار با استفاده از یکی از قابلیت های Entity Framework Core به نام change tracker اتفاق می افتد. به منظور ذخیره کردن تغییرات اتفاق افتاده بر روی Entity هایی که Track می شوند شما می بایست متد SaveChanges را از کلاس DbContext مورد نظر خود صدا بزنید. دقت کنید که شی DbContext مورد نظر که متد SaveChanges را از آن صدا میزنید می بایست همان شی ای باشد که با استفاده از آن Entity های مورد نظر خود را از بانک اطلاعاتی خوانده‌اید. اضافه کردن و حذف کردن Entity ها به طور مستقیم بر روی پروپرتی های DbSet متناظر اتفاق افتاده و دستورات متناظر با این تغییرات در بانک اطلاعاتی لحاظ می‌شود. مثال زیر نحوه اضافه کردن، به روز رسانی کردن و نهایتاً حذف نمودن Entity هایی را از درون بانک اطلاعاتی نشان می‌دهد.

تکنولوژی Entity Framework Core هم از متدهای synchronous و هم از متدهای asynchronous برای بازیابی و ذخیره کردن داده ها استفاده می کند. در وب اپلیکیشن ها توصیه می شود که از async/await و متدهای async استفاده کنید تا thread های موجود در وب سرور قفل نشده و بتوانند در کنار عملیات مربوط به data access کارهای دیگری را نیز انجام بدهند. در رابطه با این موضوع در بسته ی آموزش ویدئویی برنامه نویسی ناهمزمان (Asynchronous Programming) در دات نت صحبت کرده‌ایم.

بازیابی کردن داده های مرتبط

همانطور که می دانید یکی از موضوعات بسیار مهم در کار کردن با داده ها ارتباط بین رکوردهای موجود در بانک‌های اطلاعاتی به حساب می‌آید. تکنولوژی Entity Framework Core به سادگی می‌تواند با داده‌های مرتبط با یکدیگر که اصطلاحا تحت عنوان related data نیز شناخته می شوند کار کند. زمانی که Entity Framework Core اقدام به بازیابی Entity هایی از درون بانک اطلاعاتی می کند تمامی پروپرتی های موجود را که با استفاده از رکوردهای درون بانک اطلاعاتی ذخیره شده اند بازیابی می کند. تکنولوژی Entity Framework Core به طور پیش‌فرض داده‌های مرتبط که تحت عنوان navigation property نیز شناخته می شوند را از درون بانک اطلاعاتی بازیابی نخواهد کرد. این موضوع بدان دلیل است که Entity Framework Core تلاش می‌کند تا داده‌هایی که احتمالاً ضرورتی به وجود آنها نیست را بازیابی نکند. عدم بازیابی کردن داده های غیر ضروری می تواند در وب اپلیکیشن ها بسیار مهم باشد چرا که این نوع از نرم افزارها می بایست با سرعت بسیار بالایی request های مربوط به کاربر را پردازش کرده و به response هایی را به روشی کاملاً سریع برگردانند. اگر شما می خواهید که relationship مربوط به یک Entity با Entity های دیگر در نظر گرفته شود و داده‌های مرتبط بازیابی بگردند می‌توانید از تکنیک eager loading و یا بارگذاری پیشقدمانه استفاده کنید. برای انجام این کار از یک extension method به نام Include در دستور نوشته شده با استفاده از LINQ استفاده خواهید کرد. این موضوع در کد زیر نشان داده شده است:

برای باز کردن چندین relationship و یا حتی subrelationship ها از متد ThenInclude استفاده خواهیم کرد. تکنولوژی Entity Framework Core برای بازیابی کردن یک Entity و Entity های مرتبط با آن فقط از یک کوئری استفاده خواهد کرد. علاوه بر این روش شما می توانید با لحاظ کردن نام navigation property های مورد نظر خود به عنوان پارامتر ورودی متد Include فقط آن دسته از Entity های مورد نظر را بازیابی کنید. این موضوع در کد زیر نشان داده شده است:

یکی دیگر از کاربردهای دستورات LINQ استفاده کردن از متد aggregate و لحاظ نمودن یک specification می باشد. با استفاده از یک specification شما می توانید شکل داده هایی که قرار است بازیابی بشوند را نیز مشخص کرده و پروپرتی هایی که می خواهید مقدار بگیرند را لحاظ نمائید. برای مثال برنامه eShopOnWeb چندین specification دارد که عملیات eager loading را در خود کپسوله سازی کرده اند. دو مثال از این specification ها در کد زیر نشان داده شده است:

روشی دیگر برای بارگذاری کردن داده های مربوط به رکورد های مرتبط استفاده کردن از explicit loading می باشد. تکنیک explicit loading به شما اجازه می دهد تا داده های مورد نظر خود را به درون یک Entity که از قبل بازیابی شده است بارگذاری کنید. دقت کنید که در تکنیک explicit loading به ازای بارگذاری کردن هر داده مرتبط یک round trip جدید به دیتابیس ایجاد خواهد شد و این موضوع می‌تواند بر روی performance و یا کارایی سیستم تاثیر منفی بگذارد. از همین جهت در وب اپلیکیشن ها توصیه نمی‌شود که از تکنیک explicit loading استفاده کنیم.

تکنیک آخری که در حوزه بازیابی کردن داده های مرتبط وجود دارد Lazy loading و یا بارگذاری تنبلانه می باشد. تکنیک Lazy loading به صورت خودکار داده‌های مرتبط را زمانی که برنامه به آنها نیاز دارد بارگذاری می‌کند. در تکنولوژی EF Core به طور پیش فرض در ورژن 2.1 قابلیت Lazy loading اضافه شد. البته برای استفاده کردن از Lazy loading می بایست یک NuGet package به نام Microsoft.EntityFrameworkCore.Proxies را نصب کنید. شبیه explicit loading استفاده کردن از Lazy loading در وب اپلیکیشن ها توصیه نمی‌شود چرا که با استفاده از این روش به ازای هر داده مرتبط می بایست یک کوئری جدید به دیتابیس ارسال شده و این موضوع طبیعتا هم بر روی performance برنامه تأثیر منفی خواهد گذاشت. متاسفانه سربار تحمیل شده توسط روش Lazy loading اغلب در زمان توسعه نرم‌افزار کشف نخواهد شد. این موضوع بدان دلیل است که تاخیر و یا latency در development environment کم است و Data set هایی که برنامه با آنها کار می کند بسیار کم حجم هستند. از طرفی زمانی که برنامه در production قرار می گیرد و کاربرها و request ها به مرور افزایش پیدا می‌کنند latency برنامه افزایش پیدا خواهد کرد و به ازای هر داده مرتبط یک request جدید به سمت دیتابیس ارسال خواهد شد که این موضوع بر روی performance برنامه تاثیر منفی خواهد گذاشت به طور کلی از روش‌های Lazy loading و explicit loading در توسعه وب اپلیکیشن ها استفاده نخواهیم کرد.