نصب و راه اندازی dotnet watch
ابتدا باید بگم اگر سیستم شما دارای پردازنده ی سریع و رم بالایی نیست این ابزار کندتر از انتظار کار میکند. به نظر میرسه در نسخه ی 2.1 با تکنیک جدید بیلد سرعت این ابزار هم بیشتر باشه . قعلا باید منتظر نسخه ی بعدی باشیم.
برای نصب این ابزار کافیه پکیج Microsoft.DotNet.Watcher.Tools رو به پروژه اضافه کنید. البته مانند همه ی ابزار باید از طریق فایل csproj این کار را انجام دهید. خط زیر رو به فایل اضافه کنید :
<ItemGroup
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
</ItemGroup>
بعد از تغییر فایل csproj مطمئن شوید پکیج ها restore شوند. سپس برای فعال کردن سیستم watch کافی است در cmd به مسیر پروژه بروید و دستور dotnet watch run را اجرا کنید.
حالا بعد از هر تغییر در فایلهای cs بلافاصله سیستم متوجه میشه و پروژه رو مجدد بیلد میکنه. خوبه که یکبار امتحان کنید و سرعتش رو روی سیستم خودتون بررسی کنید.اطلاعات بیشتر در لینک زیر موجود است :
https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
ابتدا باید بگم اگر سیستم شما دارای پردازنده ی سریع و رم بالایی نیست این ابزار کندتر از انتظار کار میکند. به نظر میرسه در نسخه ی 2.1 با تکنیک جدید بیلد سرعت این ابزار هم بیشتر باشه . قعلا باید منتظر نسخه ی بعدی باشیم.
برای نصب این ابزار کافیه پکیج Microsoft.DotNet.Watcher.Tools رو به پروژه اضافه کنید. البته مانند همه ی ابزار باید از طریق فایل csproj این کار را انجام دهید. خط زیر رو به فایل اضافه کنید :
<ItemGroup
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
</ItemGroup>
بعد از تغییر فایل csproj مطمئن شوید پکیج ها restore شوند. سپس برای فعال کردن سیستم watch کافی است در cmd به مسیر پروژه بروید و دستور dotnet watch run را اجرا کنید.
حالا بعد از هر تغییر در فایلهای cs بلافاصله سیستم متوجه میشه و پروژه رو مجدد بیلد میکنه. خوبه که یکبار امتحان کنید و سرعتش رو روی سیستم خودتون بررسی کنید.اطلاعات بیشتر در لینک زیر موجود است :
https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch
Docs
Develop ASP.NET Core apps using a file watcher
This tutorial demonstrates how to install and use the .NET Core CLI's file watcher (dotnet watch) tool in an ASP.NET Core app.
میزان دانلود فریم ورک ReactJS در مقایسه با Angular و VueJS بسیار بیشتر است و عملا می توان گفت گوگل رقابت را به فیس بوک باخته است.
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
لینک زنده :
https://npmcharts.com/compare/react,@angular/core,vue
چرا انگولار محبوبیتش را از دست داد ؟
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.
برای سالها Angular محبوبترین فریم ورک Front-End بود. قابلیت هایی نظیر two-way data binding ، الگوی MVC و تزریق وابستگی در کنار ماژولار بودن کمک کرد تا Angular در بالای لیست قرار گیرد. گوگل تبدیل به حامی انگولار شد و همه چیز خوب پیش میرفت. (سال 2012)
بعد تیم های برنامه نویسی شروع به پیاده سازی پروژه های بزرگ با انگولار کردند. پروژه های بزرگ نقاط ضعف فریم ورک را رو کرد. همه چیز کند کار میکرد و بروز رسانی و تغییر غیر ممکن شد. عیب یابی و دیباگ کردن تبدیل به یک چالش اساسی شد.
در همین زمان برنامه نویسان دیگر با کسب تجربه از ایرادات انگولار شروع به توسعه ی فریم ورکهای جدید کردند.در نتیجه گوگل برای عقب نماندن از دیگران تصمیم گرفت انگولار را از نو پیاده کند.(سال 2014)
تصمیم انگولار به بازنویسی کل فریم ورک بسیاری از برنامه نویسان را آزرده کرد. در همین زمان React که به صورت یک پروژه آزمایشی توسط یکی از کارمندان فیس بوک شروع شده بود توجه ها را به سوی خود جلب کرد. همین نکته بس بود که اپلیکیشن فیس بوک با میلیونها کاربر از React استفاده میکرد. (سال 2013)
انگولار 2 مجموعه از تصمیم های غلط بود و خیلی دیر عرضه شد. برنامه نویسان قبلی علاوه بر یادگیری فریم ورک جدید باید نحوه ی کار با TypeScript را هم فرا میگرفتند. رو آوردن مایکروسافت به React هم بر محبویت آن افزود. بسیاری از سایتهای وابسته به مایکروسافت از React استفاده میکنند با اینکه مایکروسافت خود در پیاده سازی انگولار و TypeScript درگیر بوده است. (سال 2016)
واقعیت این است که Angular 2 بیش از حد کامل است که برای پروژه های بزرگ عالیست اما 80 درصد پروژه ها در دنیای وب این عظمت را ندارند. وقتی پروژه کوچک باشد پیچیدگی ها انگولار در کنار اجبار به استفاده از TypeScript یک مشکل جدی است. هنگامی که از انگولار استفاده میکنید ، باید همه ی آن را استفاده کنید و همه ی کارها را به روش انگولار انجام دهید. استفاده از jQuery یک انتخاب نیست.
انگولار 2 خیلی دیر رسید و وقتی رسید غول بزرگی بود که قدرتش بیش از اندازه زیاد بود. تغییرات زیادی داشت و معلوم نبود چه آینده ای دارد.در نتیجه خیلی از طرفداران انگولار به سنگر React پناه بردند.
در ASP Core برای اتصال به وب سرویس های WCF می توانید از افزونه ی WCF Web Service Provider استفاده کنید.
https://marketplace.visualstudio.com/items?itemName=WCFCORETEAM.VisualStudioWCFConnectedService
https://marketplace.visualstudio.com/items?itemName=WCFCORETEAM.VisualStudioWCFConnectedService
آپدیت سایت های ASP Core
در ASP قدیمی می توانستید سایت در حال کار را مستقیما آپدیت کنید. فقط کافی بود فایلهای جدید را جاگزین فایلهای قبلی کنید. اینکار از طریق FTP یا کپی فایل و Replace کردن ممکن بود. البته روشهای بهتری مثل WebDeploy هم وجود داشت اما از آنجا که خیلی از هاستها از آن پشتیبانی نمی کنند زیاد استفاده نمیشد. دلیل این مسئله وجود قابلیت Shadow Copy در ASP قدیم بود.
در CLR فایلها ی dll مربوط به یک برنامه هنگام اجرا قفل میشود. Shadow Copy از این dll ها یک کپی موقت در محل جدا ذخیره میکند و برنامه را از آنجا اجرا میکند. در نتیجه فایلهای اصلی قفل نمیشوند و می توان آنها را Replace کرد.
در ASP Core هنوز این قابلیت پیاده نشده. برای آپدیت کردن ابتدا باید سایت را stop کنید و بعد کپی کنید. اگر از WebDeploy استفاده کنید عملیات یکسان است اما به صورت خودکار انجام میشود. ضمن اینکه در WebDeploy فایل App_offline در مدت زمان آپدیت جایگزین سایت میشود. البته این گزینه هم فقط برای IIS وجود دارد و در سایر سیستم عاملها پشتیبانی نمیشود.
در ASP قدیمی می توانستید سایت در حال کار را مستقیما آپدیت کنید. فقط کافی بود فایلهای جدید را جاگزین فایلهای قبلی کنید. اینکار از طریق FTP یا کپی فایل و Replace کردن ممکن بود. البته روشهای بهتری مثل WebDeploy هم وجود داشت اما از آنجا که خیلی از هاستها از آن پشتیبانی نمی کنند زیاد استفاده نمیشد. دلیل این مسئله وجود قابلیت Shadow Copy در ASP قدیم بود.
در CLR فایلها ی dll مربوط به یک برنامه هنگام اجرا قفل میشود. Shadow Copy از این dll ها یک کپی موقت در محل جدا ذخیره میکند و برنامه را از آنجا اجرا میکند. در نتیجه فایلهای اصلی قفل نمیشوند و می توان آنها را Replace کرد.
در ASP Core هنوز این قابلیت پیاده نشده. برای آپدیت کردن ابتدا باید سایت را stop کنید و بعد کپی کنید. اگر از WebDeploy استفاده کنید عملیات یکسان است اما به صورت خودکار انجام میشود. ضمن اینکه در WebDeploy فایل App_offline در مدت زمان آپدیت جایگزین سایت میشود. البته این گزینه هم فقط برای IIS وجود دارد و در سایر سیستم عاملها پشتیبانی نمیشود.
چرا Kestrel ؟
فریم ورک ASP Core به نحوی طراحی شده است که روی یک پروسه ی جدا و خارج از IIS اجرا شود. در واقع ASP Core دیگر به wp3wp.exe وابسته نیست.
هدف از این کار یکسان نگه داشتن رفتار سایت فارغ از نوع سیستم عامل است. سیستم عامل های مختلف سرویس دهنده های خودشان را دارند. بجای مطابقت دادن فریم ورک ASP Core با هر کدام از آنها مانند (IIS , Ngnix , Apache ) از Kestrel به عنوان پروکسی معکوس استفاده میشود.
کسترل در مسیر بین ASP Core و سرویس دهنده (IIS , Ngnix , Apache ) قرار میگیرد . هر وقتی درخواستی به سرویس دهنده میرسد مستقیما به Kestrel پاس داده میشود . سپس Kestrel تمامی اطلاعات دریافتی را به شکلی قالب بندی می کند که برای ASP Core قابل تحلیل باشد.(HttpContext)
با این تکنیک تنها کافی است Kestrel با سرویس دهنده های مختلف سازگار شود و کد نویسی برای ASP Core در همه ی پلتفرم ها یکسان است.
فریم ورک ASP Core به نحوی طراحی شده است که روی یک پروسه ی جدا و خارج از IIS اجرا شود. در واقع ASP Core دیگر به wp3wp.exe وابسته نیست.
هدف از این کار یکسان نگه داشتن رفتار سایت فارغ از نوع سیستم عامل است. سیستم عامل های مختلف سرویس دهنده های خودشان را دارند. بجای مطابقت دادن فریم ورک ASP Core با هر کدام از آنها مانند (IIS , Ngnix , Apache ) از Kestrel به عنوان پروکسی معکوس استفاده میشود.
کسترل در مسیر بین ASP Core و سرویس دهنده (IIS , Ngnix , Apache ) قرار میگیرد . هر وقتی درخواستی به سرویس دهنده میرسد مستقیما به Kestrel پاس داده میشود . سپس Kestrel تمامی اطلاعات دریافتی را به شکلی قالب بندی می کند که برای ASP Core قابل تحلیل باشد.(HttpContext)
با این تکنیک تنها کافی است Kestrel با سرویس دهنده های مختلف سازگار شود و کد نویسی برای ASP Core در همه ی پلتفرم ها یکسان است.
چرا Libuv اهمیت دارد ؟
کتابخانه ی Libuv یا Unicorn Velociraptor Library و به معنی "ولوسی رپتور تک شاخ" است. این کتابخانه به زبان C نوشته شده و شامل 30 هزار خط کد میشود. libuv در ابتدا به عنوان هسته ی مرکزی فریم ورک Node.js پیاده شد ولی اکنون توسط بسیاری از فریم ورکهای دیگر مانند Kestrel استفاده میشود.
از آنجا که Kestrel بر پایه ی libuv پیاده شده است و برنامه های ASP Core درون Kestrel اجرا میشوند درک نحوه ی کار libuv برای رمزگشایی از ساختار ASP Core مهم است.
برنامه های ASP Core تنها از یک AppDomain استفاده میکنند و تنها روی یک پروسه اجرا میشوند. درون سیستم عامل یک برنامه ی ASP Core تنها یک Thread را اشغال میکند. نتیجه شاید عجیب باشد اما این تکنیک باعث شده سرعت پردازش اطلاعات نسبت به ASP قدیم بسیار زیاد شود.
کتابخانه ی libuv یک حلقه ی بی نهایت در درونش دارد و بر اساس درخواستها ورودی آنها را طبقه بندی میکند. مثلا تمامی تایمر ها را جدا لیست میکند. درخواستهایی که برای کار با دیتابیس یا فایل هستند در لیست مجزا و محاسبات ریاضی را هم بلافاصله اجرا میکند. در درون هسته libuv از 4 thread استفاده میکند و تنها زمانی آنها را به کار میگیرد که درخواستهای مربوط به فایل و دیتابیس زیادتر از ظرفیت جاری باشد.
این حلقه همیشه در حال اجراست و هیچوقت نمی توان آن را بلاک کرد. هیچ دستوری بلافاصله اجرا نمیشود. بلکه به درون حلقه پرتاپ میشود و طبق یک سری قانون زمان اجرای آن توسط libuv تعیین میشود.
در Node.js حلقه ی اصلی libuv تا حد زیادی ساده شده اما همچنان از همین قانون پیروی میکند. در واقع همه ی دستورات در Node.js به صورت Asyncهستند .
در ASP Core این عملیات به نحوی پیاده شده که دستورات Sync هم قابل اجرا باشند. شما مجبور به استفاده از Async نیستید اما توصیه میشود همیشه و همه جا از Async استفاده کنید چرا که ذات سیستم (Libuv) چنین انتظاری دارد.
کتابخانه ی Libuv یا Unicorn Velociraptor Library و به معنی "ولوسی رپتور تک شاخ" است. این کتابخانه به زبان C نوشته شده و شامل 30 هزار خط کد میشود. libuv در ابتدا به عنوان هسته ی مرکزی فریم ورک Node.js پیاده شد ولی اکنون توسط بسیاری از فریم ورکهای دیگر مانند Kestrel استفاده میشود.
از آنجا که Kestrel بر پایه ی libuv پیاده شده است و برنامه های ASP Core درون Kestrel اجرا میشوند درک نحوه ی کار libuv برای رمزگشایی از ساختار ASP Core مهم است.
برنامه های ASP Core تنها از یک AppDomain استفاده میکنند و تنها روی یک پروسه اجرا میشوند. درون سیستم عامل یک برنامه ی ASP Core تنها یک Thread را اشغال میکند. نتیجه شاید عجیب باشد اما این تکنیک باعث شده سرعت پردازش اطلاعات نسبت به ASP قدیم بسیار زیاد شود.
کتابخانه ی libuv یک حلقه ی بی نهایت در درونش دارد و بر اساس درخواستها ورودی آنها را طبقه بندی میکند. مثلا تمامی تایمر ها را جدا لیست میکند. درخواستهایی که برای کار با دیتابیس یا فایل هستند در لیست مجزا و محاسبات ریاضی را هم بلافاصله اجرا میکند. در درون هسته libuv از 4 thread استفاده میکند و تنها زمانی آنها را به کار میگیرد که درخواستهای مربوط به فایل و دیتابیس زیادتر از ظرفیت جاری باشد.
این حلقه همیشه در حال اجراست و هیچوقت نمی توان آن را بلاک کرد. هیچ دستوری بلافاصله اجرا نمیشود. بلکه به درون حلقه پرتاپ میشود و طبق یک سری قانون زمان اجرای آن توسط libuv تعیین میشود.
در Node.js حلقه ی اصلی libuv تا حد زیادی ساده شده اما همچنان از همین قانون پیروی میکند. در واقع همه ی دستورات در Node.js به صورت Asyncهستند .
در ASP Core این عملیات به نحوی پیاده شده که دستورات Sync هم قابل اجرا باشند. شما مجبور به استفاده از Async نیستید اما توصیه میشود همیشه و همه جا از Async استفاده کنید چرا که ذات سیستم (Libuv) چنین انتظاری دارد.
فایلهای استاتیک در ASP Core
در ASP NET قدیم وظیفه ی پاسخ دادن به درخواست فایل استاتیک بر عهده ی IIS بود. در نتیجه اگر در پروژه ی ASP باگی بوجود می آمد یا برنامه هنگ میکرد فایلهای استاتیک همچنان توسط کاربر قابل مشاهده بود.
در ASP Core این وظیفه به عهده ی یک Middleware است. تمامی درخواستهای مربوط به فایلهای استاتیک به میان افزار StaticFilesMiddleware منتقل میشود . اینکار سرعت پردازش اطلاعات را بالاتر میبرد چون در مواردی که نیاز به فایلهای استاتیک ندارید می توانید تصمیم بگیرید که این میان افزار را از کار بیاندازید . مثلا در وب سرویس ها نیازی به بررسی درخواستهای فایل استاتیک وجود ندارد با حذف این میان افزار می توانید منابع سرور را بیشتر آزاد کنید.
از طرف دیگر حالا اگر برنامه ی ASP Core کرش کند فایلهای استاتیک سایت هم از کار می افتد. راههایی برای دور زدن این مسئله و برگرداندن وظیفه ی مدیریت فایلهای استاتیک به IIS وجود دارد ولی انتخاب پیشفرض ASP Core نیست.
در ASP NET قدیم وظیفه ی پاسخ دادن به درخواست فایل استاتیک بر عهده ی IIS بود. در نتیجه اگر در پروژه ی ASP باگی بوجود می آمد یا برنامه هنگ میکرد فایلهای استاتیک همچنان توسط کاربر قابل مشاهده بود.
در ASP Core این وظیفه به عهده ی یک Middleware است. تمامی درخواستهای مربوط به فایلهای استاتیک به میان افزار StaticFilesMiddleware منتقل میشود . اینکار سرعت پردازش اطلاعات را بالاتر میبرد چون در مواردی که نیاز به فایلهای استاتیک ندارید می توانید تصمیم بگیرید که این میان افزار را از کار بیاندازید . مثلا در وب سرویس ها نیازی به بررسی درخواستهای فایل استاتیک وجود ندارد با حذف این میان افزار می توانید منابع سرور را بیشتر آزاد کنید.
از طرف دیگر حالا اگر برنامه ی ASP Core کرش کند فایلهای استاتیک سایت هم از کار می افتد. راههایی برای دور زدن این مسئله و برگرداندن وظیفه ی مدیریت فایلهای استاتیک به IIS وجود دارد ولی انتخاب پیشفرض ASP Core نیست.