مفاهیم ASP.NET Core

asp.net core

Core یک فریمورک Open-Source (متن باز و رایگان) و Multi-Platform (چندسکویی) برای توسعه ی اپلیکیشن های تحت وب، دسکتاپ و موبایل است که در واقع جانشین ASP.NET شده است. ASP.NET Core یک فریمورک ماژولار با استاندارد Apache License 2.0 است که امکان اجرا هم بر روی ویندوز (.NET Framework) و هم در پلتفرم های دیگر را دارد. گرچه ASP.NET Core ورژن 3 تنها با نسخه ی منسوخ شده ی .NET Framework و سایر پلتفرم ها کار می کند.

ASP.NET Core بیشتر برای بهینه سازی و توسعه فریمورک های مبتنی بر Cloud-Computing پیاده سازی شده است. این فریمورک شامل کامپوننت های ماژولار همراه با کمترین بار اضافی بر روی سرور است که باعث افزایش انعطاف پذیری سیستم در زمان طراحی و پیاده سازی می شود.

ASP.NET Core بسیار سبک و سریع است و استفاده از آن امری عاقلانه است چرا که سرعت یکی از فاکتورهای مهم در سئو سایت محسوب می شود.

معرفی NET 5.

dot net 5

به تازگی مایکروسافت از آخرین نسخه ی .NET Core یعنی .NET 5 رونمایی کرده است. .NET 5 یک فریمورک واحد است که تمام ویژگی های .NET Core و .NET Framework و Mono Xamarin را یکجا در دل خود دارد. در .NET 5 ، بیشتر تغییرات، در هسته ی فریمورک رخ داده است و نحوه ی کدنویسی ها تغییر چندانی نکرده است.

چون در .NET 5 تمام API های دات نت یک جا جمع شده اند، برنامه نویسان می توانند تنها با استفاده از یک کد، برنامه هایشان را در پلتفرم های مختلف اجرا کنند. حجم پایین SDK ها و استفاده از یک CLI واحد سبب شده تا .NET 5 طرفداران زیادی پیدا کند.

وب سرور ها در NET Core.

در  ASP.NET Core  وب سرور ها به دو دسته تقسیم می شوند:

  • In Process مانند IIS Express و IIS
  • Out of Process که به دو دسته تقسیم می شود:
    • Internal Web Server مانند Kestrel
    • External Web Server مانند IIS ، Nginx و یا Apache (بستگی به سیستم عامل دارد)

در In-Process پروژه در همان process ای اجرا می شود که IIS Worker اجرا می شود. نام Process ای که IIS را اجرا می کند w3wp.exe است و نام Process ای که IIS Express را اجرا می کند iisexpress.exe است.

تفاوت های بین In Process و Out of Process

In Process Out of Process
نام Process آن w3wp.exe یا iisexpress.exe است. نام Process آن dotnet.exe است.
فقط یک وب سرور وجود دارد. دو یا چند وب سرور وجود دارند.
کارایی In Process از Out of Process بیشتر است. همیشه پاس کاری بینInternal Web Server و External Web Server وجود دارد. (Proxying Requests)

در فایل csproj پروژه می توان نوع وب سرور (Hosting Model) را مشاهده کرد. در کد زیر که مربوط به فایل csproj پروژه است، نوع Hosting Model مشخص است.

<Project Sdk=Microsoft.NET.Sdk.Web>

<PropertyGroup>

<TargetFramework>netcoreapp3.1</TargetFramework>

<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>

</PropertyGroup>

</Project>

Kestrel چیست؟

kestrel mrbitmap

قبلا، برنامه های ASP.NET نیاز داشتند تا در IIS اجرا شوند. یعنی IIS یک Process معروف به نام Application Pool یا w3wp را اجرا می کرد و این فرایند مسئولیت راه اندازی نرم افزار و هدایت درخواست ها و مدیریت چرخه عمر آن ها را بر عهده داشت. در نتیجه برنامه ها به IIS وابسته بوده و عملا خارج از محیط آن نمی توانستند به حیات ادامه دهند.

در NET Core. برای آنکه وابستگی به IIS و سیستم عامل ویندوز از بین برود و بتوان در سیستم عامل های دیگر هم اپلیکیشن های ASP.NET Core را اجرا کرد، از وب سروری به نام Kestrel استفاده می شود.

وب سرور Kestrel در تمام سیستم عامل ها اجرا می شود. این وب سرور بسیار ساده (Raw Web Server)، سبک و در عین حال سریع است. Kestrel به حدی ساده (Feature-less) طراحی شده که حتی نمی توان با آن اپلیکیشن هایی را در پورت 80 یا 443 داشت و همچنین از مدیریت SSL نیز خبری نیست. Kestrel هیچ مسئولیتی به جز دریافت درخواست های HTTP از سیستم عامل و سپردن آن ها به ASP.NET Core ندارد.

Kestrel یک Nuget Package است که در کنار برنامه قرار می گیرد. به این معنی که هر برنامه ASP.NET Core توسط وب سرور مربوط به خودش، درخواست های HTTP را دریافت می کند. این برخلاف IIS است که فقط یک نسخه از آن در سرور نصب می شود.

 برنامه های ASP.NET Core در واقع یک Console Application هستند که nuget مربوط به Kestrel را دارا بوده و در هنگام اجرا شدن خود (Startup) ، Pipeline مربوط به Kestrel را راه اندازی می کنند تا بتوانند درخواست های HTTP را دریافت کنند.

در هر سیستم عامل، Kestrel با لایه های مربوط به پروتکل HTTP در ارتباط بوده و می تواند درخواست ها را به سمت برنامه ها هدایت کند.

Reverse Proxy Server

reverse proxy server

وب سرور Kestrel بسیار سریع و ساده (feature-less) است. اگر نیاز باشد که از ویژگی های پیچیده و گسترده ی وب سرور های قدرتمند دیگر نظیر Apache، Nginx و IIS استفاده شود، چه باید کرد؟

روشی به نام Reverse Proxy Server این مشکل را حل خواهد کرد. به طور ساده، در این معماری، به جای استفاده از یک وب سرور، دو یا چند وب سرور وجود دارد. یک وب سرور به نام Reverse Proxy در لایه بیرونی خواهد بود و از بیرون دیده می شود. بدین معنی که این وب سرور در جایی قرار خواهد گرفت که درخواست های کاربران به سمت آن ها می آید. این وب سرور ها بر اساس نیاز، تغییراتی را بر روی درخواست ها انجام می دهند (مثلا آی پی های خاصی را بلاک می کنند یا مدیریت SSL را بر عهده خواهند داشت و یا load balancing و غیره). سپس وب سرور های بیرونی، درخواست ها را به یک IP و Port که در مرزهای داخلی هستند، ارسال می کنند.

با این استفاده از روش Reverse Proxy Server می توان از هر وب سروری برای مدیریت برنامه ها استفاده کرد.  مثلا مانند سابق، وب سرور IIS وجود خواهد داشت و تنظیمات لازم روی آن انجام می شود. اما این بار IIS یک Reverse Proxy است و قرار است درخواست ها را پس از اعمال تغییرات به یک پورت دیگر Forward و هدایت نماید. این پورت در واقع همان پورتی است که Kestrel مربوط به وب اپلیکشن مسئولیت اش را بر عهده گرفته است.

برای فهمیدن نوع وب سروری که در حال حاضر استفاده می شود در متد configure کلاس Startup از کد زیر استفاده می شود:

در حالت عادی موقع اجرای برنامه با VS از IIS Express استفاده می شود، در صورتی که بخواهیم با Kestrel برنامه را اجرا کنیم باید در cmd به root پروژه ی خود رفته و Command زیر را تایپ نماییم:

dotnet run

و با فشردن دکمه های زیر می توان وب سرور را متوقف کرد:

Ctrl + C

Middleware چیست؟

middleware چیست

از لحظه ای که درخواست HTTP وارد سرور می شود تا زمانی  پردازش شود، یک مسیری را طی می کند که به آن Pipleline یا خط لوله می گویند. در طول عبور از این خط لوله، امکان حذف و یا اضافه اطلاعات به درخواست HTTP وجود دارد این عملیات در طول گذر درخواست از Pipeline توسطه Middleware ها یا میان افزارها انجام می شود. به عبارتی دیگر Middleware قسمتی از نرم افزار است که HTTP Request ها و HTTP Response ها را مدیریت می کند.

چند نمونه از Middleware های رایج عبارت اند از: احراز اصالت کاربر، مدیریت خطاها، مدیریت اسکریپت ها و … به این شکل زیر دقت کنید:

pipeline middleware

توضیح: در تصویر بالا در داخل Pipleline چند middleware وجود دارند که اولی تاریخ و جزئیات درخواست یا پاسخ HTTP را ذخیره می کند. در صورتی که درخواست HTTP برای واکشی یک فایل استاتیک نظیر یک تصویر باشد، middleware وسطی شروع به کار میکند. در غیر این صورت middleware مربوط به MVC مدیریت درخواست را بر عهده می گیرد.

برای مشاهده و یا ایجاد middleware ها به سراغ فایل startup.cs و متد Configure بروید.

در کد بالا عبارت app.Run یک middleware را ایجاد می کند. context که به عنوان آرگومان به داخل این anonymous method پاس داده می شود همان درخواست ای است که وارد Pipeline شده است.

در کد زیر فقط اولین middleware اجرا می شود. چرا؟

Hello from 1st middleware

چون app.Run یک Terminal Middleware است.

Terminal Middleware چیست؟

یک نوع middleware است که در pipleline به سراغ middleware بعدی نمی رود. اگر بخواهیم middleware های دیگر هم اجرا شوند باید به جای app.run از app.use استفاده کنیم:

Hello from 1st middleware

Hello from 2nd middleware

نمایش static files در NET Core.

با کد زیر که در فایل startup.cs و در متد Configure است، می توان از فایل های استاتیک مانند عکس و … استفاده کرد. که این کد خود یک middleware است.

نمایش صفحه اصلی

در صورتی که تنظیمات مربوط به EndPoint (بعدا توضیح داده می شود) در پروژه ی ما وجود نداشته باشد و تنها بخواهیم یک صفحه ی HTML ساده را به عنوان صفحه ی اصلی نشان دهیم باید در root پروژه یک فایل html به نام default یا index ایجاد کنیم و در startup یک middleware بنویسیم تا صفحه ی default را بشناسد:

اگر بخواهیم صفحه ی دیگری غیر از default یا index به عنوان صفحه ی اصلی (روت) نشان داده شود از کد زیر استفاده می کنیم.

Development Environment

asp.net core environment

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

  • Development : این فاز در واقع محیط توسعه و کدنویسی نرم افزار است.
  • Staging : در این فاز، به تست نرم افزار پرداخته می شود.
  • Production : این فاز نهایی است و مشتریان تنها از نسخه ای از نرم افزار که در این فاز وجود دارد استفاده می کنند.

نگاهی به مدیریت Exception Page

در ASP.NET Core به راحتی می توان خطاها را مدیریت کرد. می توان مستقیما خطاهای سینتکسی را نشان داد و حتی می توان به جای آن، در مواجه با هر خطا، از صفحه ای پیشفرض ظاهر استفاده کرد و غیره. نشان دادن صفحه ی خطاهای سینتکسی برای توسعه دهندگان خیلی مهم است اما نشان دادن این خطاها به مشتریان کاری اشتباه است. می توان به صورت کد زیر تعیین کرد که تنها در صورتی که پروژه در فاز توسعه باشد خطاها را نشان دهد و در فازهای دیگر به اشکال دیگر به آن بپردازد.

این کد باید قبل از بقیه ی middleware ها باشد. و اگر بخواهیم آن را custom کنیم باید به شکل زیر عمل کنیم:

نوشته شده توسط mrbitmap علیرضا علی رمضانی

مقالات مرتبط

2 دیدگاه. ارسال دیدگاه جدید

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این فیلد را پر کنید
این فیلد را پر کنید
لطفاً یک نشانی ایمیل معتبر بنویسید.
برای ادامه، شما باید با قوانین موافقت کنید

جدیدترین مقالات

فهرست