فریم ورک Blazor
فریم ورک Blazor یک پروژه ی آزمایشی است که به تازگی به ASP اضافه شده و امکان استفاده از Web Assembly در دات نت را فراهم میکند. تمام مرورگرهای جدید از Web Assembly پشتیبانی می کنند. در نتیجه می توانید برنامه ی کلاینتی بنویسید که مانند جاوا اسکریپت به رویدادهای موس و کیبورد واکنش میدهد در کلاینت اجرا میشود.
نسخه ی آزمایشی این فریم ورک قابلیت دیباگ و Live Reloading دارد همچنین به شما امکان میدهد کامپوننت هایی بنویسید که به صورت تو در تو به هم وابستگی دارند. ابزاری مانند Dependency Injection و Server-Side Rendering هم در آن گنجاده خواهد شد.
یکی از جالبترین قابلیت های این فریم ورک امکان اجرای دستورات جاوا اسکریپت از درون #C است. حجم فریم ورک در حدود 400 کیلوبایت است که به همراه اولین بارگذاری صفحه دانلود میشود. در صورت عدم پشتیبانی مرورگر از Web Assembly یک فایل جاوا اسکریپت اجرای کدهای #C را شبیه سازی میکند. پس برنامه ی شما روی مرورگرهای قدیمی هم بدون مشکل اجرا خواهد شد.
جهت دانلود و نصب قالب نمونه می توانید به آدرس زیر مراجعه کنید :
https://github.com/aspnet/blazor
فریم ورک Blazor یک پروژه ی آزمایشی است که به تازگی به ASP اضافه شده و امکان استفاده از Web Assembly در دات نت را فراهم میکند. تمام مرورگرهای جدید از Web Assembly پشتیبانی می کنند. در نتیجه می توانید برنامه ی کلاینتی بنویسید که مانند جاوا اسکریپت به رویدادهای موس و کیبورد واکنش میدهد در کلاینت اجرا میشود.
نسخه ی آزمایشی این فریم ورک قابلیت دیباگ و Live Reloading دارد همچنین به شما امکان میدهد کامپوننت هایی بنویسید که به صورت تو در تو به هم وابستگی دارند. ابزاری مانند Dependency Injection و Server-Side Rendering هم در آن گنجاده خواهد شد.
یکی از جالبترین قابلیت های این فریم ورک امکان اجرای دستورات جاوا اسکریپت از درون #C است. حجم فریم ورک در حدود 400 کیلوبایت است که به همراه اولین بارگذاری صفحه دانلود میشود. در صورت عدم پشتیبانی مرورگر از Web Assembly یک فایل جاوا اسکریپت اجرای کدهای #C را شبیه سازی میکند. پس برنامه ی شما روی مرورگرهای قدیمی هم بدون مشکل اجرا خواهد شد.
جهت دانلود و نصب قالب نمونه می توانید به آدرس زیر مراجعه کنید :
https://github.com/aspnet/blazor
GitHub
GitHub - dotnet/blazor: Blazor moved to https://github.com/dotnet/aspnetcore
Blazor moved to https://github.com/dotnet/aspnetcore - GitHub - dotnet/blazor: Blazor moved to https://github.com/dotnet/aspnetcore
معرفی Technical Debt
بدهی فنی یا Technical Debt زمانی پیش می آید که بجای راه درست راه سریع را در پیش میگیرید. راه درست در بسیاری موارد طولانی و پیچیده است و شما خسته هستید،حوصله ندارید یا عجله دارید، پس سعی میکنید از راه میانبر بروید و با سرهم بندی مشکل را حل کنید.
ممکن است انتخاب راه میانبر از روی نادانستن باشد. اما معمولا این انتخاب عمدی است. محدودیت پول و زمان ، فشار کارفرما و یا باگ می تواند شما را به مسیر میانبر هدایت کند. وقتی سایت شما با هزاران کاربر ناگهان کرش میکند چیزی که اهمیت دارد آنلاین شدن مجدد پروژه است. با خود میگوید بعدا برمیگردم و اصلاح میکنم. اینجاست که بدهکار میشوید. بدهی مانند لایه های چربی دور شکم پروژه ی جمع میشود و آن را سنگین و مریض میکند.
هر چقدر پروژه بزرگتر باشد بدهی فنی با سرعت بیشتری بالا میرود. وقتی از برنامه عقب باشید اعضای تیم شروع به میانبر زدن میکنند و رهگیری همه آنها برای مدیر پروژه غیر ممکن است.
بدهی فنی لزوما بد نیست. در بسیاری از موارد چاره ای جز بدهکار شدن ندارید. مهم این است که :
1- بدانید کجا در حال میانبر زدن هستید.
2- آمار آن را به خوبی نگه دارید و هر وقت میانبر زدید جایی ثبت کنید.
3- همه روزه بخشی از زمان خود را صرف از بین بردن بدهی های قبلی کنید.
4- هیچوقت اجاز ندهید میزان بدهی فنی از 20 درصد کل پروژه بیشتر شود.
هر چه میزان بدهی بالا رود توسعه ی پروژه در درازمدت سخت تر میشود. خیلی زود مجبور میشوید روی میانبر های قبل میانبر های جدید پیاده کنید. آن وقت است که باید زنگ خطر را به صدا در آورید.
همانطور که بدهی بیش از حد باعث ورشکستگی میشود و وزن زیاد هم برای بدن شما خوب نیست ، بدهی فنی هم می تواند توسعه ی پروژه را غیر ممکن کند و هزینه ی حفظ و نگه داری را بیش از حد بالا ببرد. تا جایی که مجبور میشوید پروژه را رها کنید یا آن را از نو پیاده کنید.
بدهی فنی یا Technical Debt زمانی پیش می آید که بجای راه درست راه سریع را در پیش میگیرید. راه درست در بسیاری موارد طولانی و پیچیده است و شما خسته هستید،حوصله ندارید یا عجله دارید، پس سعی میکنید از راه میانبر بروید و با سرهم بندی مشکل را حل کنید.
ممکن است انتخاب راه میانبر از روی نادانستن باشد. اما معمولا این انتخاب عمدی است. محدودیت پول و زمان ، فشار کارفرما و یا باگ می تواند شما را به مسیر میانبر هدایت کند. وقتی سایت شما با هزاران کاربر ناگهان کرش میکند چیزی که اهمیت دارد آنلاین شدن مجدد پروژه است. با خود میگوید بعدا برمیگردم و اصلاح میکنم. اینجاست که بدهکار میشوید. بدهی مانند لایه های چربی دور شکم پروژه ی جمع میشود و آن را سنگین و مریض میکند.
هر چقدر پروژه بزرگتر باشد بدهی فنی با سرعت بیشتری بالا میرود. وقتی از برنامه عقب باشید اعضای تیم شروع به میانبر زدن میکنند و رهگیری همه آنها برای مدیر پروژه غیر ممکن است.
بدهی فنی لزوما بد نیست. در بسیاری از موارد چاره ای جز بدهکار شدن ندارید. مهم این است که :
1- بدانید کجا در حال میانبر زدن هستید.
2- آمار آن را به خوبی نگه دارید و هر وقت میانبر زدید جایی ثبت کنید.
3- همه روزه بخشی از زمان خود را صرف از بین بردن بدهی های قبلی کنید.
4- هیچوقت اجاز ندهید میزان بدهی فنی از 20 درصد کل پروژه بیشتر شود.
هر چه میزان بدهی بالا رود توسعه ی پروژه در درازمدت سخت تر میشود. خیلی زود مجبور میشوید روی میانبر های قبل میانبر های جدید پیاده کنید. آن وقت است که باید زنگ خطر را به صدا در آورید.
همانطور که بدهی بیش از حد باعث ورشکستگی میشود و وزن زیاد هم برای بدن شما خوب نیست ، بدهی فنی هم می تواند توسعه ی پروژه را غیر ممکن کند و هزینه ی حفظ و نگه داری را بیش از حد بالا ببرد. تا جایی که مجبور میشوید پروژه را رها کنید یا آن را از نو پیاده کنید.
نصب و راه اندازی 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 وجود دارد و در سایر سیستم عاملها پشتیبانی نمیشود.