تا به امروز فقط برای ورژن خاصی از ویندوز ۱۰ و ۱۱ ارایه شده است. اما برای مابقی ویندوزها قرار است هفته آینده منتشر شود.
حتی برای ویندوز ۷ هم که دیگر پشتیبانی نمی‌شود آپدیت خواهد داد.
چون نخ پردازشی رویدادهای Blazor نظیر Oninitialize و OnAfterRender و ... یکی است بنابراین استفاده از StateHasChanged نتیجه مطلوب را به همراه خواهد داشت اما در رابطه با متدهای خارجی (External method) مانند تایمرها باید از await InvokeAsynck(StateHasChanged) استفاده نمود.
StateHasChanged که برای رندر مجدد کامپوننت‌ها در Blazor Server استفاده می‌شود، اجازه نمی‌دهد چندین نخ به طور همزمان به فرآیند رندر دسترسی داشته باشند. در صورتی که StateHasChanged توسط یک نخ ثانویه فراخوانی شود آنگاه استثنایی شبیه زیر رخ خواهد داد:
System.InvalidOperationException: The current thread is not associated with the Dispatcher. در اپلیکیشن‌های مبتنی بر Blazor Server تنها یک dispatcher به ازای هر اتصال وجود دارد (هر تب مرورگر یک اتصال). هر زمانی که از InvokeAsync استفاده می‌کنیم، درحقیقت کار را با این dispatcher جلو می‌بریم. (دقیقا همانند Dispatcher.Invoke در WPF یا Control.Invoke در ویندوز فرم اپلیکیشن ها). بنابراین زمانی که نیاز است در نخ دیگری StateHasChanged را فراخوانی کنیم لازم است که اینکار را توسط InvokeAsync انجام دهیم. در حقیقت InvokeAsync کارها را به صورت سریالی در یک صف مرتب می‌کند و به صورت قدم به قدم آنها را اجرا می‌کند تا از بروز استثنا جلوگیری می‌کند.
در کل زمانی که مشغول کار با رویدادهای UI triggered هستید (نظیر متدهای کلیک برروی یک دکمه، متدهای نویگیشن و ....) نیاز نیست نگران ایمن‌سازی نخ‌ها باشید زیرا Blazor خودش اینکار را انجام می‌دهد و مطمئن می‌شود که در واحد زمان فقط یک نخ کدهای یک کامپوننت را اجرا خواهد کرد. اما زمانی که مشغول کار با رویدادهای non-UI triggerd هستید (نظیر تایمرها) اگر از StateHasChanged بدون InvokeAsync استفاده کنید سبب ایجاد Thread Race Condition خواهید شد.
An application’s code base is a living entity. It keeps growing, changing, and adapting. There’s always a new feature to add, more bugs to solve, and new bugs that are created as a result. As the teams grow, the code changes more often and there are ever more features, more issues, and more bugs. Thorough manual testing becomes impossible the bigger your application gets and as you ship more frequently.
بیشتر زمانی کاربرد دارد که می‌خواهید اپلیکیشن خود را روی ماشینی میزبانی نمایید که فاقد dot Net Runtime می‌باشد.
Publishing your app as native AOT produces an app that is self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps start up very quickly and use less memory. Users of the application can run it on a machine that doesn't have the .NET runtime installed.
There are a lot of things to consider when choosing your database. Choose wisely because you’ll be married to that database for a long time. One case study is Amazon Marketplace which started with Oracle and tried to migrate after developing their own database solutions. The migration took somewhere between 5 to 10 years, and they seem to be still partially using Oracle. Though if your company reaches Amazon scale, then you’re probably doing very well.
بهتر است به جای اینکه برای حذف یک entity دو بار دیتابیس را فراخوانی کنیم (یکبار برای بازیابی آن براساس id و یکبار برای اجرای فرمان حذف آن از دیتابیس) توسط کد زیر فقط یکبار به بانک کوئری بزنیم. البته این موضوع برای قبل از EF7 کاربرد دارد. خود EF7 دارای متد ExecuteDeleteAsync می باشد که این مشکل را مرتفع کرده است.
{
try
{
var person = db.Persons.Attach(new Person { Id = id });
person.State = EntityState.Deleted;
await db.SaveChangesAsync(); // 1 database call
}
catch (DbUpdateConcurrencyException e)
{
Console.WriteLine(e);
// will happen if record no longer exists
}
} 