نظرات مطالب
نوشتن Middleware سفارشی در ASP.NET Core

یک نکته‌ی تکمیلی: کار با اینترفیس IMiddleware جهت تعریف میان‌افزارهای سفارشی

اگر امروز قصد تعریف میان‌افزارهای سفارشی را دارید، بهتر است از روش باز public async Task Invoke(HttpContext context) که در این مطلب معرفی شد، دیگر استفاده نکنید؛ چون مهم‌ترین محدودیت‌های آن، داشتن طول عمر Singleton غیرقابل تغییر و همچنین عدم امکان پیاده سازی اینترفیس IDisposable در آن جهت پاکسازی خودکار منابع است. امروز روش توصیه شده‌، استفاده از اینترفیس IMiddleware است. در این حالت متد Task Invoke فوق، به متد مشخص و ثابت Task InvokeAsync(HttpContext context, RequestDelegate next) تغییر می‌کند. چون در این حالت دیگر نمی‌توان پارامترهای این متد مشخص را مانند قبل که اینترفیسی را پیاده سازی نمی‌کرد، به صورت پویا کم و زیاد کرد، می‌توان سرویس‌های مدنظر را به سازنده‌ی کلاس، تزریق کرد. به همین جهت نیاز است، آن‌را به نحو زیر به سیستم تزریق وابستگی‌ها معرفی کرد:

builder.Services.AddTransient<MyNewMiddleware>();

این الزام به تعریف آن به صورت یک سرویس رسمی، مزیت‌های زیر را به همراه دارد:

الف) می‌توان طول عمری، غیر از Singleton را هم در صورت نیاز، تعریف کرد (و مشکل کار با سرویس‌هایی با طول عمرهای غیر از Singleton کمتر می‌شود).

ب) چون طول عمر این میان‌افزار اکنون توسط سیستم تزریق وابستگی‌ها مدیریت می‌شود، اگر این میان‌افزار اینترفیس IDisposable را پیاده سازی کند، کار پاکسازی منابع آن خودکار خواهد شد.

نکته 1: روش معرفی آن به سیستم تزریق وابستگی‌ها، به صورت Concrete type است؛ یعنی اصل کلاس باید معرفی شود (مانند سطر فوق) و نه اینکه به صورت متداول زیر به همراه ذکر اینترفیس IMiddleware باشد:

builder.Services.AddTransient<IMiddleware, MyNewMiddleware>();

مابقی کار با آن، با میان‌افزارهای متداول، تفاوتی ندارد. یعنی قسمت UseMiddleware آن یکی است:

app.UseMiddleware<MyNewMiddleware>();

بنابراین این روش نسبت به روش متداول قبلی، دو تفاوت پیاده سازی اینترفیس مشخص IMiddleware و ثبت کلاس آن به صورت یک سرویس رسمی را دارد؛ مابقی نکات آن، مانند قبل است.

نکته 2: اگر از Scrutor برای ثبت خودکار سرویس‌های برنامه استفاده می‌کنید، روش ثبت خودکار اینگونه سرویس‌ها به صورت زیر و با استفاده از متد ()AsSelf است:

services.Scan(scan => scan.FromAssembliesOf(typeof(IDataSeedersRunner))
            .AddClasses(classes => classes.Where(type =>
            {
                var allInterfaces = type.GetInterfaces();

                return allInterfaces.Contains(typeof(IMiddleware)) && 
                       allInterfaces.Contains(typeof(ISingletonService));
            }))
            .AsSelf()
            .WithSingletonLifetime());

در این مثال، تمام IMiddleware هایی که با نشانگر ISingletonService هم مزین شده‌اند، یافت شده و به صورت Concrete type هایی، با طول عمر Singleton، به سیستم تزریق وابستگی‌ها اضافه می‌شوند.

نظرات مطالب
MongoDb در سی شارپ (بخش اول)
در جدیدترین نسخه‌های اخیر روش کار به شکل زیر تغییر کرده است:
برای دریافت آخرین نسخه درایور به کتابخانه زیر مراجعه فرمایید:
dotnet add package MongoDB.Driver
همچنین برای درج Id در مدل‌ها بهتر است به شکل زیر عمل شود:
public class Book
    {
        [BsonId]
        [BsonRepresentation((BsonType.ObjectId))]
        public string Id { get; set; }
    }
با اولین ویژگی این خصوصیت را کلید اصلی معرفی میکنیم و در ویژگی دوم میگوییم این نوع قرار است یک ObjectId باشد ولی زحمت تبدیل این کلید به رشته یا بلعکس در پشت صحنه انجام میگردد  از این لحاظ شما لازم نیست با نوع ObjectId چالشی داشته باشید.

نظرات مطالب
Blazor 5x - قسمت یازدهم - مبانی Blazor - بخش 8 - کار با جاوا اسکریپت
آیا راه حلی برای فراخوانی متدهای غیر استاتیک #C از طریق کدهای جاوااسکریپتی در یک فایل js وجود دارد؟ برای مثال API گوگل مپ جزییات یک آدرس درخواست شده را به یک فایل js برمیگرداند، از چه روشی میتوان این مقدار را به کامپوننت برای پردازش و ذخیره ارسال کرد؟ 

کامپوننتی که کار پردازش نتیجه API را انجام میدهد باید خروجی خود را بصورت یک EventCallBack به والد خود برای ذخیره ارسال کند، از این جهت متدها استاتیک نیستند. آیا از روش غیر استاتیک که معرفی کردید برای این سناریو میشود استفاده کرد یا روش دیگری وجود دارد؟ 
ممنون.
نظرات مطالب
Blazor 5x - قسمت دهم - مبانی Blazor - بخش 7 - مسیریابی
یک نکته‌ی تکمیلی: امکان قرار دادن کامپوننت‌های Blazor در یک اسمبلی دیگر و مشکل مسیریابی
می‌توان کامپوننت‌های مورد نظر را در یک اسمبلی دیگر (بجز برنامه‌ی اصلی) قرار دارد؛ اما در این حالت و پس از افزودن ارجاعی به آن‌ها در فایل csproj برنامه‌ی اصلی، اگر در آن‌ها مسیریابی را تعریف کرده باشید، کار نمی‌کنند. برای رفع این مشکل باید به فایل app.razor مراجعه کرد و سپس این اسمبلی‌های ثالث را به سیستم مسیریابی معرفی نمود:
<Router
    AppAssembly="@typeof(Program).Assembly"
    AdditionalAssemblies="new[] { typeof(Component1).Assembly }">
    @* ... Router component elements ... *@
</Router>
در اینجا ویژگی AdditionalAssemblies، آرایه‌ای از اسمبلی‌های ثالث به همراه کامپوننت‌های Blazor را می‌پذیرد.
نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 14 - لایه بندی و تزریق وابستگی‌ها
با عرض سلام و تشکر
1. در پروژه برای کلاس Product و Category، مثالی برای اعمال CRUD در سطح کنترلر ارائه نشده، یا من پیدا نکردم؟ یا چون در بحث Identity نبوده تکمیل نشده این قسمت.
در این پروژه آیا برای انجام عملیات CRUD، به روشی که در پروژه «اعتبار سنجی مبتنی بر Jwt در ASP.net Core 2.0 بدون استفاده از سیستم Identity» معرفی کردین عمل کنم ؟

2. تفاوت طراحی این دو پروژه در قسمتهای تزریق وابستگی، و دقیقا انجام عملیات CRUD در کنترلرهای سطح پروژه وب، چیست ؟

نظرات مطالب
تنظیمات CORS در ASP.NET Core
یک نکته‌ی تکمیلی: دریافت خطای CORS پس از نصب تازه‌ی NET Core SDK.
پس از نصب تازه‌ی NET Core SDK. و ارسال پیامی از طرف برنامه، ممکن است خطاهای زیر را مشاهده کنید که از طرف مرورگر به اشتباه، خطای CORS گزارش می‌شوند:
در فایرفاکس:

در کروم:

برای رفع این مشکل فقط کافی است دو دستور زیر را با دسترسی مدیریتی اجرا کنید:

dotnet dev-certs https --clean
dotnet dev-certs https --trust
تا مجوز SSL آزمایشی NET Core.، به صورت امنی به سیستم معرفی شود.
این تنظیمات، نیاز به ری‌استارت کامل سیستم را هم دارند و تا آن زمان، باز هم خطاهای یاد شده را در مرورگرها مشاهده خواهید کرد.
نظرات مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت ششم - کار با User Claims
- بله. مفهوم یک سیستم «مرکزی» همین هست. نمونه‌اش اکتیو دایرکتوری در دومین‌های سرورهای ویندوزی است که کار مدیریت کاربران و سطوح دسترسی آن‌ها را یک یا چند نفر کارمند تمام وقت به نام مدیر شبکه انجام می‌دهد و این تعاریف به صورت مجزایی در کلاینت‌های متصل، انجام نمی‌شوند. در این سری در انتهای آن روشی برای ثبت اطلاعات کاربران در بانک اطلاعاتی پیشنهاد شده. علاوه بر آن چند پیاده سازی کننده‌ی سورس باز مدیریت IDP هم معرفی شده‌اند.
- در اینجا هر کلاینت ASP.NET Core هم می‌تواند سطوح دسترسی سفارشی و پیچیده‌تر خاص خودش را بر اساس ترکیب Claims و نقش‌های دریافتی از IDP، تعریف و تنظیم کند.
نظرات مطالب
React 16x - قسمت 31 - React Hooks - بخش 2 - مقایسه حالت‌های مختلف مدیریت حالت با useState Hook
- همانطور که عنوان شد، Stateless Functional Component دیگر وجود خارجی ندارند (به لطف هوک‌ها و دیگر Stateless نیستند) و الان فقط Functional Component هستند.
- پیشتر هم که Stateless بودند، توصیه شده بود که ابتدا با کامپوننت‌های تابعی شروع به کار کنید و اگر نیاز به state وجود داشت، آن‌را به کامپوننت‌های کلاسی ارتقاء دهید (که الان، حالت را هم در کامپوننت‌های تابعی می‌توان داشت).
- کامپوننت‌های تابعی در React 16 اندکی سریعتر هستند (نقل قولی از یکی از عضای تیم React):
Functional components should be slightly faster in React 16 as there's no instance created to wrap them (unlike React 15). 
علت آن عدم نیاز به React.createElement جهت معرفی نهایی آن‌ها است.
نظرات مطالب
امن سازی برنامه‌های ASP.NET Core توسط IdentityServer 4x - قسمت چهاردهم- آماده شدن برای انتشار برنامه
برای درک این سیستم از قسمت آخر آن شروع نکنید. در قسمت‌های قبل در مورد مفهوم یک سیستم تامین هویت مرکزی، مفهوم کلاینت‌ها و دسترسی دادن به آن‌ها در یک IDP (نه دسترسی دادن به کاربران)، امکان محدود کردن دسترسی کاربران به قسمت‌های مختلف برنامه‌ها و یا Web APIها توسط User Claims آن‌ها و ... مفصل بحث شده‌است.
برای مثال زمانیکه برنامه‌ای (کلاینتی) به IDP گوگل معرفی می‌شود، آیا تمام کاربران گوگل به آن دسترسی پیدا می‌کنند؟ بله. تمام آن‌ها بدون استثناء.
اما آیا تمام آن‌ها می‌توانند با قسمت‌های مختلف برنامه‌ی ما کار کنند؟ خیر. نحوه‌ی مدیریت دسترسی‌های این کاربران، در قسمت‌های قبلی بحث شده‌اند.
نظرات مطالب
سفارشی سازی ASP.NET Core Identity - قسمت سوم - نرمال سازها و اعتبارسنج‌ها
- سیستم Identity فقط با یک نمونه‌ی از IUserValidator کار می‌کند. 
- اگر چندین پیاده سازی یک اینترفیس را به سیستم تزریق وابستگی‌ها معرفی کنید، استفاده‌ی از آن‌ها نکات خاصی را به همراه دارند که در سری مهارت‌های تزریق وابستگی‌های NET Core. بحث خواهند شد.
- زمانیکه قصد ندارید از IUserValidator پیش‌فرض این سیستم در remote validation خاص یک نقطه‌ی ویژه‌ی برنامه استفاده کنید، نیازی هم به تعریف یا سفارشی سازی آن ندارید. منطق سفارشی خودتان را به هر نحوی که مایل بودید تعریف کنید، چون جای دیگری استفاده نخواهد شد. یک سرویس Validator جدید خاص خودتان را تعریف کنید که دو متد بررسی تعیین اعتبار کاربر یا ایمیل را داشته باشد. سپس این سرویس را به صورت مستقل و جدای از IUserValidator سیستم Identity تزریق و استفاده کنید. دستکاری IUserValidator خود Identity، قسمت‌های دیگر سیستم شما را هم تحت تاثیر قرار خواهد داد.