مبانی ASP.Net Core (دات نت 5)

در این مقاله موضوعات کلیدی برای درک نحوه توسعه برنامه‌های ASP.NET Core را مرور می کنیم.

The Startup class

کلاس Startup جایی است که:

• سرویس های مورد نیاز برنامه configure (پیکربندی) شده است.
• همچنین app's request handling pipeline (پایپ لاینِ هندل کردن request ِ برنامه) به صورت مجموعه ای ازmiddleware component ها define (تعریف) می شود.

اینجا یک نمونه از کلاس Startup آورده شده است:

برای اطلاعات بیشتر، App startup in ASP.NET Core را ببینید.

Dependency injection (services)

در واقع ASP.NET Core شامل یک فریم ورک built-in (داخلیِ) تزریق وابستگی ( DI - Dependency injection) است که سرویس های Configure شده را در سراسر یک برنامه در دسترس قرار می دهد (available می کند). به عنوان مثال، یک logging component (کامپوننت ورود به سیستم) یک سرویس است .

کدی برای configure (یا ثبت نام (register)) سرویس ها به متد Startup.ConfigureServices اضافه می شود. مثلا:

سرویس ها معمولاً از DI با استفاده از constructor injection (تزریق سازنده) حل می شوند. با constructor injection، یک کلاس یک پارامتر constructor از typeِ مورد نیاز یا یک interface را declare می کند. DI framework نمونه (instance) ای از این سرویس را در زمان اجرا (runtime) ارائه می دهد.

مثال زیر از constructor injection برای حل یک RazorPagesMovieContext از DI استفاده می کند:

اگر کانتینر Inversion of control (IoC) همه نیازهای یک برنامه را برآورده نکند، می توان به جای آن از یک third-party IoC container استفاده کرد.

برای اطلاعات بیشتر، به تزریق وابستگی در ASP.NET Core مراجعه کنید :

Dependency injection in ASP.NET Core

Middleware

در واقع request handling pipeline از یک سری ازmiddleware component ها تشکیل شده است. هر component (جزء) عملیاتی را بر روی یک HttpContext انجام می دهد و middleware بعدی را در pipeline فراخوانی می کند یا request (درخواست) را خاتمه می دهد (terminate می کند).

طبق قرارداد، یک middleware component با فراخوانی (invoke کردن) اکستنشن متدِ Use... در متد Startup.Configure به pipeline اضافه می‌شود. به عنوان مثال، برای فعال کردن رندر فایل‌های استاتیک، UseStaticFiles را فراخوانی (invoke) کنید.

مثال زیر یک request handling pipeline را configure می کند:

همچنین ASP.NET Core شامل مجموعه ای غنی از مmiddleware های built-in است. می توانید middleware های custom نیز بنویسید.

برای اطلاعات بیشتر، ASP.NET Core Middleware را ببینید:

ASP.NET Core Middleware

Host

در هنگام راه اندازی (startup)، یک برنامه ASP.NET Core یک host می سازد. هاست تمام ریسورس های برنامه را encapsulate می کند، مانند:

• ا اجرای سرورِ HTTP (همون An HTTP server implementation) ا
• ا Middleware components ا
• ا Logging ا
• اDependency injection (DI) servicesا
• اConfigurationا

دو هاست مختلف وجود دارد:

• .NET Generic Host
• ASP.NET Core Web Host

معمولا میزبان هاستِ جنریکِ دات نت (.NET Generic Host) توصیه می شود. ASP.NET Core Web Host فقط برای سازگاری با backwards در دسترس (available) است.

مثال زیر یک هاست جنریک دات نت ایجاد می کند:

متدهای CreateDefaultBuilder و ConfigureWebHostDefaults یک هاست را با مجموعه ای از option های پیش فرض configure می کنند، مانند:

• استفاده از Kestrel به عنوان وب سرور و فعال کردن IIS integration .
• لود کردن configuration از appsettings.json, appsettings.{Environment Name}.json, environment variables, command line arguments, و سورس های دیگر.
• ارسال logging output به کنسول و debug provider ها.

برای اطلاعات بیشتر، به .NET Generic Host در ASP.NET Core مراجعه کنید.

.NET Generic Host in ASP.NET Core

Non-web scenarios

گفته شده Generic Host (هاستِ عمومی) به انواع دیگر برنامه ها اجازه می دهد تا از اکستنشن های فریم ورکِ cross-cutting استفاده کنند. مانند

logging, dependency injection (DI), configuration, and app lifetime management.

برای اطلاعات بیشتر، به .NET Generic Host in ASP.NET Cor و Background tasks with hosted services in ASP.NET Cor مراجعه کنید.

Servers

یک برنامه ASP.NET Core از implementation ِ HTTP server برای گوش دادن به request های HTTP استفاده می کند. سرور request ها را به‌عنوان مجموعه‌ای از فیچرهای درخواستی که در یک HttpContext تشکیل شده‌اند، به برنامه ارائه می‌کند.

ا ASP.NET Core در واقع server implementation های زیر را ارائه می دهد:

ویندوز:

• ا Kestrel یک وب سرور کراس پلتفرم است. Kestrel اغلب در یک configuration پروکسی معکوس با استفاده از IIS اجرا می شود. در ASP.NET Core 2.0 یا جدیدتر، Kestrel می تواند به عنوان یک سرور عمومی (public-facing edge) که مستقیماً در معرض اینترنت قرار دارد اجرا شود.
• و IIS HTTP Server سروری برای ویندوز است که از IIS استفاده می کند.
• و HTTP.sys سروری برای ویندوز است که با IIS استفاده نمی شود.

مک و لینوکس:

• ا ASP.NET Core پیاده سازی سرور کراس پلتفرم Kestrel را ارائه می دهد. در ASP.NET Core 2.0 یا جدیدتر، Kestrel می تواند به عنوان یک سرور لبه عمومی (public-facing edge) که مستقیماً در معرض اینترنت قرار دارد اجرا شود. Kestrel اغلب در یک configuration پروکسی معکوس با Nginx یا Apache اجرا می شود.

برای اطلاعات بیشتر، به پیاده سازی وب سرور در ASP.NET Core مراجعه کنید:

Web server implementations in ASP.NET Core

Configuration

ا ASP.NET Core یک فریم ورک configuration ارائه می دهد که تنظیمات را به عنوان زوج نام-مقدار (name-value pairs) از مجموعه ی مرتب شده ای از ارائه دهندگان configuration دریافت می کند.

ا Built-in configuration provider ها برای سورس های مختلفی مانند فایل‌های json.، فایل‌های xml.، متغیرهای محیطی و آرگومان‌های خط فرمان (کامند لاین) در دسترس هستند. برای ساپورت کردن (پشتیبانی کردن از) سورس های دیگر configuration provider های custom را بنویسید.

به طور پیش‌فرض، برنامه‌های ASP.NET Core برای خواندن از appsettings.json، متغیرهای محیطی (environment variables)، command line و موارد دیگر configure شده‌اند. هنگامی که configuration برنامه لود می شود، مقادیر متغیرهای محیطی مقادیر appsettings.json را اورراید می کنند. روش ترجیحی برای خواندن ولیوهای configuration مرتبط، استفاده ازoptions pattern است. برای اطلاعات بیشتر، بایند کردنِ داده‌های configuration سلسله مراتبی را با استفاده از options pattern ببینید.

Bind hierarchical configuration data using the options pattern.

برای مدیریت داده های configurationِ محرمانه مانند پسورد ها، NET Core، Secret Manager را ارائه می دهد. برای محصولات سکرت، Azure Key Vault را پیشنهاد می کنیم.

برای اطلاعات بیشتر به configuration در ASP.NET Core مراجعه کنید.

Configuration in ASP.NET Core

Environments

محیط های اجرایی (Execution environments) مانند Staging ،Development و Production مفاهیم اولیه در ASP.NET Core هستند. با set کردن environment variable (متغیر محیطیِ (محلی)) ASPNETCORE_ENVIRONMENT، محیطی را که یک برنامه در آن اجرا می شود، مشخص می کنید. ASP.NET Core آن متغیر محیطی را هنگام راه اندازی برنامه (app startup) می خواند و مقدار (value) را در پیاده سازی IWebHostEnvironment ذخیره می کند. این پیاده سازی در هر نقطه از برنامه از طریق تزریق وابستگی (DI) available است.

مثال زیر برنامه را طوری configure می‌کند که جزئیات اطلاعات error را هنگام اجرا در محیط Development ارائه کند:

برای اطلاعات بیشتر، استفاده از چندین enviroment در ASP.NET Core را ببینید.

Logging

ا ASP.NET Core از یک API ورود به سیستم پشتیبانی می کند که با انواع provider های built-in و third-party کار می کند. provider های موجود عبارتند از:

• Console
• Debug
• Event Tracing on Windows
• Windows Event Log
• Traceource
• Azure App Service
• Trace Sourcecation Insights

برای ایجاد log ها، یک سرویس <#>ILogger (به جای # ، TCategoryName در نظر بگیر)را از تزریق وابستگی (DI) و فراخوانی متدهای logging مانند LogInformation قرار بدهید. مثلا:

متدهای logging مانند LogInformation از هر تعداد فیلد پشتیبانی می‌کنند. این فیلدها معمولاً برای ساخت یک پیام string استفاده می‌شوند، اما برخی از logging provider ها آن‌ها را به عنوان فیلدهای جداگانه به یک data store ارسال می‌کنند. این feature این امکان را به logging provider می دهد تا semantic logging را پیاده سازی کنند که به عنوان structured logging نیز شناخته می شود.

برای اطلاعات بیشتر، به Logging در .NET Core و ASP.NET Core مراجعه کنید.

Logging in .NET Core and ASP.NET Core.

Routing

یک route یک پترنِ URL است که به یک handler, درواقع map می شود. handler عموما Razor page، یک متد action در کنترلر MVC یا یک middleware است. و ASP.NET Core routing به شما امکان کنترل URL های مورد استفاده توسط برنامه را می دهد.

برای اطلاعات بیشتر، routing در ASP.NET Core را ببینید:

Routing in ASP.NET Core.

Error handling

ا ASP.NET Core دارای فیچر های bult-in برای handle کردن خطاها است، مانند:

• A developer exception page
• Custom error pages
• Static status code pages
• Startup exception handling

برای اطلاعات بیشتر، به Handle errors در ASP.NET Core مراجعه کنید:

Handle errors in ASP.NET Core.

Make HTTP requests

پیاده سازی IHttpClientFactory برای ایجاد instance های HttpClient در دسترس است. این factory:

• یک location ِ مرکزی برای نامگذاری و instance ِ configuring های HttpClient منطقی فراهم می کند. به عنوان مثال، یک کلاینت github را برای دسترسی به GitHub ثبت و configure می کند. یک کلاینت پیش فرض را برای مقاصد دیگر ثبت و configure می کند.
• پشتیبانی از ثبت و زنجیره ای از چندین delegating handler برای ایجاد request middleware pipeline خروجی. این pattern مکانیزمی را برای مدیریت concern های مقطعی (cross-cutting)برای درخواست های HTTP، از جمله caching، error handling، serialization و logging فراهم می کند.
• با Polly، یک کتابخانه third-party محبوب برای هندل کردن خطاهای transient (گذرا) می شود.
• برای جلوگیری از مشکلات رایج DNS که هنگام مدیریت lifetimeهای HttpClient به صورت دستی رخ می دهد، lifetime و pooling نمونه (instance) های اصلی HttpClientHandler را مدیریت می کند.
• یک تجربه configurable logging (ورود به سیستم قابل تنظیم) را از طریق ILogger برای تمام درخواست‌های ارسال شده از طریق کلاینت‌های ایجاد شده توسط factory اضافه می‌کند.

برای اطلاعات بیشتر، به ایجاد درخواست های HTTP با استفاده از IHttpClientFactory در ASP.NET Core مراجعه کنید:

Make HTTP requests using IHttpClientFactory in ASP.NET Core

Content root

ا content root مسیر اصلی برای:

• The executable hosting the app (.exe) (هاستینگ قابل اجرای برنامه)
• Compiled assemblies that make up the app (.dll)

(اسمبلی های کامپایل شده که برنامه را تشکیل می دهد)

• Content files used by the app, such as:

- Razor files (.cshtml, .razor)

- Configuration files (.json, .xml)

- Data files (.db)

فایل های محتوا که توسط برنامه استفاده می شوند مانند:

-- - فایل های Razor

-- - فایل های configuration

-- - فایل های دیتا

• The Web root, typically the wwwroot folder

روتِ وب، معمولا فولدر wwwroot

در طول توسعه (development)، content root به طور پیش فرض به دایرکتوری root پروژه می رسد. این دایرکتوری همچنین مسیر اصلی فایل های محتوای برنامه و Web root است. با تنظیم مسیر (path) آن هنگام ساخت هاست (building the host)، content root متفاوتی را مشخص کنید.

برای اطلاعات بیشتر، Content root را ببینید: Content root

Web root

ا web root مسیر پایه برای ریسورس فایل های public و static است، مانند:

• Stylesheets (.css)
• JavaScript (.js)
• Images (.png, .jpg)

به‌طور پیش‌فرض، فایل‌های استاتیک فقط از web root و زیرشاخه‌های (sub-directory) های آن ارائه می‌شوند. مسیر web root به صورت پیش فرض {content root}/wwwroot است. یک web root متفاوت را با تنظیم مسیر آن هنگام ساخت هاست مشخص کنید

برای اطلاعات بیشتر، Content root را ببینید: Web root

جلوگیری از انتشار فایل ها در wwwroot با ایتم پروژه <Content> در فایل پروژه. مثال زیر از انتشار content در wwwroot/local و زیرمجموعه‌های آن جلوگیری می‌کند:

در فایل‌های Razor .cshtml علامت tilde-slash (/~) به روت وب اشاره می‌کند. مسیری که با /~ شروع می شود به عنوان virtual path نامیده می شود.