نظرات مطالب
Accord.NET #1
Accord.NET در حقیقت یک توسعه ای برای AForge.NET است. و چنانچه می‌خواهید از آکورد استفاده کنید بایستی ابتدا AForge.NET نصب نمایید.
AForge.NET یک کتابخانه بسیار عالی است اما در هر کدام از فضای نام هایش نقص هایی وجود دارد که در آکورد دات نت به آن افزوده شده است؛ به عنوان مثال در درختواره فضای نام MachineLearning مستندات دو پروژه مشاهده می‌کنیم که بسیاری از مفاهیم یادگیری ماشین از جمله : دسته بند نیو بیز، بوستینگ، بگینگ، درخت تصمیم، انواع مختلف اعتبارسنجی‌ها و ... در Accord.NET گنجانده شده است.

نظرات مطالب
SQL Antipattern #2
فکر میکنم عموما  پرس‌وجوی بازگشتی اگر ساپورت بشه توسط دیتابیس بهترین روش همان لیست مجاورت هستش که مدیریت درخت رو برامون ساده میکنه و دیتابیس کنترل بشتری رو هر نود ما داره. البته به غیر از مواردی خاص...
ممنون از مطلب مفیدتون ولی سوالی که دارم اینه از نظر Performance مقایسه ای انجام شده که آیا استفاده از لیست بازگشتی چقدر از نظر سرعت در بازیابی اطلاعات با سایر روش‌ها تفاوت داره ؟ مبنعی اگر سراغ دارید ممنون میشم معرفی کنین.

نظرات مطالب
مباحث تکمیلی مدل‌های خود ارجاع دهنده در EF Code first
اولین رکورد یا به عبارتی ریشه یک درخت، ریشه‌ای ندارد. این ریشه نال رو چطور در بانک اطلاعاتی تعریف و ذخیره می‌کنید؟ بحث ما Id اولین رکورد نیست. بحث کلیدخارجی است که باید نال پذیر باشد و به همین جدول هم اشاره می‌کند و نمایانگر رکورد والد یک رکورد خاص است (جدول خود ارجاع دهنده). در همین مطلب جاری به تصویر اول دقت کنید. بحث ما فیلد ReplyId است که نال پذیر است. این ReplyId کلید خارجی اشاره‌کننده به همین جدول هم هست.
پاسخ به بازخورد‌های پروژه‌ها
درخواست ایده برای برای پیاده سازی منوی چند سطحی
با همین یک جدول خود ارجاع هم میشه همین کار را کرد.
میشه به صورت ترکیبی از SQL Antipattern شمارش مسیر در کنار این جدول خود ارجاع استفاده کرد به این شکل هم ساختار درختی را دارین هم با توجه به عمق محدود گروه بندی‌ها ، روش شمارش مسیر هم برای کوئری‌ها مربوط به درخت خیلی مفید خواهد بود. 
همچنین در رابطه با بحث جدیدی که مطرح کردید هم میتوانید هنگام درج کالایی ، گروه‌های سطح آخر را اجازه انتخاب دهید. و حالا در سطح اول هم  با امکان شمارش مسیری که گذاشته ایم ، مثلا خیلی راحت پرفروش‌ترین کالاهای آن را  که در شاخه‌های زیرین ثبت شده اند بدست آورد.
این مورد محدود کردن به انتخاب گروه‌های موجود در شاخه  در هنگام درج یکسری  خصوصیات داینامیک (Specification Attribute)  در سیستم باید در سمت برنامه کنترل شود .
مطالب
تغییرات مهم مقایسه‌‌ی رشته‌ها در NET 5.0.
با توجه به ماهیت چندسکویی NET 5.، در اکثر سیستم‌های ویندوزی، سرویس بومی سازی، بر اساس استاندارد NLS کار می‌کند، اما در سیستم‌های لینوکسی و مبتنی بر یونیکس، این استاندارد از نوع ICU است (و وجود و تنظیم آن‌ها خارج از NET. و توسط سیستم عامل مدیریت می‌شود). جهت یک‌دست سازی این دو نوع سیستم بومی سازی در دات نت، از نگارش 5 آن به بعد، استاندارد ICU که به صورت گسترده‌تری مورد پذیرش قرار گرفته‌است، استاندارد بومی سازی پیش‌فرض دات نت درنظر گرفته می‌شود؛ مگر اینکه سیستم عاملی آن‌را پشتیبانی نکند.


کدام نگارش از ویندوز، از ICU پشتیبانی می‌کند؟

تمام ویندوزهای پس از Windows 10 May 2019 Update، به همراه icu.dll، به عنوان جزء استاندارد سیستم عامل هستند. بنابراین دات نت 5 و نگارش‌های پس از آن، در این سیستم عامل‌ها، از سرویس بومی سازی ICU استفاده خواهند کرد؛ اما اگر از نگارش‌های پیشین ویندوز استفاده می‌کنید، به اجبار به سیستم NLS سوئیچ خواهد شد.


تاثیر ICU بر برنامه‌های دات نت 5 به بعد

قطعه کد زیر را درنظر بگیرید:
string s = "Hello\r\nworld!";
int idx = s.IndexOf("\n");
Console.WriteLine(idx);
در نگارش‌های پیش از 5 دات نت، خروجی کدهای فوق، عدد 6 است؛ اما ... اما ... (!) از زمان دات نت 5 به بعد، خروجی آن «منهای یک» است! البته به شرطی که آخرین به روز رسانی ویندوز 10 را نصب کرده باشید؛ یعنی حداقل  Windows 10 May 2019 Update را داشته باشید.


حالت «پیش‌فرض» جستجو و مقایسه‌ی رشته‌ها در دات نت 5 به بعد، یک مقایسه‌ی مبتنی بر «دستورات زبانی» بر اساس فرهنگ تنظیم شده‌ی در Thread جاری برنامه‌است (یا همان System.Threading.Thread.CurrentThread.CurrentCulture).


چرا متدهای کار بر روی رشته‌ها در دات نت 5 به بعد، نسبت به نگارش‌های قبلی متفاوت عمل می‌کنند؟

زمانیکه متدی مانند IndexOf فراخوانی می‌شود، هدف عمده‌ی برنامه‌نویس‌ها، یک جستجوی Ordinal است (یعنی مقایسه‌ی کاراکتر به کاراکتر؛ بدون درنظر گرفتن نکات زبانی و بومی)؛ اما فراموش می‌کنند که این متدها دارای پارامتر دومی هم هستند که از نوع StringComparison است و سال‌ها است که توصیه می‌شود این پارامتر را هم به صورت صریحی مقدار دهی کنید تا هدف خود را از نوع جستجو دقیقا مشخص نمائید. از زمان دات نت 5 به بعد، اگر این پارامتر را مشخص نکنید، جستجوی صورت گرفته یک رفتار culture-specific را خواهد داشت و نه Ordinal.  از این لحاظ مقایسه‌ی رشته‌ها توسط استانداردهای ICU و NLS، بر اساس پیاده سازی‌های مختلف زبان‌شناسی، خروجی‌های یکسانی را ارائه نمی‌دهند و به همین جهت است که اینبار خروجی منهای یک را دریافت می‌کنیم.

یک نکته: خروجی قطعه کد فوق در سیستم‌های لینوکسی که از .NET Core 2x - 3x. هم استفاده می‌کنند، دقیقا منهای یک است؛ چون پیش‌فرض بومی سازی آن‌ها نیز ICU است.


چگونه می‌توان به همان حالت پیشین مقایسه‌ی رشته‌ها در NET. بازگشت؟

مایکروسافت بسته‌ی نیوگت Microsoft.CodeAnalysis.FxCopAnalyzers را جهت گوشزد کردن نکته‌ی ذکر صریح StringComparison، به روز رسانی کرده‌است. بنابراین بهتر است تا آن‌را به پروژه‌ی خود اضافه کنید. در این حالت اخطارهای مناسبی را جهت یافتن قسمت‌های مشکل‌دار برنامه‌ی خود دریافت می‌کنید. برای مثال برای اینکه در قطعه کد فوق به همان پاسخ متداول 6 برسیم، تنها کافی‌است پارامتر دوم StringComparison را ذکر کنیم:
int idx = s.IndexOf("\n", StringComparison.Ordinal);

و یا حتی می‌توانید فایل csproj پروژه‌ی خود را ویرایش کرده و یک سطر زیر را به آن اضافه کنید:
<ItemGroup>
   <RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>
در این حالت کل برنامه‌ی شما بدون هیچ تغییری مانند قبل کار کرده و از سیستم NLS استفاده می‌شود.



کدام متدهای کار با رشته‌ها در دات نت 5، تحت تاثیر این تغییرات قرار گرفته‌اند؟

اگر از متدهای زیر در برنامه‌های خود استفاده می‌کنید، نکته‌ی ذکر پارامتر StringComparison.Ordinal را فراموش نکنید:
System.String.Compare
System.String.EndsWith
System.String.IndexOf
System.String.StartsWith
System.String.ToLower
System.String.ToLowerInvariant
System.String.ToUpper
System.String.ToUpperInvariant
System.Globalization.TextInfo (most members)
System.Globalization.CompareInfo (most members)
System.Array.Sort (when sorting arrays of strings)
System.Collections.Generic.List<T>.Sort() (when the list elements are strings)
System.Collections.Generic.SortedDictionary<TKey,TValue> (when the keys are strings)
System.Collections.Generic.SortedList<TKey,TValue> (when the keys are strings)
System.Collections.Generic.SortedSet<T> (when the set contains strings)


سؤال: اگر متدی پارامتر دوم StringComparison را نداشت چطور؟
اگر به ماخذ «Behavior changes when comparing strings on .NET 5» مراجعه کنید، در انتهای آن جدولی را ارائه داده که دو سطر اول آن، به صورت زیر است:
API                Default behavior       Remarks
string.Compare     CurrentCulture
در این جدول، هر متدی که رفتار پیش‌فرض آن از نوع CurrentCulture است، تحت تاثیر قرار گرفته‌است و متدی مانند string.Contains که رفتار پیش‌فرض آن Ordinal است، از این تغییرات مصون است و نیازی به تغییری ندارد.


برای مطالعه‌ی بیشتر:
Behavior changes when comparing strings on .NET 5+
.NET globalization and ICU.
Globalization breaking changes
بحث و گفتگویی در این مورد
مطالب
آموزش LINQ بخش دوم
سبک‌های مختلف نوشتن Query در LINQ
تعریف Query:
عبارتی که اطلاعات را از منبع داده، بازیابی می‌کند، پرس و جو یا Query می‌گوییم. بطور کلی عملیات پرس و جو شامل سه بخش زیر می‌شود:
1- مشخص کردن منبع داده
2- ایجاد پرس و جو (Query)
3- اجرای پرس و جو
// The Three Parts of a LINQ Query:
//  1. منبع داده
int[] numbers = new int[7] { 0, 1, 2, 3, 4, 5, 6 };
// 2. ایجاد پرس و جو
// numQuery is an IEnumerable<int>
var numQuery =
    from num in numbers
    where (num % 2) == 0
    select num;
// 3. اجرای پرس و جو
foreach (int num in numQuery)
{
    Console.Write("{0,1} ", num);
}
شکل زیر توصیفی از کد‌های بالا می‌باشد :
 
دو سبک برای نوشتن عبارت‌های جستجو در LINQ وجود دارند :
 1- Fluent Style 
 2- Query Expression Style یا Query Syntax
سبک Fluent از متد‌های الحاقی برای عملیات پرس و جو استفاده می‌کند. در کلیه‌ی کدهای بخش اول این سری آموزشی از سبک Fluent استفاده شده است.
در کلاس‌های زیر متد‌های استاتیک مختلفی برای عملیات بر روی توالی‌ها ارائه شده‌اند:
 • System.Linq.Enumerable
 • System.Linq.Queryable
 • System.Linq.ParallelEnumarable
بطور کلی هر نمونه‌ای که اینترفیس <IEnumerable<Tsource را پیاده سازی کرده باشد می‌تواند از این متدهای الحاقی استفاده کند.
عملگرهای جستجو به دو صورت تکی و زنجیره‌ای برای ایجاد پرس و جو‌های پیچیده مورد استفاده قرار می‌گیرند.

پرس و جوی‌های زنجیره‌ای
در ابتدا کلاسی به نام Ingredient را به شکل زیر تعریف می‌کنیم (این کلاس نشان دهنده‌ی نام مواد غذایی و کالری آنهاست):
class Ingredient
{
    public string Name { get; set; }
    public int Calories { get; set; }
}
لیستی از مواد غذایی را ایجاد می‌کنیم:
Ingredient[] ingredients =
{
   new Ingredient {Name = "Suger", Calories = 500},
   new Ingredient {Name = "Egg", Calories = 100 },
   new Ingredient {Name = "Milk", Calories = 150 },
   new Ingredient {Name = "Flour", Calories = 50 },
   new Ingredient {Name = "Butter", Calories = 200 }
};
حال می‌خواهیم بصورت زنجیره‌ای از عملگر‌های پرس و جوی Where,OrderBy,Select استفاده کنیم:
Ingredient[] ingredients =
{
   new Ingredient {Name = "Suger", Calories = 500},
   new Ingredient {Name = "Egg", Calories = 100 },
   new Ingredient {Name = "Milk", Calories = 150 },
   new Ingredient {Name = "Flour", Calories = 50 },
   new Ingredient {Name = "Butter", Calories = 200 }
};

IEnumerable<string> highCalories =
ingredients.Where(x => x.Calories >= 150)
  .OrderBy(x => x.Name)
  .Select(x => x.Name);

foreach (var item in highCalories)
{
   Console.WriteLine(item);
}
خروجی کد بالا به شکل زیر است :
Butter
Milk
Suger
نمودار زیر نحوه‌ی عملکرد عملگرهای پرس و جو را نشان می‌دهد. هر عملگر بر روی توالی خروجی عملگر قبلی کار می‌کند. توجه کنید که توالی ورودی از نوع <IEnumerable<Ingredient می‌باشد و توالی خروجی تولید شده از نوع <IEnumerable<string است.
در این مثال عملگر‌های پرس و جو بر روی توالی ورودی عمل می‌کنند تا به دستور Select برسند. دستور Select هر عنصر را به یک رشته تبدیل می‌کند. این عملیات را Projection می‌گویند.











عبارت Lambda نوشته شده‌ی در بخش Select مشخص می‌کند که خروجی بر اساس چه خصوصیتی از توالی ورودی باشد. در اینجا نام عناصر به صورت رشته در خروجی ظاهر می‌شوند.


سبک Query Expression (عبارت‌های پرس و جو) 

Query Expression یک گرامر زیبا و روان برای نوشتن پرس و جو‌ها را ارائه می‌دهد. در مثال زیر از سبک Query Expression استفاده کرده‌ایم:

Ingredient[] ingredients =
{
    new Ingredient {Name = "Suger", Calories = 500},
    new Ingredient {Name = "Egg", Calories = 100},
    new Ingredient {Name = "Milk", Calories = 150},
    new Ingredient {Name = "Flour", Calories = 50},
    new Ingredient {Name = "Butter", Calories = 200}
};

IEnumerable<string> highCalories =
    from i in ingredients
    where i.Calories >= 150
    orderby i.Name
    select i.Name;

foreach (var item in highCalories)
{
    Console.WriteLine(item);
}

خروجی کد بالا با خروجی کد به سبک Fluent  یکسان است:

Butter
Milk
Suger

همانطور که می‌بینید ترتیب عملیات همانند روش قبل است. عبارت‌های پرس و جوی (from,where,orderby,select) به ترتیب با اصلاح توالی ورودی و تحویل آن به عبارت جستجوی بعدی کار را انجام می‌دهند.

عبارت جستجوی بالا با کلمه‌ی کلیدی from آغاز شده است. هدف from دو چیز است:

1- مشخص کردن توالی ورودی (منبع داده)

2- معرفی متغیر Range  (مشخص کردن عنصر مورد نظر در منبع داده)

متغیر Range همچون متغیر شمارنده در حلقه هاست. 


در ادامه این سری آموزشی درباره متغیر Range بصورت کاملتری بحث خواهیم کرد.   

نظرات مطالب
ASP.NET MVC #18
در این حالت پیاده سازی کلاس RolesProvider باید به چه صورتی باشد؟
مطالب
بررسی الگوی Visitor در جاوا اسکریپت
این الگو اجازه‌ی تعریف کردن عملیاتی جدید را برای مجموعه‌ای از شیء‌ها، بدون تغیر دادن ساختار خود شیء‌ها، میدهد. همچنین اجازه‌ی جدا کردن کلاس را از منطقی که کلاس  پیاده سازی می‌کند، به ما میدهد.
عملیات بیشتری می‌توانند در شیء Visitor کپسوله سازی شوند. شیء‌ها می‌توانند یک متد visit داشته باشند که یک شیء Visitor را دریافت می‌کند. Visitor می‌تواند تغییرات مورد نیاز را ایجاد کند و عملیاتی را بر روی شیء‌هایی که دریافت کرده‌است، انجام دهد.

این الگو به توسعه دهندگان این اجازه را میدهد که کتابخانه‌ها (libraries)، فریم ورک‌ها (frameworks) و ... را گسترش دهند.


مثال: 

class Visitor {
    visit(item){}
}

class BookVisitor extends Visitor {
    visit(book) {
        var cost=0; 
        if(book.getPrice() > 50) 
        { 
            cost = book.getPrice()*0.50 
        } 
        else{
            cost = book.getPrice()
        }     
        console.log("Book name: "+ book.getName() + "\n" + "ID: " + book.getID() + "\n" + "cost: "+ cost); 
        return cost; 
    }
}

class Book{
    constructor(id,name,price){
        this.id = id
        this.name = name
        this.price = price
    }
    getPrice(){
        return this.price
    }
    getName(){
        return this.name
    }
    getID(){
        return this.id
    }
    accept(visitor){
        return visitor.visit(this)
    }
}

var visitor = new BookVisitor()
var book1 = new Book("#1234","lordOftheRings",80)
book1.accept(visitor)

در مثال بالا ما یک کتابفروشی داریم. کلاس Book برای نشان دادن یک کتاب در فروشگاه استفاده شده‌است. این کلاس همانند زیر تعریف شده‌است: 
class Book{
    constructor(id,name,price){
        this.id = id
        this.name = name
        this.price = price
    }
    //code...
}

یک کتاب خصوصیات زیر را دارد: 
  • id
  • name
  • price

هم چنین شامل توابع زیر می‌باشد:
getPrice(){
    return this.price
}

getName(){
    return this.name
}

getID(){
    return this.id
}

متد getPrice ، قیمت را برگشت میدهد، getName ، نام را برگشت میدهد و getID، شناسه‌ی کتاب را برگشت میدهد.

اکنون کتابفروشی یک تخفیف را برای کتاب‌هایی که هزینه‌ی آن‌ها بیشتر از 50 دلار است، معرفی می‌کند. در ادامه، می‌خواهیم یک عملیات دیگر را انجام دهیم و تخفیف را بر روی آن‌ها پیاده سازی کنیم. در اینجا از الگوی visitor استفاده خواهیم کرد. ما یک Visitor را معرفی می‌کنیم که کتابها را بازدید خواهد کرد و قیمت آن‌ها را به‌روزرسانی می‌کند. بنابراین شیء‌های کتاب باید تابعی داشته باشند که اجازه دهد visitor، آنها را بازدید (visit) کند و عملیات مد نظر را بر روی آن‌ها انجام دهد. برای این منظور، یک متد به نام accept  در کلاس Book  تعریف کرده‌ایم:
 
accept(visitor){
    return visitor.visit(this)
}

متد accept  یک شیء visitor را به عنوان یک آرگومان دریافت می‌کند و به آن اجازه میدهد که با فراخوانی کردن تابع visit خودش، کتاب جاری را بازدید (visit) کند (this اشاره به کتاب جاری دارد) .

اکنون اجازه دهید نگاهی به کلاس Visitor  داشته باشیم: 
class Visitor {
   visit(item){}
}

این کلاس، یک تابع به نام visit دارد و itemی را که می‌خواهد بازدید (visit ) کند، به عنوان پارامتر دریافت می‌کند. در این سناریو، می‌خواهیم که کتاب‌ها را بازدید (visit ) کنیم. از این رو، در ابتدا یک کلاس را به نام BookVisitor تعریف می‌کنیم که کلاس Visitor را extend می‌کند: 

class BookVisitor extends Visitor {
   visit(book) {
      var cost=0; 
      if(book.getPrice() > 50) 
      { 
         cost = book.getPrice()*0.50 
      } 
      else{
         cost = book.getPrice()
      }     
      console.log("Book name: "+ book.getName() + "\n" + "ID: " + book.getID() + "\n" + "cost: "+ cost); 
      return cost; 
   }
}

تابع visit، قیمت کتابی را که دارد بازدید می‌کند، بررسی می‌کند. اگر بزرگتر از 50 باشد، 50 درصد تخفیف را بر روی آن اعمال می‌کند؛ در غیر این صورت، قیمت به حالت قبلی خودش باقی می‌ماند. 

چه زمانی از این الگو استفاده کنیم:

  1. زمانیکه نیاز است عملیاتی مشابه، بر روی شیء‌های متفاوتی از یک data structure  انجام شود. 
  2. زمانیکه نیاز است عملیاتی خاص، بر روی شیء‌های متفاوتی از data structure انجام شود. 
  3. زمانیکه می‌خواهید توسعه پذیری را برای کتابخانه‌ها (libraries) یا فریم ورک‌ها (frameworks) اضافه کنید.
مطالب
نحوه‌ی صحیح فراخوانی SQL Aggregate Functions حین استفاده از LINQ - قسمت دوم

در قسمت قبل در مورد حالتی که کوئری انجام شده نتیجه‌ای را بر نگردانده است، بحث شد. در این قسمت یکی از شایع‌ترین مشکلات حین کار با تابع Sum بررسی خواهد شد.

ابتدا جدول ساده Transactions را با دو فیلد Id و Amount مطابق تصویر زیر در نظر بگیرید:


تعدادی رکورد در این جدول ثبت شده‌اند. اکنون می‌خواهیم جمع آن‌ها را محاسبه کنیم:


همانطور که ملاحظه می‌نمائید این عملیات میسر نیست، زیرا حاصل نهایی فراتر از بازه‌ی تعریف شده‌ی Int32 است.
برای رفع این مشکل باید Amount را تبدیل به BigInt (برای مثال مرتبط با نگارش‌های مختلف SQL Server) کرد. مطابق توضیحات قسمت قبل، این عملیات casting باید به lambda expression تعریف شده اعمال گردد، زیرا خروجی Sum بر مبنای آن تعیین می‌گردد.



در این حالت خروجی SQL آن نیز به صورت زیر در خواهد آمد:



هر چند این مباحث ساده به نظر می‌رسند ولی در صورت عدم رعایت سبب سرخ و سفید شدن در هنگام مقتضی خواهند گردید.

مطالب
مروری بر Blazor (قسمت اول)

Blazer یک فریمورک جدید تحت وب هست که این امکان را به برنامه نویسان دات نت میدهد تا از طریق Open Web Standards بتوانند کدهای خود را در مرورگر اجرا و تجربه جدیدی از ساخت برنامه‌های تک صفحه‌ای را داشته باشند. در این نوشتار قصد داریم ساختار و نحوه کارکرد این فناوری را بررسی نماییم. قبل از هر چیزی به دوران قبل از ایجاد Web Assembly برمی‌گردیم :

همانطور که در شکل زیر می‌بینید، زمانی تنها جاوااسکریپت فرمانروای یک مرورگر محسوب می‌شد. در این حالت کدهای جاوااسکریپت به هر شکلی که نوشته شده باشند در اختیار parser قرار میگیرند  و یک درخت از کدهای نوشته شده ایجاد شده و از طریق یک کامپایلر، کد‌ها به سطح پایین‌تری مشابه بایت کدها تبدیل می‌گردند و سپس از طریق یک مفسر دسترسی به بخش‌های مختلف api یک مرورگر در اختیار این کدها قرار میگیرند تا کار مورد نظر انجام شود.

 

در تصویر بعدی Web Assembly به بخش مفسر تزریق میشود و از طریق آن زبان‌های مختلف باید بر اساس Web Standard، به کدهای سطح‌های پایین‌تری کامپایل شوند. در اینجا این نکته مدنظر باشد که کدهایی که به سطح پایین‌تری کامپایل میشوند، تنها در داخل مرورگر شناخته شده میباشند و در خارج از دنیای وب قابل استفاده نیستند و نمیتوانند در سطح سیستم عامل قابل اجرا باشند. به همین جهت به شکل یک sandbox مورد استفاده قرار میگیرند و از این لحاظ، مشکلات امنیتی را در خارج از مرورگر ایجاد نمی‌کنند.

 

در شکل سوم Blazor که ترکیبی از نام Browser + Razor میباشد اضافه میشود. Blazor در اینجا وظیفه دارد محتوای فایل دریافتی را که شامل کدهای  HTML و  CSS و جاوااسکریپت است، به کدهای قابل فهمی برای مرورگر تبدیل کند. سپس mono وارد کار میشود. همانطور که می‌دانید mono جهت پشتیبانی از اجرای چندسکویی پروژه‌های دات نت اضافه شده که در اینجا هم همان وظیفه را منتها برای مرورگرهای مختلف، دارد. بدین جهت مونوی کامپایل شده بر روی Web Assembly قرار میگیرد تا کدهای دریافتی را تفسیر نماید. Blazor در اینجا dll‌های لازم را در mono بارگذاری میکند و سپس mono کدها را برای Web Assembly تفسیر میکند.

 

  اگر در تصویر بالا درقت کنید دو فایل Blazor.js و mono.js نیز وجود دارند که یک ارتباط به صورت Introp layer با Web Assembly برقرار کرده‌اند. البته در حال حاضر این ارتباط توسط Web Assembly پشتیبانی نمی‌شود. در صورت پیاده سازی و پشتیبانی Web Assembly از این بخش، میتوان با جاوااسکریپت هم با آن ارتباط برقرار کرد و یک ارتباط دو طرفه‌ای بین کدهای js و دات نت برقرار نمود؛ بدین صورت میتوان در دات نت توابع js را صدا زد و در js توابع دات نت صدا زده شوند.

همچنین مایکروسافت تنها به استفاده از Web Assembly اکتفا نکرده و از طریق SignalR نیز این  بستر را فراهم کرده است. با ایجاد یک سوکت به سمت سرور، تغییرات صفحه در سمت سرور، محاسبه و سپس بازگشت داده می‌شوند. در این حالت نیازی به ارسال فایل‌های dll نسبت به روش قبل نمی‌باشد. برای استفاده از این حالت میتوانید از بین گزینه‌های موجود در ایجاد پروژه، Blazor Server-side را مورد استفاده قرار دهید. البته این روش هم مزایا و معایب خودش را دارد.

جهت مقایسه این دو بخش به بررسی نکات مثبت و منفی میپردازیم:
1- در حالت استفاده از Web Assembly، حجمی حدود نزدیک به دو مگابایت بایدجابجا شود؛ ولی در حال سمت سرور، حجم صفحه حدود 100 کیلوبایت خواهد شد.
2- در حالت سمت سرور، تغییرات به دلیل رفت و برگشت به سرور با کمی تاخیر روبرو میشوند.
3- در حالت سمت سرور کارکرد آفلاین از دست میرود.
4- در حالت سرور، به دلیل اینکه همه کارها سمت سرور انجام میشود، ترافیک سرور را بالاتر میبرند.
5- استفاده از حالت سرور، معماری ساده‌تر و پیچیدگی‌های کمتری در سمت کلاینت دارد.