اشتراکها
اشتراکها
هزینه واقعی توسعه UI در دات نت
اشتراکها
EF 6.0.2 در راه است
دات نت 6 به همراه source generatorهای توکاری است که میتوانند کار serialization و deserialization نوع JSON را با کارآیی بسیار بیشتری انجام دهند؛ با آزمایشهایی که این بهبود را در حد 40 درصد سریعتر نسبت به حالت متداول آن نمایش میدهند و ... این مساله بسیار مهم است. از این جهت که این روزها، JSON را در همهجا مشاهده میکنیم؛ در Web APIها، در تنظیمات برنامهها، در ارسال پیامها بین برنامهها و غیره. بنابراین هرگونه بهبودی در زمینهی کارآیی serialization و deserialization آن، تاثیر بسیار قابل ملاحظهای را بر روی کارآیی کلی یک برنامه بجا خواهد گذاشت.
System.Text.Json source generator چیست؟
پایهی تمام اعمال serialization و deserialization در دات نت، استفاده از Reflection است که در زمینهی ارائهی برنامههایی با کارآیی بالا و با مصرف حافظهی پایین، بهینه عمل نمیکند. راهحل جایگزین استفاده از Reflection که در زمان اجرای برنامه رخ میدهد، به همراه دات نت 5 ارائه شد و source generators نام دارد. Source generators امکان تولید فایلهای #C را در زمان کامپایل برنامه میسر میکنند که نسبت به راهحل Reflection که در زمان اجرای برنامه فعال میشود، کارآیی بسیار بیشتری را ارائه میکنند. برای مثال به همراه دات نت 6، علاوه بر روش پیشفرض مبتنی بر Reflection ارائه شدهی توسط System.Text.Json، راه حل جدید امکان استفادهی از source generators توکار آن نیز پیش بینی شدهاست. کار اصلی آن، انجام تمام مراحلی است که پیشتر توسط Reflection در زمان اجرای برنامه صورت میگرفت، اینبار در زمان کامپایل برنامه و ارائهی آن به صورت از پیش آماده شده و مهیا.
مزایای این روش شامل موارد زیر است:
- بالا رفتن سرعت برنامه
- کاهش زمان آغاز اولیهی برنامه
- کاهش میزان حافظهی مورد نیاز برنامه
- عدم نیاز به استفادهی از System.Reflection و System.Reflection.Emit
- ارائهی Trim-compatible serialization که سبب کاهش اندازهی نهایی برنامه میشود. برای مثال در برنامههای Blazor میتوان با فعالسازی Trimming، کدهای استفاده نشده را از فایلهای بایناری نهایی حذف کرد. استفاده از source generators، با این روش سازگاری کاملی دارد.
مثالی از نحوهی کار با JSON در دات نت 6، توسط source generators آن
فرض کنید قصد داریم اعمال serialization و deserialization از نوع JSON را بر روی نمونههای کلاس زیر انجام دهیم:
اولین کاری که در این زمینه باید انجام شود، ایجاد یک کلاس خالی، با نامی دلخواه، اما مشتق شدهی از JsonSerializerContext است. در این حالت اخطارهایی را در IDE خود مبتنی بر نیاز به پیاده سازی تعدادی از متدهای این کلاس پایه دریافت میکنیم. اما ... ما قصد نداریم این متدها را پیاده سازی کنیم؛ Source generator قرار است اینکار را انجام دهد. به همین جهت این کلاس را partial تعریف کرده (تا source generator بتواند آنرا در فایلی دیگر تکمیل کند) و همچنین آنرا مزین به ویژگی JsonSerializable از نوع کلاسی که میخواهیم آنرا serialize کنیم، خواهیم کرد تا سبب فعال شدن source generator بر روی این کلاس شویم:
و ... همین! کدهای این کلاس partial توسط source generator در زمان کامپایل برنامه به صورت خودکار تولید و تکمیل میشوند.
پس از آن فقط کافی است MyJsonContext را به عنوان پارامتر متدهای جدید Serialize و یا Deserialize، به صورت زیر ارسال کنیم تا از آن استفاده شود:
متدهای جدید این API مبتنی بر source generators را در ادامه ملاحظه میکنید:
روش معرفی تنظیمات Serializer به Source generator
برای معرفی تنظیمات serialization و deserialization، برای مثال تهیهی خروجیهای CamelCase، میتوان از ویژگی JsonSourceGenerationOptions به صورت زیر استفاده کرد:
در این حالت مابقی کدها مانند قبل باقی خواهند ماند:
روش استفاده از JSON Source generators در برنامههای ASP.NET Core
در این نوع برنامهها، JsonSerializerContextها را میتوان توسط متد AddContext به صورت زیر به تنظیمات JSON برنامه معرفی کرد:
روش استفاده از JSON Source generators در برنامههای Blazor
البته در اینجا بیشتر منظور امکان استفادهی از آنها توسط HttpClient است که به صورت زیر توسط متد GetFromJsonAsync واقع در فضای نام System.Net.Http.Json، میسر شدهاست:
لیست کاملتر این API جدید به صورت زیر است:
System.Text.Json source generator چیست؟
پایهی تمام اعمال serialization و deserialization در دات نت، استفاده از Reflection است که در زمینهی ارائهی برنامههایی با کارآیی بالا و با مصرف حافظهی پایین، بهینه عمل نمیکند. راهحل جایگزین استفاده از Reflection که در زمان اجرای برنامه رخ میدهد، به همراه دات نت 5 ارائه شد و source generators نام دارد. Source generators امکان تولید فایلهای #C را در زمان کامپایل برنامه میسر میکنند که نسبت به راهحل Reflection که در زمان اجرای برنامه فعال میشود، کارآیی بسیار بیشتری را ارائه میکنند. برای مثال به همراه دات نت 6، علاوه بر روش پیشفرض مبتنی بر Reflection ارائه شدهی توسط System.Text.Json، راه حل جدید امکان استفادهی از source generators توکار آن نیز پیش بینی شدهاست. کار اصلی آن، انجام تمام مراحلی است که پیشتر توسط Reflection در زمان اجرای برنامه صورت میگرفت، اینبار در زمان کامپایل برنامه و ارائهی آن به صورت از پیش آماده شده و مهیا.
مزایای این روش شامل موارد زیر است:
- بالا رفتن سرعت برنامه
- کاهش زمان آغاز اولیهی برنامه
- کاهش میزان حافظهی مورد نیاز برنامه
- عدم نیاز به استفادهی از System.Reflection و System.Reflection.Emit
- ارائهی Trim-compatible serialization که سبب کاهش اندازهی نهایی برنامه میشود. برای مثال در برنامههای Blazor میتوان با فعالسازی Trimming، کدهای استفاده نشده را از فایلهای بایناری نهایی حذف کرد. استفاده از source generators، با این روش سازگاری کاملی دارد.
مثالی از نحوهی کار با JSON در دات نت 6، توسط source generators آن
فرض کنید قصد داریم اعمال serialization و deserialization از نوع JSON را بر روی نمونههای کلاس زیر انجام دهیم:
namespace Test { internal class Person { public string FirstName { get; set; } public string LastName { get; set; } } }
using System.Text.Json.Serialization; namespace Test { [JsonSerializable(typeof(Person))] internal partial class MyJsonContext : JsonSerializerContext { } }
پس از آن فقط کافی است MyJsonContext را به عنوان پارامتر متدهای جدید Serialize و یا Deserialize، به صورت زیر ارسال کنیم تا از آن استفاده شود:
Person person = new() { FirstName = "Jane", LastName = "Doe" }; byte[] utf8Json = JsonSerializer.SerializeToUtf8Bytes(person, MyJsonContext.Default.Person); person = JsonSerializer.Deserialize(utf8Json, MyJsonContext.Default.Person);
متدهای جدید این API مبتنی بر source generators را در ادامه ملاحظه میکنید:
namespace System.Text.Json { public static class JsonSerializer { public static object? Deserialize(ReadOnlySpan<byte> utf8Json, Type returnType, JsonSerializerContext context) => ...; public static object? Deserialize(ReadOnlySpan<char> json, Type returnType, JsonSerializerContext context) => ...; public static object? Deserialize(string json, Type returnType, JsonSerializerContext context) => ...; public static object? Deserialize(ref Utf8JsonReader reader, Type returnType, JsonSerializerContext context) => ...; public static ValueTask<object?> DeserializeAsync(Stream utf8Json, Type returnType, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static ValueTask<TValue?> DeserializeAsync<TValue>(Stream utf8Json, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static TValue? Deserialize<TValue>(ReadOnlySpan<byte> utf8Json, JsonTypeInfo<TValue> jsonTypeInfo) => ...; public static TValue? Deserialize<TValue>(string json, JsonTypeInfo<TValue> jsonTypeInfo) => ...; public static TValue? Deserialize<TValue>(ReadOnlySpan<char> json, JsonTypeInfo<TValue> jsonTypeInfo) => ...; public static TValue? Deserialize<TValue>(ref Utf8JsonReader reader, JsonTypeInfo<TValue> jsonTypeInfo) => ...; public static string Serialize(object? value, Type inputType, JsonSerializerContext context) => ...; public static void Serialize(Utf8JsonWriter writer, object? value, Type inputType, JsonSerializerContext context) { } public static Task SerializeAsync(Stream utf8Json, object? value, Type inputType, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task SerializeAsync<TValue>(Stream utf8Json, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static byte[] SerializeToUtf8Bytes(object? value, Type inputType, JsonSerializerContext context) => ...; public static byte[] SerializeToUtf8Bytes<TValue>(TValue value, JsonTypeInfo<TValue> jsonTypeInfo) => ...; public static void Serialize<TValue>(Utf8JsonWriter writer, TValue value, JsonTypeInfo<TValue> jsonTypeInfo) { } public static string Serialize<TValue>(TValue value, JsonTypeInfo<TValue> jsonTypeInfo) => ...; } }
برای معرفی تنظیمات serialization و deserialization، برای مثال تهیهی خروجیهای CamelCase، میتوان از ویژگی JsonSourceGenerationOptions به صورت زیر استفاده کرد:
using System.Text.Json.Serialization; namespace Test { [JsonSourceGenerationOptions(PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase)] [JsonSerializable(typeof(Person))] internal partial class MyJsonContext : JsonSerializerContext { } }
string json = JsonSerializer.Serialize(person, MyJsonContext.Default.Person); Person person = JsonSerializer.Deserialize(json, MyJsonContext.Default.Person);
روش استفاده از JSON Source generators در برنامههای ASP.NET Core
در این نوع برنامهها، JsonSerializerContextها را میتوان توسط متد AddContext به صورت زیر به تنظیمات JSON برنامه معرفی کرد:
services.AddControllers().AddJsonOptions(options => options.AddContext<MyJsonContext>());
روش استفاده از JSON Source generators در برنامههای Blazor
البته در اینجا بیشتر منظور امکان استفادهی از آنها توسط HttpClient است که به صورت زیر توسط متد GetFromJsonAsync واقع در فضای نام System.Net.Http.Json، میسر شدهاست:
[JsonSerializable(typeof(WeatherForecast[]))] internal partial class MyJsonContext : JsonSerializerContext { } @code { private WeatherForecast[] forecasts; private static JsonSerializerOptions Options = new(JsonSerializerDefaults.Web); private static MyJsonContext Context = new MyJsonContext(Options); protected override async Task OnInitializedAsync() { forecasts = await Http.GetFromJsonAsync("sample-data/weather.json", Context.WeatherForecastArray); } }
namespace System.Net.Http.Json { public static partial class HttpClientJsonExtensions { public static Task<object?> GetFromJsonAsync(this HttpClient client, string? requestUri, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<object?> GetFromJsonAsync(this HttpClient client, System.Uri? requestUri, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<TValue?> GetFromJsonAsync<TValue>(this HttpClient client, string? requestUri, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<TValue?> GetFromJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<HttpResponseMessage> PostAsJsonAsync<TValue>(this HttpClient client, string? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<HttpResponseMessage> PostAsJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<HttpResponseMessage> PutAsJsonAsync<TValue>(this HttpClient client, string? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<HttpResponseMessage> PutAsJsonAsync<TValue>(this HttpClient client, System.Uri? requestUri, TValue value, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; } public static partial class HttpContentJsonExtensions { public static Task<object?> ReadFromJsonAsync(this HttpContent content, Type type, JsonSerializerContext context, CancellationToken cancellationToken = default(CancellationToken)) => ...; public static Task<T?> ReadFromJsonAsync<T>(this HttpContent content, JsonTypeInfo<TValue> jsonTypeInfo, CancellationToken cancellationToken = default(CancellationToken)) => ...; } }
این طراحی ارتباطی به فایل appsettings.json ندارد؛ چون بحث ذخیره سازی دادهها در یک بانک اطلاعاتی رابطهای غیر شیءگرا در اینجا مطرح است و همچنین امکان نگاشت مقادیر آن توسط امکانات EF Core. ولی در کل امکان یک چنین نگاشتهایی از EF Core 2.1 به بعد، تحت قابلیت جدیدی به نام «تبدیلگرهای مقدار»، به آن اضافه شدهاست: «یک مثال تکمیلی: روش ذخیرهی آرایهای از رشتهها» و یا «کار با فیلدهایی از نوع JSON در EF Core و یک نمونهی دیگر »
حرف شما درسته، ولی با توجه به امکان استفاده از DLLهای Full .NET Framework در NET Core 2 میتوان به راهکارهایی دیگری نیز دست یافت.
Support for referencing .NET Framework libraries and NuGet packages
برای مثال یک برنامه با Web API & Owin (نه Web API Core) نوشتم و با dotnet (نسخه دو) اون رو در لینوکس اجرا کردم، بدون نصب Mono
با استفاده از Blazor میتوان برنامههای وب تعاملی را با کمک زبان #C تهیه کرد که پیشتر برای نوشتن آنها به جاوا اسکریپت نیاز بود. به این ترتیب میتوان برای تهیهی قسمتهای front-end و backend پروژهی خود، از زبانی که به آن تسلط دارید استفاده کنید. یکی از مزایای آن امکان به اشتراک گذاری کدهای سمت سرور و کلاینت است؛ با توجه به اینکه هر دو به یک زبان تهیه میشوند.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
بنابراین فقط کافی است دستور dotnet new blazorserver و یا dotnet new blazorwasm را در یک پوشهی خالی اجرا کنیم تا بر اساس قالبهای پیشفرض ارائه شده، بتوان پروژههای خالی Blazor Server و یا Blazor WebAssembly را ایجاد کرد.
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
وضعیت توسعهی برنامههای وب، پیش از ارائهی Blazor
عموما برای توسعهی برنامههای وب، در سمت سرور آنها از زبانهایی مانند C#، Java و Python و امثال آنها استفاده میشود؛ اما این وضعیت در سمت کلاینت فرق میکند. در سمت کلاینت، عموما از فریمورکها و کتابخانههای جاوا اسکریپتی مانند Angular ،React ،Vue.js ،jQuery و غیره استفاده میشود.
همانطور که مشاهده میکنید، فراگیری و اجرای این دو گروه متفاوت از زبانها، مشکل و وقتگیر است. بنابراین چقدر خوب میشد اگر امکان تهیهی هر دو قسمت برنامههای وب، تنها با یک زبان میسر میشد. با استفاده از Blazor، این آرزو میسر شدهاست.
با استفاده از Blazor میتوان کدهای تعاملی UI را بجای استفاده از زبان جاوا اسکریپت، با کمک زبان #C تهیه کرد. به این ترتیب با استفاده از یک زبان میتوان کدهای سمت سرور و سمت کلاینت را پیاده سازی کرد. البته شاید این سؤال مطرح شود که مرورگرها تنها قادر به درک کدهای HTML و جاوا اسکریپت هستند و نه #C، بنابراین چگونه میتوان از زبان #C در مرورگرها نیز استفاده کرد؟ پاسخ به آن، به فناوری جدید «وب اسمبلی» بر میگردد. Blazor با استفاده از «وب اسمبلی» است که میتواند کدهای #C را درون مرورگر اجرا کند.
حالتهای مختلف هاست و ارائهی برنامههای مبتنی بر Blazor
برنامههای مبتنی بر Blazor، به دو روش مختلف قابل ارائه هستند:
الف) Blazor Server
Blazor Server، در اساس یک برنامهی استاندارد ASP.NET Core است که در آن تمام قابلیتهای سمت سرور، مانند کار با EF-Core، میسر است و امکان دسترسی به این امکانات به صورت یکپارچهای در سراسر برنامه وجود دارد. در این حالت، کامپوننتهای Blazor، بجای اجرای بر روی مرورگر کاربر، در سمت سرور اجرا میشوند. این تعاملات و به روز رسانیهای UI، توسط یک اتصال دائم SignalR مدیریت میشوند.
همانطور که مشاهده میکنید، در حالت هاست سمت سرور، همه چیز، منجمله کامپوننتهای Blazor، در همان سمت سرور قرار دارند و این اتصال پشت صحنهی SignalR است که کار تبادل اطلاعات ارسالی و رندر شده را بر عهده میگیرد.
ب) Blazor web assembly
در این حالت با استفاده از فناوری جدید «وب اسمبلی»، تمام کدهای یک برنامهی مبتنی بر Blazor به کمک NET Runtime.، داخل مرورگر اجرا میشود. به Blazor web assembly باید همانند فریمورکهای SPA (تک صفحهای وب)، مانند Angular و React نگاه کرد؛ با یک تفاوت مهم: در اینجا بجای استفاده از جاو اسکریپت برای نوشتن برنامهی SPA، از #C استفاده میشود. اگر به تصویر فوق دقت کنید، در حالت اجرای برنامههای Blazor web assembly، تنها به مرورگر کاربر نیاز است و همه چیز داخل آن قرار میگیرد. در اینجا دیگر خبری از یک اتصال دائم SignalR با سرور وجود ندارد.
البته باید دقت داشت که از فناوری وب اسمبلی، در تمام مرورگرهای جدید پشتیبانی میشود؛ منهای IE 11. در این حالت مرورگر کل برنامهی Blazor را دریافت میکند (همانند دریافت کل کدهای یک برنامهی Angular و یا React) و بدون استفاده از رندر سمت سرور حالت الف، قابلیت تعامل با کاربر را دارد.
بدیهی است با توجه به اینکه Blazor web assembly مستقیما داخل مرورگر اجرا میشود، دیگر همانند حالت الف، امکان دسترسی مستقیم به فناوریها و امکانات سمت سرور، مانند کار مستقیم با EF-Core را نخواهد داشت. برای این منظور دقیقا همانند روش کار با سایر فریم ورکهای SPA، نیاز به تهیهی یک ASP.NET Core Web API جهت تعامل با سرور خواهد بود.
مزایا و معایب حالتهای مختلف هاست برنامههای Blazor
الف) Blazor Server
مزایا:
- حجم دریافتی توسط مرورگر در این حالت بسیار کم است.
- امکان دسترسی به تمام امکانات سمت سرور را دارد؛ مانند تمام کتابخانههای سمت سرور و همچنین امکان دیباگ آن نیز همانند سایر برنامههای سمت سرور است.
- بر روی مرورگرهای قدیمی نیز قابل اجرا است؛ چون بدون نیاز به فناوری جدید «وب اسمبلی» کار میکند.
معایب:
- رندر شدن UI آن نسبت به حالت ب، کندتر است. از این جهت که تمام تعاملات UI آن، توسط اتصال SignalR به سمت سرور ارسال شده و سپس نتیجهی نهایی رندر شده، به سمت کلاینت بازگشت داده میشود.
- پشتیبانی از اجرای offline آن وجود ندارد. اگر اتصال SignalR موجود قطع شود، دیگر نمیتوان از برنامه استفاده کرد.
- با توجه به نیاز به استفادهی از یک اتصال دائم SignalR به ازای هر کاربر، مقیاس پذیری این نوع برنامهها کمتر است. البته اگر تعداد کاربران برنامههای شما در یک شبکهی اینترانت داخلی شرکتی محدود است، این مورد مشکل خاصی نخواهد بود. از دیدگاهی دیگر اگر تعداد کاربران برنامهی شما بسیار زیاد است، استفاده از Blazor Server توصیه نمیشود. البته باید دقت داشت که سروری با 4GB RAM، میتواند 5000 کاربر همزمان SignalR را مدیریت کند.
ب) Blazor web assembly یا به اختصار Blazor WASM
مزایا:
- هیچ نوع وابستگی به سمت سرور ندارد. همینقدر که برنامه توسط مرورگر دریافت شد، قابل اجر است.
- برای هاست آن الزاما نیازی به یک سرور IIS و یا یک وب سرور ASP.NET Core نیست.
- امکان ارائهی آن توسط یک CDN نیز وجود دارد.
- چون در این حالت کل برنامه توسط مرورگر دریافت میشود، قابلیت اجرای آفلاین را نیز پیدا میکند.
- برای کار، نیازی به اتصال دائم SignalR را ندارد؛ به همین جهت مقیاس پذیری آن بیشتر است.
معایب:
- حتما نیاز به استفادهی از مرورگرهای جدید با پشتیبانی از web assembly را دارد؛ برای مثال نیاز به کروم نگارش 57 به بعد و فایرفاکس نگارش 52 به بعد را دارد و بر روی IE اجرا نمیشود.
- چون کل برنامه در این حالت توسط مرورگر دریافت میشود، حجم ابتدایی دریافت آن کمی بالا است.
- میدان دید و عملکرد آن همانند سایر برنامههای SPA، محدود است به امکاناتی که مرورگر، در اختیار برنامه قرار میدهد.
ایجاد پروژههای خالی Blazor Server و Blazor web assembly
یا میتوانید از ویژوال استودیوی کامل و منوی افزودن پروژهی آن برای اینکار استفاده کنید و یا اگر به خروجی دستور dotnet new --list مراجعه کنیم، SDK دات نت 5، به همراه دو قالب مرتبط زیر نیز هست:
C:\Users\Vahid>dotnet new --list Templates Short Name Language Tags -------------------------------------------- ------------------- ------------ ---------------------- Blazor Server App blazorserver [C#] Web/Blazor Blazor WebAssembly App blazorwasm [C#] Web/Blazor/WebAssembly
در قسمت بعد، این دو پروژهی خالی فوق را ایجاد کرده و ساختار آنها را بررسی میکنیم. همچنین نکاتی را هم که در این قسمت در مورد نحوهی هاست این برنامهها عنوان شد، بر روی این پروژهها مشاهده خواهیم کرد.
مسیرراهها
شروع به کار با EF Core 1.0
قسمت 1: برپایی تنظیمات اولیه
قسمت 2: به روز رسانی ساختار بانک اطلاعاتی
قسمت 3: انتقال مهاجرتها به یک اسمبلی دیگر
قسمت 4: کار با بانکهای اطلاعاتی از پیش موجود
قسمت 5: استراتژهای تعیین کلید اصلی جداول و ایندکسها
قسمت 6: تعیین نوعهای داده و ویژگیهای آنها
قسمت 7: بررسی رابطهی One-to-Many
قسمت 8: بررسی رابطهی Many-to-Many
قسمت 9: بررسی رابطهی One-to-One
قسمت 10: استفاده از امکانات بومی بانکهای اطلاعاتی
قسمت 11: بررسی رابطهی Self Referencing
قسمت 12: بررسی تنظیمات ارث بری روابط
قسمت 13: بررسی سیستم ردیابی تغییرات
قسمت 14: لایه بندی و تزریق وابستگیها
قسمت 15: نوشتن آزمونهای واحد
قسمت 2: به روز رسانی ساختار بانک اطلاعاتی
قسمت 3: انتقال مهاجرتها به یک اسمبلی دیگر
قسمت 4: کار با بانکهای اطلاعاتی از پیش موجود
قسمت 5: استراتژهای تعیین کلید اصلی جداول و ایندکسها
قسمت 6: تعیین نوعهای داده و ویژگیهای آنها
قسمت 7: بررسی رابطهی One-to-Many
قسمت 8: بررسی رابطهی Many-to-Many
قسمت 9: بررسی رابطهی One-to-One
قسمت 10: استفاده از امکانات بومی بانکهای اطلاعاتی
قسمت 11: بررسی رابطهی Self Referencing
قسمت 12: بررسی تنظیمات ارث بری روابط
قسمت 13: بررسی سیستم ردیابی تغییرات
قسمت 14: لایه بندی و تزریق وابستگیها
قسمت 15: نوشتن آزمونهای واحد