Zepto.js یک کتابخانهی سمت مرورگر است که میتواند در برخی کاربردها جایگزین مناسبی برای jQuery باشد. مهمترین ویژگی Zepto، سازگاری ساختار این کتابخانه با جیکوئری است. به این معنی که چنانچه شیوهی کدنویسی با jQuery را بدانید، شیوهی کدنویسی Zepto را نیز فرا گرفتهاید.
برای رفع این مشکلات، از روشهای توسعهی به همراه ابزارهای یکپارچگی مداوم استفاده میشود. برای نمونه، AppVeyor یکی از سرویسهای ابری یکپارچگی مداوم (Continuous Integration و یا به اختصار CI) است. به کمک آن میتوان یک image از ویندوز سرور را به همراه ابزارهای build، آزمایش و توزیع برنامههای NET. در اختیار داشت. این سرویس، مخزن کد شما را مونیتور کرده و هر زمانیکه تغییری را در آن ایجاد کردید، آنها را به صورت خودکار build و در صورت موفقیت آمیز بودن این عملیات، بستهی نیوگت متناظری را به سایت nuget.org ارسال میکند. بنابراین پس از یکپارچه کردن مخزن کد خود با این نوع سرویسهای یکپارچگی مداوم، دیگر حتی نیازی به build دستی آن نیز نخواهید داشت. همینقدر که کدی را به مخزن کد تحت نظر، commit کنید، مابقی مراحل آن خودکار است.
به همین جهت در این مطلب قصد داریم نحوهی اتصال یک مخزن کد GitHub را به سرویس یکپارچگی مداوم AppVeyor، جهت تولید خودکار بستههای Nuget، بررسی کنیم.
معرفی سرویس ابری AppVeyor
AppVeyor یک راه حل یکپارچگی مداوم چند سکویی است که استفادهی از آن برای پروژههای سورس باز رایگان است و سازگاری فوق العادهای را با محصولات مایکروسافت دارد. برای ورود به آن میتوان از اکانتهای GitHub ،BitBucket و VSTS (Visual Studio Team Services) استفاده کرد.
گردش کاری متداول یکپارچگی مداوم AppVeyor به این صورت است:
الف) با اکانت GitHub خود به آن وارد شوید.
ب) یک مخزن کد GitHub خود را به آن Import کنید.
ج) به مخزن کد GitHub خود یک فایل yml. تنظیمات مخصوص AppVeyor را اضافه کنید.
د) نظارهگر Build و توزیع خودکار پروژهی خود باشید.
ایجاد اکانت و اتصال به مخزن کد GitHub
در ابتدا به صفحهی لاگین آن مراجعه کنید. در اینجا جهت سهولت کار با GitHub و مخازن کد آن، گزینهی GitHub را انتخاب کرده و توسط آن به سیستم وارد شوید:
پس از ورود موفق، گزینهی new project را انتخاب کنید:
در ادامه مخزن کد GitHub و نوع عمومی آنرا انتخاب میکنیم تا AppVeyor بتواند پروژههای آنرا Import کند و همچنین به آنها web hookهایی را اضافه کند تا با اعمال تغییراتی در سمت GitHub، کار اطلاع رسانی آنها به AppVeyor به صورت خودکار صورت گیرد:
پس از آن لیست مخزنهای کد شما در همینجا ارائه میشود تا بتوانید یک یا چند مورد را انتخاب کنید:
انجام تنظیمات عمومی مخزن کد
در صفحهی بعدی، برگهی settings و سپس از منوی کنار صفحهی آن، گزینهی General را انتخاب کنید:
در اینجا اگر پروژهی شما از نوع NET Core. است، گزینهی NET Core .csproj patching. را انتخاب نمائید:
سپس در پایین صفحه بر روی دکمهی Save کلیک کنید.
انتخاب و تنظیم محیط Build
در ادامه در برگهی settings و سپس از منوی کنار صفحهی آن، گزینهی Environment را انتخاب کنید:
در این صفحه، worker image را بر روی VS 2017 قرار دهید و همچنین در قسمت Cached directories and files، مسیر C:\Users\appveyor\.dnx را جهت کش کردن عملیات Build و بالا بردن سرعت آن، مقدار دهی کنید. سپس در پایین صفحه بر روی دکمهی Save کلیک نمائید.
اکنون بر روی گزینهی Build در منوی سمت چپ صفحه کلیک کنید. در اینجا سه حالت msbuild ،script و off را میتوان انتخاب کرد.
- در حالت msbuild، که سادهترین حالت ممکن است، فایل sln. مخزن کد، یافت شده و بر اساس آن به صورت خودکار تمام پروژههای این solution یکی پس از دیگری build خواهند شد. این مورد برای برنامههای Full .NET Framework شاید گزینهی مناسبی باشد.
- حالت script برای پروژههای NET Core. مناسبتر است و در این حالت میتوان کنترل بیشتری را بر روی build داشت. به علاوه این روش بر روی لینوکس هم کار میکند؛ زیرا در آنجا دسترسی به msbuild نداریم.
- حالت off به معنای خاموش کردن عملیات build است.
در اینجا گزینهی cmd را جهت ورود build script انتخاب میکنیم:
سپس دستورات ذیل را جهت ورود به پوشهی پروژهی کتابخانه (جائیکه فایل csproj آن قرار دارد)، بازیابی وابستگیهای پروژه و سپس تولید بستهی نیوگتی از آن، وارد میکنیم:
cd ./src/DNTPersianUtils.Core dotnet restore dotnet pack -c release cd ../..
ذکر ../.. cd در انتهای این دستورات ضروری است. در غیر اینصورت cd بعدی در تنظیماتی دیگر، داخل همین پوشه انجام میشود.
تنظیم اجرای خودکار آزمونهای واحد
در همین صفحه، گزینههای settings -> tests -> script -> cmd را انتخاب و سپس دستورات زیر را وارد کرده و آنرا ذخیره کنید:
cd ./src/DNTPersianUtils.Core.Tests dotnet restore dotnet test cd ../..
تنظیم اطلاع رسانی خودکار از اجرای عملیات
در برگهی settings -> notifications مطابق تنظیمات فوق میتوان نوع email را جهت اطلاع رسانی شکست انجام عملیات یکپارچگی مداوم، انتخاب کرد.
آزمایش Build خودکار
برای آزمایش تنظیماتی که انجام دادیم، به برگهی latest build مراجعه کرده و بر روی دکمهی new build کلیک کنید تا اسکریپتهای build و test فوق اجرا شوند. بدیهی است اجرای بعدی این اسکریپتها خودکار بوده و به ازای هر commit به GitHub، بدون نیاز به مراجعهی مستقیم به appveyor صورت میگیرند.
اضافه کردن نماد AppVeyor به پروژه
در تنظیمات برگهی Settings، گزینهی AppVeyor badge نیز در منوی سمت چپ صفحه، وجود دارد:
در اینجا همان کدهای mark down آنرا انتخاب کرده و به ابتدای فایل readme پروژهی خود اضافه کنید. برای نمونه نماد فعلی (تصویر فوق)، build failing را نمایش میدهد؛ چون سه آزمون واحد آن مشکل دارند و باید اصلاح شوند.
پس از رفع مشکلات پروژه و commit آنها، build و اجرای خودکار آزمونهای واحد آن توسط AppVeyor صورت گرفته و اینبار این نماد به صورت زیر تغییر میکند:
ارسال خودکار بستهی نیوگت تولید شده به سایت nuget.org
برای ارسال خودکار حاصل Build، به سایت نیوگت، نیاز است یک API Key داشته باشیم. به همین جهت به صفحهی مخصوص آن در سایت nuget پس از ورود به سایت آن، مراجعه کرده و یک کلید API جدید را صرفا برای این پروژه تولید کنید (در قسمت Available Packages بستهی پیشینی را که دستی آپلود کرده بودید انتخاب کنید).
در اینجا API Key را ذکر خواهیم کرد. سپس در پایین صفحه بر روی دکمهی Save کلیک کنید.
همچنین نیاز است مشخص کنیم که بستههای nupkg تولید شده در چه مسیری قرار دارند. به همین جهت در قسمت settings -> artifacts مسیر پوشهی bin نهایی را ذکر میکنیم:
این مورد را نیز با کلیک بر روی دکمهی Save ذخیره کنید.
اکنون اگر نگارش جدیدی را به GitHub ارسال کنیم (تغییر VersionPrefix در فایل csproj و سپس commit آن)، پس از Build پروژه، بستهی نیوگت آن نیز به صورت خودکار تولید شده و به سایت nuget.org ارسال میشود. لاگ آنرا در پایین صفحهی برگهی latest build میتوانید مشاهده کنید.
ساده سازی مراحل تنظیمات AppVeyor
در صفحهی settings، در منوی سمت چپ آن، گزینهی export YAML نیز وجود دارد. در اینجا میتوان تمام تنظیمات انجام شدهی فوق را با فرمت yml. دریافت کرد و سپس این فایل را به ریشهی مخزن کد خود افزود. با وجود این فایل، دیگر نیازی به طی کردن دستی هیچکدام از مراحل فوق نیست.
برای نمونه فایل appveyor.yml نهایی مطابق با توضیحات این مطلب، چنین محتوایی را دارد:
version: 1.0.{build} image: Visual Studio 2017 dotnet_csproj: patch: true file: '**\*.csproj' version: '{version}' package_version: '{version}' assembly_version: '{version}' file_version: '{version}' informational_version: '{version}' cache: C:\Users\appveyor\.dnx build_script: - cmd: >- cd ./src/DNTPersianUtils.Core dotnet restore dotnet pack -c release cd ../.. test_script: - cmd: >- cd ./src/DNTPersianUtils.Core.Tests dotnet restore dotnet test cd ../.. artifacts: - path: ./src/DNTPersianUtils.Core/bin/release/*.nupkg name: NuGet deploy: - provider: NuGet api_key: secure: xyz skip_symbols: true notifications: - provider: Email to: - me@yahoo.com on_build_success: false on_build_failure: true on_build_status_changed: true
یک نکته: api_key ذکر شدهی در اینجا در قسمت secure، رمزنگاری شدهاست. برای تولید آن میتوانید از مسیر https://ci.appveyor.com/tools/encrypt استفاده کنید. به این صورت مشکلی با عمومی کردن فایل appveyor.yml خود در GitHub نخواهید داشت.
خواندنیهای 16 تیر
اس کیوال سرور
توسعه وب
دات نت فریم ورک
دبلیو پی اف و سیلور لایت
سی و مشتقات
شیرپوینت
کتابهای رایگان
مای اس کیوال
متفرقه
وب سرورها
پی اچ پی
شما برای این کار باید چند مرحله را انجام دهید:
مرحلهی اول: یک پروژهی جدید بسازید
نکته: برای اینکار میتوانید پروژه را از نوع ASP.NET 5 Web Application نیز انتخاب نمایید و مراحل کوتاهتری را طی نمایید. اما راه اندازی دستی قسمتهای مختلف پروژه برای یکبار، به درک بهتر ساختار آن کمک زیادی میکند. از طرفی کار کردن بر روی یک پروژهی تمیز و خالی، برای انتقال دادههای مورد نیاز از یک پروژهی دیگر، از بروز خطاهای پیش بینی نشده و تداخلهای احتمالی نیز جلوگیری میکند.
مرحلهی دوم: اعمال تنظیمات جهت
استفادهی از MVC
همان طور که مشاهده میکنید در این پروژه دیگر خبری از web.config نیست. اما نگران نباشید، امکان اعمال تنظیمات، باز هم وجود دارد و فقط به فایلهای json منتقل شدهاند که project.json هم یکی از آنهاست. برای استفادهی از Microsoft.AspNet.Mvc فقط کافی است فایل project.json را باز کنید و در قسمت "dependencies" پکیج "Microsoft.AspNet.Mvc" را به آن اضافه نمایید تا به صورت خودکار دانلود و به پروژه اضافه گردد.
"dependencies": { "Microsoft.AspNet.Server.IIS": "1.0.0-beta5", "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5", "Microsoft.AspNet.Mvc": "6.0.0-beta5" },
public void ConfigureServices(IServiceCollection services) { services.AddMvc(); } public void Configure(IApplicationBuilder app) { app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Home}/{action=Index}/{id?}"); }); }
<h1>My First MVC6 Website!</h1>
برنامه را اجرا کنید تا خروجی مورد انتظار را مشاهده نمایید.
مرحلهی سوم: انتقال فایلهای پروژهی قبلی به پروژهی جدید
Viewهای مربوط به این controller را نیز به پوشهی Views/Home منتقل نمایید و پروژه را بار دیگر اجرا نمایید. حال باید نمایی از محتوای این فایلها بدون اعمال استایلها را مشاهده نمایید.
همان طور که میدانیم MVC 5 برای استایل صفحات خود از bootstrap استفاده میکند و فایلهای مورد نیاز آن در پوشههای Content و Script -که در root سایت موجود هستند- قرار دارند و نیز ارجاع به این فایلها در Layout.cshtml_ قرار دارد. اما در MVC 6 قضیه کمی متفاوت و البته بهتر شده است. در MVC 6 تمام فایلهای client-side شامل css و js در پوشهی wwwroot قرار دارند و ما میتواینم فایلهای bootstrap و غیره را از پروژهی خود، به این مکان کپی نماییم. ولی روش بهتر، استفاده از ابزارهای bower و gulp برای این کار است. همان طور که میدانید bower یک package manager برای نصب، به روزرسانی و مدیریت کتابخانههای سمت کلاینت و gulp نیز یک task runner برای انجام کارهای مختلف از قبیل script minification و ... در سمت کلاینت است. gulp و bower به طور تو کار در ویژوال 2015 پشتیبانی میشوند و حتی اگر پروژهی خود را از نوع ASP.NET 5 Web Application انتخاب کرده باشید، به صورت پیش فرض از آنها استفاده میکند.
در اینجا برای استفاده، ابتدا یک فایل از نوع Bower JSON Configuration را به root پروژه اضافه کرده و آن را bower.json بنامید و در خاصیت "dependencies" آن bootstrap, jquery, jquery-validation, jquery-validation-unobtrusive را اضافه نمایید.
نکته: من در این قسمت، در restore کردن پکیجها با استفاده از bower، با خطای زیر مواجه شدم:
visual 2015 ECMDERR Failed to execute "git ls-remote --tags --heads git://github.com/jquery/jquery.git", exit code of #-532462766
من از نسخهی Visual Studio 2015 Update 1 CTP استفاده میکنم، ولی ظاهرا این مشکل در نسخههای دیگر هم وجود دارد و فایل bower.cmd ویژوال به درستی کار نمیکند. من برای حل این مشکل، ابتدا git را نصب کردم و در تنظیمات bower، مسیر پیش فرض ویژال رو به مسیر نصب git تغییر دادم. یعنی در پروژه بر روی پوشهی Bower کلیک راست و configure external tools را انتخاب کردم و تیک $(DevEnvDir)\Extensions\Microsoft\Web Tools\External\git را برداشته و در عوض مسیر پیش فرض خودم یعنی C:\Program Files\Git\bin را اضافه کردم.
اگر راه درست و اصولیتری برای حل این مشکل وجود دارد ممنون میشوم دوستان راهنمایی بفرمایند.
خب بعد از اضافه کردن خاصیت dependencies و پکیجهای مورد نیاز، خاصیت exportsOverride را نیز مانند نمونه به فایل bower.json اضافه نمایید.
{ "name": "ASP.NET", "private": true, "dependencies": { "bootstrap": "3.3.6", "jquery": "2.1.4", "jquery-validation": "1.14.0", "jquery-validation-unobtrusive": "3.2.4" }, "exportsOverride": { "bootstrap": { "js": "dist/js/*.*", "css": "dist/css/*.*", "fonts": "dist/fonts/*.*" }, "jquery": { "": "jquery.{js,min.js,min.map}" }, "jquery-validation": { "": "jquery.validate.js" }, "jquery-validation-unobtrusive": { "": "jquery.validate.unobtrusive.{js,min.js}" } } }
"devDependencies": { "gulp": "3.9.0", "rimraf": "2.4.4", "gulp-concat": "2.6.0" }
var gulp = require('gulp'); var rimraf = require('rimraf'); var paths = { bower: "./bower_components/", lib: "./wwwroot/lib/" }; gulp.task('clean', function (callback) { rimraf(paths.lib, callback); }); gulp.task('default', ['clean'], function () { var bower = { "bootstrap": "bootstrap/dist/**/*.{js,map,css,ttf,svg,woff,eot}", "jquery": "jquery/jquery*.{js,map}", "jquery-validation": "jquery-validation/jquery.validate.js", "jquery-validation-unobtrusive": "jquery-validation-unobtrusive/jquery.validate.unobtrusive.js" }; for (var destinationDir in bower) { gulp.src(paths.bower + bower[destinationDir]) .pipe(gulp.dest(paths.lib + destinationDir)); } });
اگر پردازش فوق با موفقیت و بدون خطا انجام شود، میتوانید پکیجهای ایجاد شده را در مسیر wwwroot/lib، مشاهده نمایید.
مرحلهی چهارم: ویرایش برخی از view ها
حال که پکیجهای مورد نیاز پروژه، در پوشهی wwwroot قرار گرفتند، باید view هایی که ارجاعی را به این فایلها دارند، نیز ویرایش نماییم. یکی از این فایلها Layout.cshtml_ است که در مسیر Views/Shared قرار دارد. این فایل را باز کرده و به جای متد ()Styles .Render از عنصر <link> برای لود کردن استایلهای بوت استرپ و غیره استفاده نمایید.
<link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" /> <link rel="stylesheet" href="~/css/site.css" />
<script src="~/lib/jquery/dist/jquery.js"></script> <script src="~/lib/bootstrap/dist/js/bootstrap.js"></script>
مرحلهی پنجم(اختیاری): جایگزین کردن متدهای Html helper با ساختار Tag
Helper
یکی از ویژگیهای جالب و مفید MVC 6 ساختار TagHalper ها هستند که در واقع جایگزینی برای متدهای HtmlHelper و عملکردی مشابه به آنها دارند. البته استفاده از این ویژگی اجباری نیست ولی اگر تعداد ویوهای شما زیاد نیست و خواهان استفادهی از این قابلیت در پروژهی خود هستید، تنها کاری که باید انجام دهید، پیدا کردن HtmlHelperها و جایگزینی آنها به صورت زیر میباشد:
@Html.TextBoxFor(model => model.Name, new { style = "width: 100px" })
<input asp-for="Name" style="width: 100px" />
نتیجه گیری
همان طور ملاحظه نمودید انتقال پروژه از ASP.NET MVC 5 به ASP.NET MVC 6 شامل انجام چند مرحله است و دشواری خاصی ندارد. عمدهی این تغییرات و پیچیدگیها هم مربوط به انتقال فایلهای client-side و نحوهی کار با ابزارهای مدیریت پکیج میشود و البته تنظیماتی که در این بین باید انجام شوند. البته قسمتهای دیگری مانند تنظیمات bundling و connection string نیز با MVC 5 تفاوت هایی دارد و کار با آنها نیز بسیار ساده میباشد.
آشنایی با مدل برنامه نویسی TAP
دات نت فریم ورک، از زمان ارائه نگارش یک آن، از اعمال غیرهمزمان و API خاص آن پشتیبانی میکردهاست. همچنین این مورد یکی از ویژگیهای Win32 نیز میباشد. نوشتن کدهای همزمان متداول بسیار ساده است. در این نوع کدها هر عملیات خاص، پس از پایان عملیات قبلی انجام میشود.
public string TestNoneAsync() { var webClient = new WebClient(); return webClient.DownloadString("http://www.google.com"); }
این مورد همچنین در برنامههای سمت سرور نیز حائز اهمیت است. با قفل شدن تعداد زیادی ترد در حال اجرا، عملا قدرت پاسخدهی سرور نیز کاهش مییابد. بنابراین در این نوع موارد، برنامههای چند ریسمانی هرچند در سمت کلاینت ممکن است مفید واقع شوند و برای مثال ترد UI را آزاد کنند، اما اثر آنچنانی بر روی برنامههای سمت سرور ندارند. زیرا در آنها میتوان هزاران ترد را ایجاد کرد که همگی دارای کدهای اصطلاحا blocking باشند. برای حل این مساله استفاده از API غیرهمزمان توصیه میشود.
برای نمونه کلاس WebClient توکار دات نت، دارای متدی به نام DownloadStringAsync نیز میباشد. این متد به محض فراخوانی، ترد جاری را آزاد میکند. به این معنا که فراخوانی آن سبب توقف ترد جاری برای دریافت نتیجهی دریافت اطلاعات از وب نمیشود. به این نوع API، یک Asynchronous API گفته میشود؛ زیرا با سایر کدهای نوشته شده، هماهنگ و همزمان اجرا نمیشود.
هر چند این کد جدید مشکل عدم پاسخ دهی برنامه را برطرف میکند، اما مشکل دیگری را به همراه دارد؛ چگونه باید حاصل عملیات آنرا پس از پایان کار دریافت کرد؟ چگونه باید خطاها و مشکلات احتمالی را مدیریت کرد؟
برای مدیریت این مساله، رخدادی به نام DownloadStringCompleted تعریف شدهاست. روال رویدادگردان آن پس از پایان کار دریافت اطلاعات از وب، فراخوانی میگردد.
public void TestAsync() { var webClient = new WebClient(); webClient.DownloadStringAsync(new Uri("http://www.google.com")); webClient.DownloadStringCompleted += webClientDownloadStringCompleted; } void webClientDownloadStringCompleted(object sender, DownloadStringCompletedEventArgs e) { // use e.Result }
مشکل! ما سادگی یک عملیات همزمان را از دست دادیم. متد TestNoneAsync از لحاظ پیاده سازی و همچنین خواندن و نگهداری آن در طول زمان، بسیار سادهتر است از نمونهی TestAsync نوشته شده. در کدهای غیرهمزمان فوق، یک متد ساده، به دو متد مجزا خرد شدهاست و نتیجهی نهایی، درون یک روال رخدادگردان بدست میآید.
به این مدل، EAP یا Event based asynchronous pattern نیز گفته میشود. EAP در دات نت 2 معرفی شد. روالهای رخدادگردان در این حالت، در ترد اصلی برنامه اجرا میشوند. اما اگر به حالت اصلی اعمال غیرهمزمان موجود از دات نت یک کوچ کنیم، اینطور نیست. در WinForms و WPF برای به روز رسانی رابط کاربری نیاز است اطلاعات دریافت شده در همان تردی که رابط کاربری ایجاد شده است، تحویل گرفته شده و استفاده شوند. در غیراینصورت استثنایی صادر شده و برنامه خاتمه مییابد.
آشنایی با Synchronization Context
ابتدا یک برنامهی WinForms ساده را آغاز کرده و یک دکمهی جدید را به نام btnGetInfo و یک تکست باکس را به نام txtResults، به آن اضافه کنید. سپس کدهای فرم اصلی آنرا به نحو ذیل تغییر دهید:
using System; using System.Linq; using System.Net; using System.Windows.Forms; namespace Async02 { public partial class Form1 : Form { public Form1() { InitializeComponent(); } private void btnGetInfo_Click(object sender, EventArgs e) { var req = (HttpWebRequest)WebRequest.Create("http://www.google.com"); req.Method = "HEAD"; req.BeginGetResponse( asyncResult => { var resp = (HttpWebResponse)req.EndGetResponse(asyncResult); var headersText = formatHeaders(resp.Headers); txtResults.Text = headersText; }, null); } private string formatHeaders(WebHeaderCollection headers) { var headerString = headers.Keys.Cast<string>() .Select(header => string.Format("{0}:{1}", header, headers[header])); return string.Join(Environment.NewLine, headerString.ToArray()); } } }
همچنین در این مثال از متد غیرهمزمان BeginGetResponse نیز استفاده شدهاست. در این نوع API خاص، کار با BeginGetResponse آغاز شده و سپس در callback نهایی توسط EndGetResponse، نتیجهی عملیات به دست میآید.
اگر برنامه را اجرا کنید، با استثنای زیر مواجه خواهید شد:
An exception of type 'System.InvalidOperationException' occurred in System.Windows.Forms.dll but was not handled in user code Additional information: Cross-thread operation not valid: Control 'txtResults' accessed from a thread other than the thread it was created on.
private void btnGetInfo_Click(object sender, EventArgs e) { var sync = SynchronizationContext.Current; var req = (HttpWebRequest)WebRequest.Create("http://www.google.com"); req.Method = "HEAD"; req.BeginGetResponse( asyncResult => { var resp = (HttpWebResponse)req.EndGetResponse(asyncResult); var headersText = formatHeaders(resp.Headers); sync.Post(delegate { txtResults.Text = headersText; }, null); }, null); }
برای درک بهتر آن، سه break point را پیش از متد BeginGetResponse، داخل Async calback و داخل delegate متد Post قرار دهید. پس از اجرای برنامه، از منوی دیباگ در VS.NET گزینهی Windows و سپس Threads را انتخاب کنید.
در اینجا همانطور که مشخص است، کد داخل delegate تعریف شده، در ترد اصلی برنامه اجرا میشود و نه یکی از Worker threadهای ثانویه.
هر چند استفاده از متدهای تو در تو و lambda syntax، نیاز به تعریف چندین متد جداگانه را برطرف کردهاست، اما باز هم کد سادهای به نظر نمیرسد. در سی شارپ 5، برای مدیریت بهتر تمام مشکلات یاد شده، پشتیبانی توکاری از اعمال غیرهمزمان، به هستهی زبان اضافه شدهاست.
Syntax ابتدایی یک متد Async
در ابتدا کلاس و متد Async زیر را در نظر بگیرید:
using System; using System.Threading.Tasks; namespace Async01 { public class AsyncExample { public async Task DoWorkAsync(int parameter) { await Task.Delay(parameter); Console.WriteLine(parameter); } } }
- در مدل برنامه نویسی TAP، متدهای غیرهمزمان باید یک Task را بازگشت دهند؛ یا نمونهی جنریک آنرا. البته کامپایلر، async void را نیز پشتیبانی میکند ولی در قسمتهای بعدی بررسی خواهیم کرد که چرا استفاده از آن مشکلزا است و باید از آن پرهیز شود.
- همچنین مطابق TAP، اینگونه متدها باید به پسوند Async ختم شوند تا استفاده کننده در حین کار با Intellisense، بتواند آنها را از متدهای معمولی سریعتر تشخیص دهد.
- از واژهی کلیدی async نیز استفاده میگردد تا کامپایلر از وجود اعمال غیر همزمان مطلع گردد.
- await به کامپایلر میگوید، عبارت پس از من، یک وظیفهی غیرهمزمان است و ادامهی کدهای نوشته شده، تنها زمانی باید اجرا شوند که عملیات غیرهمزمان معرفی شده، تکمیل گردد.
در متد DoWorkAsync، ابتدا به اندازهای مشخص توقف حاصل شده و سپس سطر بعدی یعنی Console.WriteLine اجرا میشود.
یک اشتباه عمومی! استفاده از واژههای کلیدی async و await متد شما را async نمیکنند.
برخلاف تصور ابتدایی از بکارگیری واژههای کلیدی async و await، این کلمات نحوهی اجرای متد شما را async نمیکنند. این کلمات صرفا برای تشکیل متدهایی که هم اکنون غیرهمزمان هستند، مفید میباشند. برای توضیح بیشتر آن به مثال ذیل دقت کنید:
public async Task<double> GetNumberAsync() { var generator = new Random(); await Task.Delay(generator.Next(1000)); return generator.NextDouble(); }
در ادامه برای استفاده از آن خواهیم داشت:
public async Task<double> GetSumAsync() { var leftOperand = await GetNumberAsync(); var rightOperand = await GetNumberAsync(); return leftOperand + rightOperand; }
در کدهای همزمان متداول، سطر اول ابتدا انجام میشود و بعد سطر دوم و الی آخر. با استفاده از واژهی کلیدی await یک چنین عملکردی را با اعمال غیرهمزمان خواهیم داشت. پیش از این برای مدیریت اینگونه اعمال از یک سری callback و یا رخداد استفاده میشد. برای مثال ابتدا عملیات همزمانی شروع شده و سپس نتیجهی آن در یک روال رخداد گردان جایی در کدهای برنامه دریافت میشد (مانند مثال ابتدای بحث). اکنون تصور کنید که قصد داشتید جمع نهایی حاصل دو عملیات غیرهمزمان را از دو روال رخدادگردان جدا از هم، جمع آوری کرده و بازگشت دهید. هرچند اینکار غیرممکن نیست، اما حاصل کار به طور قطع آنچنان زیبا نبوده و قابلیت نگهداری پایینی دارد. واژهی کلیدی await، انجام اینگونه امور غیرهمزمان را طبیعی و همزمان جلوه میدهد. به این ترتیب بهتر میتوان بر روی منطق و الگوریتمهای مورد استفاده تمرکز داشت، تا اینکه مدام درگیر مکانیک اعمال غیرهمزمان بود.
امکان استفاده از واژهی کلیدی await در هر جایی از کدها وجود دارد. برای نمونه در مثال زیر، برای ترکیب دو عملیات غیرهمزمان، از await در حین تشکیل عملیات ضرب نهایی، دقیقا در جایی که مقدار متد باید بازگشت داده شود، استفاده شدهاست:
public async Task<double> GetProductOfSumAsync() { var leftOperand = GetSumAsync(); var rightOperand = GetSumAsync(); return await leftOperand * await rightOperand; }
Operator '*' cannot be applied to operands of type 'System.Threading.Tasks.Task<double>' and 'System.Threading.Tasks.Task<double>'
اگر متد DownloadString همزمان ابتدای بحث را نیز بخواهیم تبدیل به نمونهی async سیشارپ 5 کنیم، میتوان از متد الحاقی جدید آن به نام DownloadStringTaskAsync کمک گرفت:
public async Task<string> DownloadAsync() { var webClient = new WebClient(); return await webClient.DownloadStringTaskAsync("http://www.google.com"); }
سؤال: آیا استفاده از await نیز ترد جاری را قفل میکند؟
اگر به کدها دقت کنید، استفاده از await به معنای صبر کردن تا پایان عملیات async است. پس اینطور به نظر میرسد که در اینجا نیز ترد اصلی، همانند قبل قفل شدهاست.
public void TestDownloadAsync() { Debug.WriteLine("Before DownloadAsync"); DownloadAsync(); Debug.WriteLine("After DownloadAsync"); }
Before DownloadAsync After DownloadAsync
برنامههای Async و نگارشهای مختلف دات نت
شاید در ابتدا به نظر برسد که قابلیتهای جدید async و await صرفا متعلق هستند به دات نت 4.5 به بعد؛ اما خیر. اگر کامپایلری را داشته باشید که از این واژههای کلیدی را پشتیبانی کند، امکان استفاده از آنها را با دات نت 4 نیز خواهید داشت. برای این منظور تنها کافی است از VS 2012 به بعد استفاده نمائید. سپس در کنسول پاورشل نیوگت دستور ذیل را اجرا نمائید (فقط برای برنامههای دات نت 4 البته):
PM> Install-Package Microsoft.Bcl.Async
استفاده از Froala WYSIWYG Editor در ASP.NET
از آنجا که یک کد مدیریت نشده، مبحث کارهای JIT را ندارد، ولی CLR مجبور است وقتی را برای آن بگذارد، به نظر میرسد ما با یک نقص کوچک در کارآیی روبرو هستیم. گفتیم که جیت کدها را در حافظهی پویا ذخیره میکند. به همین خاطر با terminate شدن یا خاتمه دادن به برنامه، این کدها از بین میروند یا اینکه اگر دو نمونه از برنامه را اجرا کنیم، هر کدام جداگانه کد را تولید میکنند و هر کدام برای خودشان حافظهای بر خواهند داشت و اگر مقایسهای با کدهای مدیریت نشده داشته باشید، در مورد مصرف حافظه یک مشکل ایجاد میکند. همچنین JIT در حین تبدیل به کدهای بومی یک بهینه سازی روی کد هم انجام میدهد که این بهینه سازی وقتی را به خود اختصاص میدهد ولی همین بهینه سازی کد موجب کارآیی بهتر برنامه میگردد.
در زبان سی شارپ دو سوئیچ وجود دارند که بر بهینه سازی کد تاثیر گذار هستند؛ سوئیچهای debug و optimize. در جدول زیر تاثیر هر یک از سوئیچها را بر کیفیت کد IL و JIT در تبدیل به کد بومی را نشان میدهد.
موقعیکه از دستور -optimize استفاده میشود، کد IL تولید شده شامل تعداد زیادی از دستورات بدون دستورالعمل No Operation یا به اختصار NOP و پرشهای شاخهای به خط کد بعدی میباشد. این دستور العملها ما را قادر میسازند تا ویژگی edit & Continue را برای دیباگ کردن و یک سری دستورالعملها را برای کدنویسی راحتتر برای دیباگ کردن و ایجاد break pointها داشته باشیم.
موقعی که کد IL بهینه شده تولید شود، این خصوصیات اضافه حذف خواهند شد و دنبال کردن خط به خط کد، کار سختی میشود. ولی در عوض فایل نهایی exe یا dll، کوچکتر خواهد شد. بهینه سازی IL توسط JIT حذف خواهد شد و برای کسانی که دوست دارند کدهای IL را تحلیل و آنالیز کنند، خواندنش سادهتر و آسانتر خواهد بود.
نکتهی بعدی اینکه موقعیکه شما از سوئیچ (/debug(+/full/pdbonly استفاده میکنید، یک فایل PDB یا Program Database ایجاد میشود. این فایل به دیباگرها کمک میکند تا متغیرهای محلی را شناسایی و به کدهای IL متصل شوند. کلمهی full بدین معنی است که JIT میتواند دستورات بومی را ردیابی کند تا مبداء آن کد را پیدا کند. سبب میشود که ویژوال استودیو به یک دیباگر متصل شده تا در حین اجرای پروسه، آن را دیباگ کند. در صورتی که این سوئیچ را استفاده نکنید، به طور پیش فرض پروسه اجرا و مصرف حافظه کمتر میشود. اگر شما پروسهای را اجرا کنید که دیباگر به آن متصل شود، به طور اجباری JIT مجبور به انجام عملیات ردیابی خواهد شد؛ مگر اینکه گزینهی suppress jit optimization on module load را غیرفعال کرده باشید.
موقعیکه در ویژوال استودیو دو حالت دیباگ و ریلیز را انتخاب میکنید، در واقع تنظیمات زیر را اجرا میکنید:
//debug /optimize /debug:full //======================= //Release /optimize+ /debug:pdbonly
اگر خیلی شک دارید که واقعا یک برنامهی CLR کارآیی یک برنامه را پایین میآورد، بهتر هست به بررسی کارآیی چند برنامه غیر آزمایشی noTrial که حتی خود مایکروسافت آن برنامهها را ایجاد کرده است بپردازید و آنها را با یک برنامهی unmanaged مقایسه کنید. قطعا باعث تعجب شما خواهد شد. این نکته دلایل زیادی دارد که در زیر تعدادی از آنها را بررسی میکنیم.
اینکه CLR در محیط اجرا قصد کمپایل دارد، باعث آشنایی کامپایلر با محیط اجرا میگردد. از این رو تصمیماتی را که میگیرد، میتواند به کارآیی یک برنامه کمک کند. در صورتیکه یک برنامهی unmanaged که قبلا کمپایل شده و با محیطهای متفاوتی که روی آنها اجرا میشود، هیچ آشنایی ندارد و نمیتواند از آن محیطها حداکثر بهرهوری لازم را به عمل آورد.
برای آشنایی با این ویژگیها توجه شما را به نکات ذیل جلب میکنم:
یک. JIT میتواند با نوع پردازنده آشنا شود که آیا این پردازنده از نسل پنتیوم 4 است یا نسل Core i. به همین علت میتواند از این مزیت استفاده کرده و دستورات اختصاصی آنها را به کار گیرد، تا برنامه با performance بالاتری اجرا گردد. در صورتی که unmanaged باید حتما دستورات را در پایینترین سطح ممکن و عمومی اجرا کند؛ در صورتیکه شاید یک دستور اختصاصی در یک سی پی یو خاص، در یک عملیات موجب 4 برابر، اجرای سریعتر شود.
دو. JIT میتواند بررسی هایی را که برابر false هستند، تشخیص دهد. برای فهم بهتر، کد زیر را در نظر بگیرید:
if (numberOfCPUs > 1) { ... }
سه. مورد بعدی که هنوز پیاده سازی نشده، ولی احتمال اجرای آن در آینده است، این است که یک کد میتواند جهت تصحیح بعضی موارد چون مسائل مربوط به دیباگ کردن و مرتب سازیهای مجدد، عمل کامپایل را مجددا برای یک کد اعمال نماید.
دلایل بالا تنها قسمت کوچکی است که به ما اثبات میکند که چرا CLR میتواند کارآیی بهتری را نسبت به زبانهای unmanaged امروزی داشته باشد. همچنین قولهایی از سازندگان برای بهبود کیفیت هر چه بیشتر این سیستمها به گوش میرسد.
کارآیی بالاتر
اگر برنامهای توسط شما بررسی شد و دیدید که نتایج مورد نیاز در مورد performance را نشان نمیدهد، میتوانید از ابزار کمکی که مایکروسافت در بستههای فریمورک دات نت قرار داده است استفاده کنید. نام این ابزار Ngen.exe است و وظیفهی آن این است که وقتی برنامه بر روی یک سیستم برای اولین مرتبه اجرا میگردد، کد همهی اسمبلیها را تبدیل کرده و آنها روی دیسک ذخیره میکند. بدین ترتیب در دفعات بعدی اجرا، JIT بررسی میکند که آیا کد کامپایل شدهی اسمبلی از قبل موجود است یا خیر. در صورت وجود، عملیات کامپایل به کد بومی لغو شده و از کد ذخیره شده استفاده خواهد کرد.
نکتهای که باید در حین استفاده از این ابزار به آن دقت کنید این است که کد در محیطهای واقعی اجرا چندان بهینه نیست. بعدا در مورد این ابزار به تفصیل صحبت میکنیم.
system.runtime.profileoptimization
کلاس بالا سبب میشود که CLR در یک فایل ثبت کند که چه متدهایی در حین اجرای برنامه کمپایل شوند تا در آینده در حین آغاز اجرای برنامه کامپایلر JIT بتواند همزمان این متدها را در ترد دیگری کامپایل کند. اگر برنامهی شما روی یک پردازندهی چند هستهای اجرا میشود، در نتیجه اجرای سریعتری خواهید داشت. به این دلیل که چندین متد به طور همزمان در حال کمپایل شدن هستند و همزمان با آماده سازی برنامه برای اجرا اتفاق میافتد؛ به جای اینکه عمل کمپایل همزمان با تعامل کاربر با برنامه باشد.
ترکیب کامپوننتها
در ادامه، همان برنامهی تا قسمت 5 را که کار نمایش یک counter را انجام میدهد، تکمیل میکنیم. در این برنامه اگر به فایل index.js دقت کنید، کار رندر تک کامپوننت Counter را انجام میدهیم:
ReactDOM.render(<Counter />, document.getElementById("root"));
برای نمایش این مفهوم، کامپوننت جدید src\components\counters.jsx را ایجاد میکنیم. قصد داریم در این کامپوننت، لیستی از کامپوننتهای Counter را رندر کنیم. سپس در index.js، بجای رندر کامپوننت Counter، کامپوننت جدید Counters را رندر میکنیم. به این ترتیب درخت کامپوننتهای برنامه، در سطح بالایی خودش از کامپوننت Counters شروع میشود و سپس فرزندان آنرا کامپوننتهای Counter تشکیل میدهند. به همین جهت فایل index.js را به صورت زیر ویرایش میکنیم تا به کامپوننت Counters اشاره کند:
import Counters from "./components/counters"; ReactDOM.render(<Counters />, document.getElementById("root"));
import React, { Component } from "react"; import Counter from "./counter"; class Counters extends Component { state = {}; render() { return ( <div> <Counter /> <Counter /> <Counter /> <Counter /> </div> ); } } export default Counters;
در مرحلهی بعد، بجای رندر و درج دستی این کامپوننتها، آرایهای از اشیاء counter را ایجاد کرده و سپس آنها را توسط متد Array.map رندر میکنیم:
import React, { Component } from "react"; import Counter from "./counter"; class Counters extends Component { state = { counters: [ { id: 1, value: 0 }, { id: 2, value: 0 }, { id: 3, value: 0 }, { id: 4, value: 0 } ] }; render() { return ( <div> {this.state.counters.map(counter => ( <Counter key={counter.id} /> ))} </div> ); } } export default Counters;
ارسال دادهها به کامپوننتها
مشکل! مقدار value هر شیء شمارشگر تعریف شده، به کامپوننتهای مرتبط رندر شده اعمال نشدهاست. برای مثال اگر value اولین شیء را به 4 تغییر دهیم، هنوز هم این کامپوننت با همان مقدار صفر شروع به کار میکند. برای رفع این مشکل، به همان روشی که ویژگی key کامپوننت Counter را مقدار دهی کردیم، میتوان ویژگیهای سفارشی دیگری را تعریف و مقدار دهی کرد:
render() { return ( <div> {this.state.counters.map(counter => ( <Counter key={counter.id} value={counter.value} selected={true} /> ))} </div> );
class Counter extends Component { state = { count: 0 }; render() { console.log("props", this.props); //...
خاصیت this.props، یک شیء سادهی جاوا اسکریپتی است و شامل تمام ویژگیهایی میباشد که ما در کامپوننت Counters برای هر کدام از کامپوننتهای Counter رندر شدهی توسط آن، تعریف کردیم. برای نمونه دو ویژگی جدید value و selected را که به تعاریف المانهای Counter در کامپوننت Counters اضافه کردیم، در اینجا به همراه مقادیر منتسب به آنها، قابل مشاهده هستند. البته در این خروجی، key را ملاحظه نمیکنید؛ چون هدف اصلی آن، معرفی یکتای المانها در DOM مجازی React است.
بنابراین اکنون میتوان به value تنظیم شدهی در کامپوننت Counters به صورت this.props.value در کامپوننت Counter دسترسی یافت و سپس از آن جهت مقدار دهی اولیهی counter استفاده کرد.
class Counter extends Component { state = { count: this.props.value };
یک نکته: در اینجا selected={true} را داریم. اگر مقدار آنرا حذف کنیم، یعنی selected تنها درج شود، مقدار آن، همان true دریافت خواهد شد.
تعریف فرزند برای المانهای کامپوننتها
ویژگیهای اضافه شدهی به تعاریف المانهای کامپوننتها، توسط خاصیت this.props، به هر کدام از آن کامپوننتها منتقل میشوند. این خاصیت props، یک خاصیت ویژه را به نام children، نیز دارا است و از آن برای دسترسی به المانهای تعریف شدهی بین تگهای یک المان اصلی استفاده میشود:
render() { return ( <div> {this.state.counters.map(counter => ( <Counter key={counter.id} value={counter.value} selected={true}> <h4>Counter #{counter.id}</h4> </Counter> ))} </div> ); }
یک نمونه مثال واقعی این قابلیت، امکان تعریف محتوای دیالوگ باکسها، توسط استفاده کنندهی از آن است.
روش دیباگ برنامههای React
افزونهی مفید React developer tools را میتوانید برای مرورگرهای کروم و فایرفاکس، دریافت و نصب کنید. برای نمونه پس از نصب آن در مرورگر کروم، یک برگهی جدید به لیست برگههای کنسول توسعه دهندگان آن اضافه میشود:
همانطور که مشاهده کنید، درخت کامپوننتهای برنامه را در برگهی جدید Components، میتوان مشاهده کرد. در اینجا با انتخاب هر کدام از فرزندان این درخت، مشخصات آن نیز مانند props و state، در کنار صفحه ظاهر میشوند. همچنین در بالای همین قسمت، 4 آیکن مشاهدهی سورس، مشاهدهی DOM و یا لاگ کردن جزئیات شیء کامپوننت انتخابی در کنسول هم درج شدهاند:
که برای نمونه چنین خروجی را لاگ میکند:
بررسی تفاوتهای خواص props و state
در کامپوننت Counter، از props برای مقدار دهی اولیهی state استفاده میکنیم:
class Counter extends Component { state = { count: this.props.value };
- props حاوی اطلاعاتی است که به یک کامپوننت ارسال میکنیم؛ اما state حاوی اطلاعاتی است که مختص به آن کامپوننت بوده و private است. یعنی سایر کامپوننتها نمیتوانند به state کامپوننت دیگری دسترسی پیدا کنند. برای مثال در کامپوننت Counters، تمام attributes سفارشی تنظیم شدهی بر روی تعاریف المانهای کامپوننت Counter، جزئی از اطلاعات props خواهند بود. در اینجا نمیتوان به state کامپوننت مدنظری دسترسی یافت و آنرا مقدار دهی کرد. به همین ترتیب state کامپوننت Counters نیز در سایر کامپوننتها قابل دسترسی نیست.
- همچنین باید درنظر داشت که props، در مقایسه با state، فقط خواندنی است. به عبارتی مقدار ورودی به یک کامپوننت را داخل آن کامپوننت نمیتوان تغییر داد. برای مثال سعی کنید در داخل متد رویدادگردان کلیک موجود در کامپوننت Counter، مقدار this.props.value را به صفر تنظیم کنید. در این حالت با کلیک بر روی دکمهی Increment، بلافاصله خطای readonly بودن خواص شیء منتسب به props را دریافت میکنیم. در اینجا اگر نیاز است این مقدار را داخل کامپوننت تغییر دهیم، باید ابتدا این مقدار را دریافت کرده و سپس آنرا داخل state قرار دهیم. پس از آن امکان ویرایش اطلاعات منتسب به state، داخل یک کامپوننت وجود خواهد داشت.
صدور و مدیریت رخدادها
در ادامه میخواهیم در کنار هر دکمهی Increment کامپوننت شمارشگر، یک دکمهی Delete هم قرار دهیم:
مشکل! اگر کد مدیریتی handleDelete را در کامپوننت Counter قرار دهیم، چگونه باید به لیست آرایهی اشیاء counters والد آن، یعنی کامپوننت Counters که سبب رندر شدن کامپوننتهای شمارشگر شده (state = { counters: [ ] })، دسترسی یافت و شیءای را از آن حذف کرد؟ در React، کامپوننتی که state ای را تعریف میکند، باید کامپوننتی باشد که قرار است آنرا تغییر دهد و اطلاعات state هر کامپوننت، صرفا متعلق به آن کامپوننت بوده و جزو اطلاعات خصوصی آن است. بنابراین مدیریت حذف و یا افزودن کامپوننتها در لیست نمایش داده شده، باید جزو وظایف کامپوننت Counters باشد و نه Counter.
برای حل این مشکل، کامپوننت Counter تعریف شده (کامپوننت فرزند) باید سبب بروز رخداد onDelete شود تا کامپوننت Counters (کامپوننت والد)، آنرا توسط متد handleDelete مدیریت کند. بنابراین ابتدا به کامپوننت Counters (کامپوننت والد) مراجعه کرده و متد رویدادگردان handleDelete را به آن اضافه میکنیم:
handleDelete = () => { console.log("handleDelete called."); };
<Counter key={counter.id} value={counter.value} selected={true} onDelete={this.handleDelete} />
<button onClick={this.props.onDelete} className="btn btn-danger btn-sm m-2" > Delete </button>
اکنون اگر برنامه را ذخیره کرده و پس از بارگذاری مجدد برنامه در مرورگر بر روی دکمهی Delete کلیک کنیم، پیام «handleDelete called» در کنسول توسعه دهندگان مرورگر لاگ میشود. به این ترتیب کامپوننت فرزند سبب بروز رخدادی شده و والد آن، این رخداد را مدیریت میکند.
به روز رسانی state
تا اینجا دکمهی Delete فرزند، به متد handleDelete والد متصل شدهاست. مرحلهی بعد، پیاده سازی واقعی حذف یک المان از DOM مجازی و به روز رسانی state است. برای اینکار ابتدا به رخدادگردان onClick، در کامپوننت شمارشگر، مراجعه کرده و id دریافتی را به سمت والد ارسال میکنیم:
onClick={() => this.props.onDelete(this.props.id)}
<Counter key={counter.id} value={counter.value} selected={true} onDelete={this.handleDelete} id={counter.id} />
handleDelete = counterId => { console.log("handleDelete called.", counterId); const counters = this.state.counters.filter( counter => counter.id !== counterId ); this.setState({ counters }); // = this.setState({ counters: counters }); };
البته پیاده سازی ما تا به اینجا بدون مشکل کار میکند، اما به ازای هر خاصیت counter، یک ویژگی جدید را به تعریف المان مرتبط اضافه کردهایم که در طول زمان بیش از اندازه طولانی خواهد شد. برای رفع این مشکل، خود شیء counter را به صورت یک ویژگی جدید به کامپوننت مرتبط با آن ارسال میکنیم. به این ترتیب اگر در آینده خاصیتی را به این شیء اضافه کردیم، دیگر نیازی نیست تا آنرا به صورت دستی و مجزا تعریف کنیم. به همین جهت ابتدا تعریف المان Counter را به صورت زیر خلاصه میکنیم که در آن ویژگی جدید counter، حاوی کل شیء counter است:
<Counter key={counter.id} counter={counter} onDelete={this.handleDelete} />
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: sample-07.zip
12.استفاده از validation سمت کاربر
13.استفاده از validation سمت سرور
14.چک کردن scriptهای مورد استفاده سمت کاربر
ایندکسها در RavenDB
خوب؛ اکنون این سؤال مطرح میشود که RavenDB چگونه اطلاعاتی را در این اسناد بدون اسکیما جستجو میکند؟ اینجا است که مفهوم و کاربرد ایندکسها مطرح میشوند. ما در قسمت قبل که کوئری نویسی مقدماتی را بررسی کردیم، عملا ایندکس خاصی را به صورت دستی جهت انجام جستجوها ایجاد نکردیم؛ از این جهت که خود RavenDB به کمک امکانات dynamic indexing آن، پیشتر اینکار را انجام داده است. برای نمونه به سطر ارسال کوئری به سرور، که در قسمت قبل ارائه شد، دقت کنید. در اینجا ارسال کوئری به indexes/dynamic کاملا مشخص است:
Request # 2: GET - 3,818 ms - <system> - 200 - /indexes/dynamic/Questions?&query=Title%3ARaven*&pageSize=128
Dynamic Indexes یا ایندکسهای پویا
ایندکسهای پویا زمانی ایجاد خواهند شد که ایندکس صریحی توسط برنامه نویس تعریف نگردد. برای مثال زمانیکه یک کوئری LINQ را صادر میکنیم، RavenDB بر این اساس و برای مثال فیلدهای قسمت Where آن، ایندکس پویایی را تولید خواهد کرد. ایجاد ایندکسها در RavenDB از اصل عاقبت یک دست شدن پیروی میکنند. یعنی مدتی طول خواهد کشید تا کل اطلاعات بر اساس ایندکس جدیدی که در حال تهیه است، ایندکس شوند. بنابراین تولید ایندکسهای پویا در زمان اولین بار اجرای کوئری، کوئری اول را اندکی کند جلوه خواهند داد؛ اما کوئریهای بعدی که بر روی یک ایندکس آماده اجرا میشوند، بسیار سریع خواهند بود.
Static indexes یا ایندکسهای ایستا
ایندکسهای پویا به دلیل وقفه ابتدایی که برای تولید آنها وجود خواهد داشت، شاید آنچنان مطلوب به نظر نرسند. اینجا است که مفهوم ایندکسهای ایستا مطرح میشوند. در این حالت ما به RavenDB خواهیم گفت که چه چیزی را ایندکس کند. برای تولید ایندکسهای ایستا، از مفاهیم Map/Reduce که در پیشنیازهای دوره جاری در مورد آن بحث شد، استفاده میگردد. خوشبختانه تهیه Map/Reduceها در RavenDB پیچیده نبوده و کل عملیات آن توسط کوئریهای LINQ قابل پیاده سازی است.
تهیه ایندکسهای پویا نیز در تردهای پسزمینه انجام میشوند. از آنجائیکه RavenDB برای اعمال Read، بهینه سازی شده است، با ارسال یک کوئری به آن، این بانک اطلاعاتی، کلیه اطلاعات آماده را در اختیار شما قرار خواهد داد؛ صرفنظر از اینکه کار تهیه ایندکس تمام شده است یا خیر.
چگونه یک ایندکس ایستا را ایجاد کنیم؟
اگر به کنسول مدیریتی سیلورلایت RavenDB مراجعه کنیم، حاصل کوئریهای LINQ قسمت قبل را در برگهی ایندکسهای آن میتوان مشاهده کرد:
در اینجا بر روی دکمه Edit کلیک نمائید، تا با نحوه تهیه این ایندکس پویا آشنا شویم:
این ایندکس، یک نام داشته به همراه قسمت Map از پروسه Map/Reduce که توسط یک کوئری LINQ تهیه شده است. کاری که در اینجا انجام شده، ایندکس کردن کلیه سؤالات، بر اساس خاصیت عنوان آنها است.
اکنون اگر بخواهیم همین کار را با کدنویسی انجام دهیم، به صورت زیر میتوان عمل کرد:
using System; using System.Linq; using Raven.Client.Document; using RavenDBSample01.Models; using Raven.Client; using Raven.Client.Linq; using Raven.Client.Indexes; namespace RavenDBSample01 { class Program { static void Main(string[] args) { using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { store.DatabaseCommands.PutIndex( name: "Questions/ByTitle", indexDef: new IndexDefinitionBuilder<Question> { Map = questions => questions.Select(question => new { Title = question.Title } ) }); } } } }
برنامه را اجرا کرده و سپس به کنسول مدیریتی تحت وب RavenDB، قسمت ایندکسهای آن مراجعه کنید. در اینجا میتوان ایندکس جدید ایجاد شده را مشاهده کرد:
هرچند همین اعمال را در کنسول مدیریتی نیز میتوان انجام داد، اما مزیت آن در سمت کدها، دسترسی به intellisense و نوشتن کوئریهای strongly typed است.
روش استفاده از store.DatabaseCommands.PutIndex اولین روش تولید Index در RavenDB با کدنویسی است. روش دوم، بر اساس ارث بری از کلاس AbstractIndexCreationTask شروع میشود و مناسب است برای حالتیکه نمیخواهید کدهای تولید ایندکس، با کدهای سایر قسمتهای برنامه مخلوط شوند:
public class QuestionsByTitle : AbstractIndexCreationTask<Question> { public QuestionsByTitle() { Map = questions => questions.Select(question => new { Title = question.Title }); } }
اکنون برای معرفی آن به برنامه باید از متد IndexCreation.CreateIndexes استفاده کرد. این متد، نیاز به دریافت اسمبلی محل تعریف کلاسهای تولید ایندکس را دارد. به این ترتیب تمام کلاسهای مشتق شده از AbstractIndexCreationTask را یافته و ایندکسهای متناظری را تولید میکند.
using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { IndexCreation.CreateIndexes(typeof(QuestionsByTitle).Assembly, store); }
استفاده از ایندکسهای ایستای ایجاد شده
تا اینجا موفق شدیم ایندکسهای ایستای خود را با کد نویسی ایجاد کنیم. در ادامه قصد داریم از این ایندکسها در کوئریهای خود استفاده نمائیم.
using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { using (var session = store.OpenSession()) { var questions = session.Query<Question>(indexName: "QuestionsByTitle") .Where(x => x.Title.StartsWith("Raven")).Take(128); foreach (var question in questions) { Console.WriteLine(question.Title); } } }
Request # 147: GET - 58 ms - <system> - 200 - /indexes/QuestionsByTitle?&query=Title%3ARaven*&pageSize=128 Query: Title:Raven* Time: 7 ms Index: QuestionsByTitle Results: 2 returned out of 2 total.
var questions = session.Query<Question, QuestionsByTitle>() .Where(x => x.Title.StartsWith("Raven")).Take(128);
ایجاد ایندکسهای پیشرفته با پیاده سازی Map/Reduce
حالتی را در نظر بگیرید که در آن قصد داریم تعداد عنوانهای سؤالات مانند هم را بیابیم (یا تعداد مطالب گروههای مختلف یک وبلاگ را محاسبه کنیم). برای انجام اینکار با سرعت بسیار بالا، میتوانیم از ایندکسهایی با قابلیت محاسباتی در RavenDB استفاده کنیم. کار با ارث بری از کلاس AbstractIndexCreationTask شروع میشود. آرگومان جنریک اول آن، نام کلاسی است که در تهیه ایندکس شرکت خواهد داشت و آرگومان دوم (و اختیاری) ذکر شده، نتیجه عملیات Reduce است:
public class QuestionsCountByTitleReduceResult { public string Title { set; get; } public int Count { set; get; } } public class QuestionsCountByTitle : AbstractIndexCreationTask<Question, QuestionsCountByTitleReduceResult> { public QuestionsCountByTitle() { Map = questions => questions.Select(question => new { Title = question.Title, Count = 1 }); Reduce = results => results.GroupBy(x => x.Title) .Select(g => new { Title = g.Key, Count = g.Sum(x => x.Count) }); } }
اکنون برای استفاده از این ایندکس، ابتدا توسط متد IndexCreation.CreateIndexes، کار معرفی آن به RavenDB صورت گرفته و سپس متد Query سشن باز شده، دو آرگومان جنریگ را خواهد پذیرفت. اولین آرگومان، همان نتیجه Map/Reduce است و دومین آرگومان نام کلاس ایندکس جدید تعریف شده میباشد:
using (var store = new DocumentStore { Url = "http://localhost:8080" }.Initialize()) { IndexCreation.CreateIndexes(typeof(QuestionsCountByTitle).Assembly, store); using (var session = store.OpenSession()) { var result = session.Query<QuestionsCountByTitleReduceResult, QuestionsCountByTitle>() .FirstOrDefault(x => x.Title == "Raven") ?? new QuestionsCountByTitleReduceResult(); Console.WriteLine(result.Count); } }