اشتراکها
سشنها نیز همانند تمام قسمتهای دیگر یک برنامهی ASP.NET Core، به صورت پیش فرض غیرفعال هستند و نیاز به مراحل خاصی است تا امکان استفادهی از آنها فراهم شود. همچنین روش کار کردن با آنها نیز متفاوت است با نگارشهای قبلی ASP.NET (تمام نگارشها).
سشن چیست؟
شیء سشن، مجموعهای از اشیاء serialized مرتبط با جلسهی کاری جاری یک کاربر است. این اشیاء عموما در حافظهی محلی سرور ذخیره میشوند؛ اما امکان ذخیره سازی توزیع شدهی آنها در بانکهای اطلاعاتی نیز پیش بینی شدهاست.
عموما استفادهی از اشیاء سشن توصیه نمیشوند. از این جهت که این نوع اشیاء بسیار شبیه هستند به متغیرهای سراسری و وجود این نوع متغیرها اساسا ضعف طراحی شیءگرا به حساب میآیند. اما با توجه به ماهیت stateless بودن برنامههای وب، به این معنا که با پایان رندر یک صفحه، تمام اشیاء مرتبط با آنها نیز در سمت سرور تخریب میشوند، نیاز است برای یک سری از دادههای عمومی کاربر، راه حلی را پیدا کرد تا بتوان از اطلاعات آنها استفادهی مجدد کرد. برای مثال نگهداری رشتهی اتصالی بانک اطلاعاتی که کاربر در حین لاگین به سیستم آنرا انتخاب کردهاست (اگر برنامه به ازای هر سال از یک بانک اطلاعاتی مجزا استفاده میکند) و یا زمانیکه کاربری captcha را پر میکند و مقدار آنرا به سمت سرور ارسال میکند، نیاز است مقدار ارسالی او را با مقدار ابتدایی captcha مقایسه کرد. یک چنین اطلاعاتی نباید با پایان رندر صفحه تخریب شوند و نیاز است تا زمانیکه جلسهی کاری کاربر به پایان نرسیدهاست، در دسترس باشند. به همین جهت است که مفهومی را به نام «اشیاء سشن» طراحی کردهاند.
درکل خارج از این موارد بهتر است از سشن استفاده نکنید و در جای جای برنامهی خود ردپای آنرا باقی نگذارید و به خاطر داشته باشید:
متغیر سشن = متغیر سراسری = ضعف طراحی شیءگرا
توصیهی به استفادهی از روشهای سبک وزنتر
سشنها تنها روش به اشتراک گذاری اطلاعات نیستند. اگر میخواهید اطلاعاتی را در بین میان افزارهای برنامه در طی یک درخواست به اشتراک بگذارید، شاید سشن هم یک راه حل باشد؛ اما راه حلی سنگین وزن. راه حل بهتر برای این موارد، استفادهی از HttpContext.Items است. HttpContext.Items نیز همانند سشن، یک key/value store است؛ اما طول عمر آن محدود است به طول عمر درخواست جاری و در تمام میان افزارهای برنامه در دسترس است.
برای مثال در یک میان افزار آنرا تنظیم میکنید:
و سپس در میان افزاری دیگر از آن استفاده خواهید کرد:
فعال سازی سشنها در ASP.NET Core
ASP.NET Core یک choose-what-you-need framework است. به این معنا که تا زمانیکه قابلیتی را به صورت صریح فعال سازی نکرده باشید، در دسترس نخواهد بود. همین مساله در نهایت به کاهش مصرف منابع این نوع برنامهها و همچنین طراحی ماژولار سیستم ختم میشوند. برای مثال در نگارشهای قبلی ASP.NET (تمام نگارشها)، سشنها به صورت پیش فرض فعال هستند، مگر آنکه HTTP Module آنرا در فایل web.config حذف کنید؛ اما در اینجا برعکس است.
اگر تنها در موارد خاصی که ذکر شد، نیاز به استفادهی از متغیرهای سشن را داشتید، روش فعال سازی آن به صورت ذیل است:
الف) نصب بستهی نیوگت Microsoft.AspNetCore.Session
برای این منظور وابستگی ذیل را به فایل project.json اضافه کنید:
ب) انجام تنظیمات آغازین برنامه
برای این کار به کلاس آغازین برنامه مراجعه کرده و ابتدا سرویس سشنها را فعال کنید:
و سپس در متد Configure، استفادهی از سشنها را نیز باید ذکر کنید:
در اینجا امکان سفارشی سازی مقادیر پیش فرض مدیریت سشنها نیز وجود دارند. برای مثال زمان پیش فرض انقضای سشن کاربر، پس از 20 دقیقه عدم فعالیت او است که قابل تغییر میباشد:
روش استفادهی از سشنها
در مثال ذیل نحوهی ذخیره سازی اطلاعات را در شیء سشن جلسهی جاری یک کاربر، ملاحظه میکنید:
به همراه نحوهی بازیابی این اطلاعات در متدهای دیگر برنامه:
همانطور که ملاحظه میکنید، سه متد Set، SetInt32 و SetString در اینجا برای تنظیم key/valueهای سشن، از پیش موجود هستند.
حالت Set آن آرایهای از بایتها را دریافت میکند و میتوان برای حالت serialization اشیاء، مفید باشد.
دقیقا معادل همین سه متد، متدهای Get، GetInt32 و GetString برای بازیابی مقادیر سشن طراحی شدهاند و باید دقت داشت که خروجیهای اینها میتوانند نال نیز باشند. به همین جهت خروجی GetInt32 آن نال پذیر است.
توسعهی متدهای پیش فرض کار با سشنها
سه متد یاد شدهی کار با سشنها در ASP.NET Core هرچند ضروری هستند، اما کافی نیستند. برای توسعهی آنها میتوان متدهای الحاقی را تدارک دید که نمونهای از آنها را ذیل مشاهده میکنید:
در اینجا با استفاده از کلاس BitConverter و امکان سریالایز مقادیر توسط آن به آرایهای از بایتها، امکان کار با متدهای عمومی Set و Get را یافتهایم.
و یا جهت کار با اشیاء پیچیدهتر میتوان از کتابخانهی JSON.NET استفاده کرد. به عبارتی در این نگارش از ASP.NET، کار سریالایز و دیسریالایز اشیاء، به برنامه نویس واگذار شدهاست و اینکه در پشت صحنه از چه کتابخانهای میخواهید استفاده کنید، در اختیار خودتان است.
البته باید دقت داشت که در اینجا وابستگی JSON.NET به صورت خودکار در دسترس است. از این جهت که بسیاری از وابستگیهای ASP.NET Core مانند مورد ذیل، به JSON.NET وابستهاند و نصب آنها به معنای نصب خودکار JSON.NET نیز هست:
اگر لیست بستههای وابستهی به JSON.NET را میخواهید مشاهده کنید، فایل project.lock.json را گشوده و در آن Newtonsoft.Json را جستجو کنید.
یک مطلب تکمیلی
در اینجا نیز امکان ذخیره سازی سشنها در بانک اطلاعاتی بجای حافظهی فرار سرور درنظر گرفته شدهاست و برای این حالت، بانکهای اطلاعاتی NoSQL ویژهای به نام key/value stores مانند بانک اطلاعاتی فوق سریع Redis پیشنهاد میشود؛ هرچند امکان کار با SQL Server نیز در اینجا وجود دارد، اما برای کش سرورهای مبتنی بر key/value ها، بانک اطلاعاتی Redis، انتخاب اول است.
Managing Application State
سشن چیست؟
شیء سشن، مجموعهای از اشیاء serialized مرتبط با جلسهی کاری جاری یک کاربر است. این اشیاء عموما در حافظهی محلی سرور ذخیره میشوند؛ اما امکان ذخیره سازی توزیع شدهی آنها در بانکهای اطلاعاتی نیز پیش بینی شدهاست.
عموما استفادهی از اشیاء سشن توصیه نمیشوند. از این جهت که این نوع اشیاء بسیار شبیه هستند به متغیرهای سراسری و وجود این نوع متغیرها اساسا ضعف طراحی شیءگرا به حساب میآیند. اما با توجه به ماهیت stateless بودن برنامههای وب، به این معنا که با پایان رندر یک صفحه، تمام اشیاء مرتبط با آنها نیز در سمت سرور تخریب میشوند، نیاز است برای یک سری از دادههای عمومی کاربر، راه حلی را پیدا کرد تا بتوان از اطلاعات آنها استفادهی مجدد کرد. برای مثال نگهداری رشتهی اتصالی بانک اطلاعاتی که کاربر در حین لاگین به سیستم آنرا انتخاب کردهاست (اگر برنامه به ازای هر سال از یک بانک اطلاعاتی مجزا استفاده میکند) و یا زمانیکه کاربری captcha را پر میکند و مقدار آنرا به سمت سرور ارسال میکند، نیاز است مقدار ارسالی او را با مقدار ابتدایی captcha مقایسه کرد. یک چنین اطلاعاتی نباید با پایان رندر صفحه تخریب شوند و نیاز است تا زمانیکه جلسهی کاری کاربر به پایان نرسیدهاست، در دسترس باشند. به همین جهت است که مفهومی را به نام «اشیاء سشن» طراحی کردهاند.
درکل خارج از این موارد بهتر است از سشن استفاده نکنید و در جای جای برنامهی خود ردپای آنرا باقی نگذارید و به خاطر داشته باشید:
متغیر سشن = متغیر سراسری = ضعف طراحی شیءگرا
توصیهی به استفادهی از روشهای سبک وزنتر
سشنها تنها روش به اشتراک گذاری اطلاعات نیستند. اگر میخواهید اطلاعاتی را در بین میان افزارهای برنامه در طی یک درخواست به اشتراک بگذارید، شاید سشن هم یک راه حل باشد؛ اما راه حلی سنگین وزن. راه حل بهتر برای این موارد، استفادهی از HttpContext.Items است. HttpContext.Items نیز همانند سشن، یک key/value store است؛ اما طول عمر آن محدود است به طول عمر درخواست جاری و در تمام میان افزارهای برنامه در دسترس است.
برای مثال در یک میان افزار آنرا تنظیم میکنید:
app.Use(async (context, next) => { context.Items["isVerified"] = true; await next.Invoke(); });
app.Run(async (context) => { await context.Response.WriteAsync("Verified request? " + context.Items["isVerified"]); });
فعال سازی سشنها در ASP.NET Core
ASP.NET Core یک choose-what-you-need framework است. به این معنا که تا زمانیکه قابلیتی را به صورت صریح فعال سازی نکرده باشید، در دسترس نخواهد بود. همین مساله در نهایت به کاهش مصرف منابع این نوع برنامهها و همچنین طراحی ماژولار سیستم ختم میشوند. برای مثال در نگارشهای قبلی ASP.NET (تمام نگارشها)، سشنها به صورت پیش فرض فعال هستند، مگر آنکه HTTP Module آنرا در فایل web.config حذف کنید؛ اما در اینجا برعکس است.
اگر تنها در موارد خاصی که ذکر شد، نیاز به استفادهی از متغیرهای سشن را داشتید، روش فعال سازی آن به صورت ذیل است:
الف) نصب بستهی نیوگت Microsoft.AspNetCore.Session
برای این منظور وابستگی ذیل را به فایل project.json اضافه کنید:
{ "dependencies": { //same as before "Microsoft.AspNetCore.Session": "1.0.0" } }
برای این کار به کلاس آغازین برنامه مراجعه کرده و ابتدا سرویس سشنها را فعال کنید:
public void ConfigureServices(IServiceCollection services) { services.AddSession();
public void Configure(IApplicationBuilder app) { app.UseSession();
app.UseSession(options: new SessionOptions { IdleTimeout = TimeSpan.FromMinutes(30), CookieName = ".MyApplication" });
روش استفادهی از سشنها
در مثال ذیل نحوهی ذخیره سازی اطلاعات را در شیء سشن جلسهی جاری یک کاربر، ملاحظه میکنید:
public ActionResult TestSession() { this.HttpContext.Session.Set("key-1", BitConverter.GetBytes(DateTime.Now.Ticks)); this.HttpContext.Session.SetInt32("key-2", 1); this.HttpContext.Session.SetString("key-3", "DNT"); return Content("OK!"); }
public IActionResult Index() { byte[] key1 = this.HttpContext.Session.Get("key-1"); long key1Value = BitConverter.ToInt64(key1, 0); int? key2Value = this.HttpContext.Session.GetInt32("key-2"); string key3Value = this.HttpContext.Session.GetString("key-3"); return Content("OK!"); }
حالت Set آن آرایهای از بایتها را دریافت میکند و میتوان برای حالت serialization اشیاء، مفید باشد.
دقیقا معادل همین سه متد، متدهای Get، GetInt32 و GetString برای بازیابی مقادیر سشن طراحی شدهاند و باید دقت داشت که خروجیهای اینها میتوانند نال نیز باشند. به همین جهت خروجی GetInt32 آن نال پذیر است.
توسعهی متدهای پیش فرض کار با سشنها
سه متد یاد شدهی کار با سشنها در ASP.NET Core هرچند ضروری هستند، اما کافی نیستند. برای توسعهی آنها میتوان متدهای الحاقی را تدارک دید که نمونهای از آنها را ذیل مشاهده میکنید:
using System; using Microsoft.AspNetCore.Http; using Newtonsoft.Json; namespace Core1RtmEmptyTest.StartupCustomizations { public static class SessionExts { public static void SetDateTime(this ISession collection, string key, DateTime value) { collection.Set(key, BitConverter.GetBytes(value.Ticks)); } public static DateTime? GetDateTime(this ISession collection, string key) { var data = collection.Get(key); if (data == null) { return null; } var dateInt = BitConverter.ToInt64(data, 0); return new DateTime(dateInt); } public static void SetObject(this ISession session, string key, object value) { var stringValue = JsonConvert.SerializeObject(value); session.SetString(key, stringValue); } public static T GetObject<T>(this ISession session, string key) { var stringValue = session.GetString(key); return JsonConvert.DeserializeObject<T>(stringValue); } } }
و یا جهت کار با اشیاء پیچیدهتر میتوان از کتابخانهی JSON.NET استفاده کرد. به عبارتی در این نگارش از ASP.NET، کار سریالایز و دیسریالایز اشیاء، به برنامه نویس واگذار شدهاست و اینکه در پشت صحنه از چه کتابخانهای میخواهید استفاده کنید، در اختیار خودتان است.
البته باید دقت داشت که در اینجا وابستگی JSON.NET به صورت خودکار در دسترس است. از این جهت که بسیاری از وابستگیهای ASP.NET Core مانند مورد ذیل، به JSON.NET وابستهاند و نصب آنها به معنای نصب خودکار JSON.NET نیز هست:
{ "dependencies": { //same as before "Microsoft.Extensions.Configuration.Json": "1.0.0" } }
یک مطلب تکمیلی
در اینجا نیز امکان ذخیره سازی سشنها در بانک اطلاعاتی بجای حافظهی فرار سرور درنظر گرفته شدهاست و برای این حالت، بانکهای اطلاعاتی NoSQL ویژهای به نام key/value stores مانند بانک اطلاعاتی فوق سریع Redis پیشنهاد میشود؛ هرچند امکان کار با SQL Server نیز در اینجا وجود دارد، اما برای کش سرورهای مبتنی بر key/value ها، بانک اطلاعاتی Redis، انتخاب اول است.
Managing Application State
به روز رسانی
- NET Core 1.0.1. منتشر شد. با این تغییرات
برای مطالعهی بیشتر
- Announcing September 2016 Updates for .NET Core 1.0
- Announcing the ASP.NET Core September 2016 Patch Release
توضیحات بیشتری در مورد روش ارتقاء
- NET Core 1.0.1. منتشر شد. با این تغییرات
برای مطالعهی بیشتر
- Announcing September 2016 Updates for .NET Core 1.0
- Announcing the ASP.NET Core September 2016 Patch Release
توضیحات بیشتری در مورد روش ارتقاء
مسیرراهها
jqGrid
- صفحه بندی و مرتب سازی خودکار اطلاعات به کمک jqGrid در ASP.NET MVC
- فرمت کردن اطلاعات نمایش داده شده به کمک jqGrid در ASP.NET MVC
- فعال سازی و پردازش جستجوی پویای jqGrid در ASP.NET MVC
- فعال سازی و پردازش صفحات پویای افزودن، ویرایش و حذف رکوردهای jqGrid در ASP.NET MVC
- استفاده ازExpressionها جهت ایجاد Strongly typed view در ASP.NET MVC
- سفارشی سازی عناصر صفحات پویای افزودن و ویرایش رکوردهای jqGrid در ASP.NET MVC
- تهیه خروجی PDF و اکسل از حاصل جستجوی پویای jqGrid به کمک PDF Report
- آپلود فایل توسط فرمهای پویای jqGrid
- اعتبارسنجی سفارشی سمت کاربر و سمت سرور در jqGrid
- فعال سازی و پردازش Inline Add در jqGrid
- گروه بندی اطلاعات در jqGrid
- نمایش Subgrid در jqGrid
- ایجاد زیر گریدهای چند سطحی در jqGrid
- نمایش ساختارهای درختی توسط jqGrid
پیشنیازها
- «با HttpHandler بیشتر آشنا شوید»
یکی از بزرگترین تغییرات ASP.NET Core نسبت به نگارشهای قبلی آن، مدیریت HTTP pipeline آن است. به عنوان یک توسعه دهندهی ASP.NET به طور قطع با مفاهیمی مانند HttpHandler و HttpModules آشنایی دارید و ... هر دوی اینها با نگارش جدید ASP.NET حذف و با مفهوم جدیدی به نام Middleware جایگزین شدهاند.
- HttpHandlerها عموما مبتنی بر پسوندهای فایلها عمل میکنند. برای نمونه، رایجترین آنها ASP.NET page handler است که هرگاه درخواستی، ختم شدهی به پسوند aspx، به موتور ASP.NET Web forms وارد شد، به این page handler، جهت پردازش نهایی هدایت میشود. محل تنظیم آنها نیز در فایل web.config است.
- HttpModuleها مبتنی بر رخدادها عمل میکنند. HttpModuleها به عنوان جزئی از request pipeline عمل کرده و دسترسی کاملی دارند به رخدادهای طول عمر درخواست رسیده. آنها را میتوان توسط فایلهای global.asax و یا web.config تنظیم کرد.
- MiddleWareها را که جزئی از طراحی OWIN نیز هستند، میتوان به عنوان کامپوننتهای کوچکی از برنامه که قابلیت یکپارچه شدن با HTTP request pipeline را دارند، درنظر گرفت. عملکرد آنها ترکیبی است از هر دوی HttpHandler و HttpModuleها که در نگارشهای قبلی ASP.NET مورد استفاده بودند. از MiddleWareها میتوان برای پیاده سازی اعمال مختلفی جهت پردازش درخواستهای رسیده مانند اعتبارسنجی، کار با سشنها، ثبت وقایع سیستم، مسیریابی و غیره استفاده کرد. OWIN یا Open Web Interface for .NET به توسعه دهندهها امکان غیروابسته کردن برنامهی ASP.NET خود را از وب سرور مورد استفاده میدهد. به علاوه OWIN امکان پلاگین نویسی اجزای مختلف برنامه را بدون وابسته کردن آنها به یکدیگر فراهم میکند. برای مثال میتوان یک پلاگین logger را تهیه کرد تا اطلاعات مختلفی را از درخواستهای رسیده ثبت کند.
مواردی که با ارائهی ASP.NET Core 1.0 حذف شدهاند
- System.Web: یکی از اهداف اصلی OWIN، مستقل کردن برنامهی وب، از هاست آن است تا بتوان از وب سرورهای بیشتری استفاده کرد. System.Web انحصارا برای IIS طراحی شده بود و در این نگارش دیگر وجود خارجی ندارد.
- HttpModules: با Middlewareها جایگزین شدهاند.
- HttpHandlers: البته HttpHandlers از زمان ارائهی اولین نگارش ASP.NET MVC، در چندین سال قبل منسوخ شدند. زیرا پردازش صفحات وب در ASP.NET MVC برخلاف وب فرمها، از فایلهایی با پسوندهای خاص شروع نمیشوند و نقطهی آغازین آنها، اکشن متدهای کنترلرها است.
- فایل global.asax: با حذف شدن HttpModules، دیگر ضرورتی به وجود این فایل نیست.
شباهتهای بینMiddleware و HttpModuleها
همانند HttpModuleها، Middlewareها نیز به ازای هر درخواست رسیده اجرا میشوند و از هر دو میتوان جهت تولید response ایی خاص استفاده کرد.
تفاوتهای بینMiddleware و HttpModuleها
- عموما HttpModule از طریق web.config و یا فایل global.asax تنظیم میشوند. اما Middlewareها تنها از طریق کد و در فایل Startup.cs برنامههای ASP.NET Core 1.0 قابل معرفی هستند.
- به عنوان یک توسعه دهنده، کنترلی را بر روی ترتیب اجرای انواع و اقسام HttpModuleها نداریم. این مشکل در Middlewareها برطرف شده و اکنون ترتیب اجرای آنها، دقیقا مطابق ترتیب افزوده شدن و تعریف آنها در فایل Startup.cs است.
- ترتیب اجرای HttpModuleها هرچه که باشد، برای حالتهای request و response یکی است. اما ترتیب اجرای Middlewareهای مخصوص response، عکس ترتیب اجرای Middlewareهای مخصوص request هستند (تصویر ذیل).
- HttpModuleها را صرفا جهت اتصال کدهایی به رخدادهای طول عمر برنامه میتوان طراحی کرد؛ اما Middleware مستقل هستند از این رخدادها.
- HttpModuleها به System.Web وابستهاند؛ برخلاف Middlewareها که وابستگی به هاست خود ندارند.
Middlewareهای توکار ASP.NET Core 1.0
ASP.NET Core 1.0 به همراه تعدادی Middleware توکار است؛ مانند:
- Authentication: جهت پشتیبانی از اعتبارسنجی
- CORS: برای فعال سازی Cross-Origin Resource Sharing
- Routing: جهت تعریف و محدود سازی مسیریابیهای برنامه
- Session: برای پشتیبانی و مدیریت سشنهای کاربران
- Diagnostics: پشتیبانی از صفحات خطا و اطلاعات زمان اجرای برنامه
و مواردی دیگر که برای توزیع فایلهای استاتیک و یا مرور محتویات پوشهها و امثال آنها طراحی شدهاند که در طی این مطلب و همچنین مطالب آتی، آنها را بررسی خواهیم کرد.
یک مثال: اگر یک پروژهی خالی ASP.NET Core 1.0 را در ویژوال استودیو ایجاد کنید، این پروژه قادر نیست حتی فایلهای استاتیک مانند تصاویر، فایلهای پیش فرض مانند index.html و یا قابلیت مرور سادهی فایلهای موجود در یک پوشه را ارائه دهد (حتی اگر به آنها نیازی نداشته باشید).
طراحی این نگارش از ASP.NET، مبتنی است بر سبک وزن بودن و ماژولار بودن. هر قابلیتی را که نیاز دارید، باید middleware آنرا نیز خودتان به صورت صریح اضافه کنید و یا در غیر اینصورت فعال نیست. برخلاف نگارشهای قبلی ASP.NET که HTTP Moduleهای از سشن گرفته تا اعتبارسنجی و غیره، همگی به صورت پیش فرض در فایل Web.Config فعال بودند؛ مگر اینکه آنها را به صورت دستی حذف میکردید.
ثبت و فعال سازی اولین Middleware
در ادامهی تکمیل و معرفی برنامهی خالی ASP.NET Core 1.0، قصد داریم یک Middleware توکار را به نام Welcome Page، بجای نمایش سطر Hello world پیش فرض این برنامه، ثبت و فعال سازی کنیم. این Middleware ویژه، در اسمبلی به نام Microsoft.AspNetCore.Diagnostics قرار دارد. اگر فایل project.json پیش فرض این پروژه را باز کنید، این اسمبلی به صورت پیش فرض در آن ثبت و معرفی شدهاست:
بنابراین هم اکنون بستهی نیوگت آن نیز به پروژهی جاری اضافه شده و قابل استفاده است. در غیراینصورت همانطور که در قسمت قبل در مطلب «نقش فایل project.json» عنوان شد، میتوان بر روی گره references کلیک راست کرده و سپس از منوی ظاهر شده،گزینهی manage nuget packages را انتخاب کرد. سپس، ابتدا برگهی browse را انتخاب کنید و در اینجا نام Microsoft.AspNetCore.Diagnostics را جستجو کرده و در آخر آنرا نصب کنید.
پس از اطمینان حاصل کردن از نصب بستهی نیوگت Microsoft.AspNetCore.Diagnostics، اکنون جهت معرفی Middleware توکار Welcome Page ، فایل Startup.cs را گشوده و کدهای آنرا به نحو ذیل تغییر دهید:
در اینجا نحوهی ثبت این middleware را با افزودن آن به IApplicationBuilder تزریق شدهی توسط OWIN، به کمک متد الحاقی UseWelcomePage مشاهده میکنید.
به علاوه middleware دومی را نیز با متد الحاقی Run مشاهده میکنید. به این نوع middlewareهای خاص، اصطلاحا terminal middleware میگویند. از این جهت که درخواستی را دریافت و یک response را تولید میکنند و کار همینجا خاتمه مییابد و زنجیرهی پردازشی middlewareها ادامه نخواهد یافت. در اینجا پارامتر context آن از نوع HttpContext است و باید دقت داشت، زمانیکه کار نوشتن در Response، در اینجا انجام شد، اگر پس از متد Run یک Middleware دیگر را ثبت کنید، هیچگاه اجرا نخواهد شد.
در این حالت اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
welcome page نیز یک terminal middleware است. به همین جهت middleware بعدی ثبت شدهی در اینجا یا همان متد Run، دیگر اجرا نخواهد شد.
در قسمتهای بعدی، تعداد بیشتری از Middlewareهای توکار ASP.NET Core 1.0 را بررسی خواهیم کرد.
- «با HttpHandler بیشتر آشنا شوید»
یکی از بزرگترین تغییرات ASP.NET Core نسبت به نگارشهای قبلی آن، مدیریت HTTP pipeline آن است. به عنوان یک توسعه دهندهی ASP.NET به طور قطع با مفاهیمی مانند HttpHandler و HttpModules آشنایی دارید و ... هر دوی اینها با نگارش جدید ASP.NET حذف و با مفهوم جدیدی به نام Middleware جایگزین شدهاند.
- HttpHandlerها عموما مبتنی بر پسوندهای فایلها عمل میکنند. برای نمونه، رایجترین آنها ASP.NET page handler است که هرگاه درخواستی، ختم شدهی به پسوند aspx، به موتور ASP.NET Web forms وارد شد، به این page handler، جهت پردازش نهایی هدایت میشود. محل تنظیم آنها نیز در فایل web.config است.
- HttpModuleها مبتنی بر رخدادها عمل میکنند. HttpModuleها به عنوان جزئی از request pipeline عمل کرده و دسترسی کاملی دارند به رخدادهای طول عمر درخواست رسیده. آنها را میتوان توسط فایلهای global.asax و یا web.config تنظیم کرد.
- MiddleWareها را که جزئی از طراحی OWIN نیز هستند، میتوان به عنوان کامپوننتهای کوچکی از برنامه که قابلیت یکپارچه شدن با HTTP request pipeline را دارند، درنظر گرفت. عملکرد آنها ترکیبی است از هر دوی HttpHandler و HttpModuleها که در نگارشهای قبلی ASP.NET مورد استفاده بودند. از MiddleWareها میتوان برای پیاده سازی اعمال مختلفی جهت پردازش درخواستهای رسیده مانند اعتبارسنجی، کار با سشنها، ثبت وقایع سیستم، مسیریابی و غیره استفاده کرد. OWIN یا Open Web Interface for .NET به توسعه دهندهها امکان غیروابسته کردن برنامهی ASP.NET خود را از وب سرور مورد استفاده میدهد. به علاوه OWIN امکان پلاگین نویسی اجزای مختلف برنامه را بدون وابسته کردن آنها به یکدیگر فراهم میکند. برای مثال میتوان یک پلاگین logger را تهیه کرد تا اطلاعات مختلفی را از درخواستهای رسیده ثبت کند.
مواردی که با ارائهی ASP.NET Core 1.0 حذف شدهاند
- System.Web: یکی از اهداف اصلی OWIN، مستقل کردن برنامهی وب، از هاست آن است تا بتوان از وب سرورهای بیشتری استفاده کرد. System.Web انحصارا برای IIS طراحی شده بود و در این نگارش دیگر وجود خارجی ندارد.
- HttpModules: با Middlewareها جایگزین شدهاند.
- HttpHandlers: البته HttpHandlers از زمان ارائهی اولین نگارش ASP.NET MVC، در چندین سال قبل منسوخ شدند. زیرا پردازش صفحات وب در ASP.NET MVC برخلاف وب فرمها، از فایلهایی با پسوندهای خاص شروع نمیشوند و نقطهی آغازین آنها، اکشن متدهای کنترلرها است.
- فایل global.asax: با حذف شدن HttpModules، دیگر ضرورتی به وجود این فایل نیست.
شباهتهای بینMiddleware و HttpModuleها
همانند HttpModuleها، Middlewareها نیز به ازای هر درخواست رسیده اجرا میشوند و از هر دو میتوان جهت تولید response ایی خاص استفاده کرد.
تفاوتهای بینMiddleware و HttpModuleها
- عموما HttpModule از طریق web.config و یا فایل global.asax تنظیم میشوند. اما Middlewareها تنها از طریق کد و در فایل Startup.cs برنامههای ASP.NET Core 1.0 قابل معرفی هستند.
- به عنوان یک توسعه دهنده، کنترلی را بر روی ترتیب اجرای انواع و اقسام HttpModuleها نداریم. این مشکل در Middlewareها برطرف شده و اکنون ترتیب اجرای آنها، دقیقا مطابق ترتیب افزوده شدن و تعریف آنها در فایل Startup.cs است.
- ترتیب اجرای HttpModuleها هرچه که باشد، برای حالتهای request و response یکی است. اما ترتیب اجرای Middlewareهای مخصوص response، عکس ترتیب اجرای Middlewareهای مخصوص request هستند (تصویر ذیل).
- HttpModuleها را صرفا جهت اتصال کدهایی به رخدادهای طول عمر برنامه میتوان طراحی کرد؛ اما Middleware مستقل هستند از این رخدادها.
- HttpModuleها به System.Web وابستهاند؛ برخلاف Middlewareها که وابستگی به هاست خود ندارند.
Middlewareهای توکار ASP.NET Core 1.0
ASP.NET Core 1.0 به همراه تعدادی Middleware توکار است؛ مانند:
- Authentication: جهت پشتیبانی از اعتبارسنجی
- CORS: برای فعال سازی Cross-Origin Resource Sharing
- Routing: جهت تعریف و محدود سازی مسیریابیهای برنامه
- Session: برای پشتیبانی و مدیریت سشنهای کاربران
- Diagnostics: پشتیبانی از صفحات خطا و اطلاعات زمان اجرای برنامه
و مواردی دیگر که برای توزیع فایلهای استاتیک و یا مرور محتویات پوشهها و امثال آنها طراحی شدهاند که در طی این مطلب و همچنین مطالب آتی، آنها را بررسی خواهیم کرد.
یک مثال: اگر یک پروژهی خالی ASP.NET Core 1.0 را در ویژوال استودیو ایجاد کنید، این پروژه قادر نیست حتی فایلهای استاتیک مانند تصاویر، فایلهای پیش فرض مانند index.html و یا قابلیت مرور سادهی فایلهای موجود در یک پوشه را ارائه دهد (حتی اگر به آنها نیازی نداشته باشید).
طراحی این نگارش از ASP.NET، مبتنی است بر سبک وزن بودن و ماژولار بودن. هر قابلیتی را که نیاز دارید، باید middleware آنرا نیز خودتان به صورت صریح اضافه کنید و یا در غیر اینصورت فعال نیست. برخلاف نگارشهای قبلی ASP.NET که HTTP Moduleهای از سشن گرفته تا اعتبارسنجی و غیره، همگی به صورت پیش فرض در فایل Web.Config فعال بودند؛ مگر اینکه آنها را به صورت دستی حذف میکردید.
ثبت و فعال سازی اولین Middleware
در ادامهی تکمیل و معرفی برنامهی خالی ASP.NET Core 1.0، قصد داریم یک Middleware توکار را به نام Welcome Page، بجای نمایش سطر Hello world پیش فرض این برنامه، ثبت و فعال سازی کنیم. این Middleware ویژه، در اسمبلی به نام Microsoft.AspNetCore.Diagnostics قرار دارد. اگر فایل project.json پیش فرض این پروژه را باز کنید، این اسمبلی به صورت پیش فرض در آن ثبت و معرفی شدهاست:
{ "dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }, "Microsoft.AspNetCore.Diagnostics": "1.0.0", "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0", "Microsoft.AspNetCore.Server.Kestrel": "1.0.0", "Microsoft.Extensions.Logging.Console": "1.0.0" },
پس از اطمینان حاصل کردن از نصب بستهی نیوگت Microsoft.AspNetCore.Diagnostics، اکنون جهت معرفی Middleware توکار Welcome Page ، فایل Startup.cs را گشوده و کدهای آنرا به نحو ذیل تغییر دهید:
using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Http; using Microsoft.Extensions.DependencyInjection; namespace Core1RtmEmptyTest { public class Startup { public void ConfigureServices(IServiceCollection services) { } public void Configure(IApplicationBuilder app) { app.UseWelcomePage(); app.Run(async (context) => { await context.Response.WriteAsync("Hello DNT!"); }); } } }
به علاوه middleware دومی را نیز با متد الحاقی Run مشاهده میکنید. به این نوع middlewareهای خاص، اصطلاحا terminal middleware میگویند. از این جهت که درخواستی را دریافت و یک response را تولید میکنند و کار همینجا خاتمه مییابد و زنجیرهی پردازشی middlewareها ادامه نخواهد یافت. در اینجا پارامتر context آن از نوع HttpContext است و باید دقت داشت، زمانیکه کار نوشتن در Response، در اینجا انجام شد، اگر پس از متد Run یک Middleware دیگر را ثبت کنید، هیچگاه اجرا نخواهد شد.
در این حالت اگر برنامه را اجرا کنید، خروجی ذیل را مشاهده خواهید کرد:
welcome page نیز یک terminal middleware است. به همین جهت middleware بعدی ثبت شدهی در اینجا یا همان متد Run، دیگر اجرا نخواهد شد.
در قسمتهای بعدی، تعداد بیشتری از Middlewareهای توکار ASP.NET Core 1.0 را بررسی خواهیم کرد.
- Global query filters in Entity Framework Core 2.0
- Implementing tenant providers on ASP.NET Core
- Implementing database per tenant strategy on ASP.NET Core
- Handling missing tenants in ASP.NET Core
- Unit testing multi-tenant database provider
- Defensive database context for multi-tenant ASP.NET Core applications
هستند یکسری پروژهی افزونه پذیر برای ASP.NET Core که این مفاهیم را پیاده سازی کردهاند (و وابستگی به StructureMap هم ندارند):
ExtCore - Free, open source and cross-platform framework for creating modular and extendable web applications based on ASP.NET Core
SimplCommerce - A super simple, cross platform, modularized ecommerce system built on .NET Core
Modular Web Application with ASP.NET Core
Orchard vNext - Orchard 2 is a re-implementation of Orchard CMS in ASP.NET Core
SimplCommerce - A super simple, cross platform, modularized ecommerce system built on .NET Core
Modular Web Application with ASP.NET Core
Orchard vNext - Orchard 2 is a re-implementation of Orchard CMS in ASP.NET Core
اشتراکها