نظرات مطالب
آشنایی با Refactoring - قسمت 1
نظرات مطالب
نوروز مبارک!
سلام آقای نصیری
نورزتون مبارک امیدوارم سال خوبی داشته باشید.
نورزتون مبارک امیدوارم سال خوبی داشته باشید.
نظرات مطالب
دریافت فایل از یوتیوب
سال نو مبارک، ایده جالبی بود.
نظرات مطالب
BloggerToCHM
ممنون. سال نوی شما هم مبارک باشه.
یک نکته تکمیلی:
بعد از Build کردن ریپازیتوری یا Pack کردن پکیج خود میتوانید فایلهای تولید شده را در جایی به نام "Artifacts" ذخیره کنید تا در زمان دلخواه بتوانید آنها را دانلود کنید
به جهت انجام این کار باید از اکشن upload-artifact استفاده کنید. مثال:
name: Build on: [push] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Setup .NET Core uses: actions/setup-dotnet@v1 - name: Build (Release) run: dotnet build src --configuration Release - name: Pack (Release) run: dotnet pack src --configuration Release - name: Upload Artifact uses: actions/upload-artifact@v1.0.0 with: name: Release_Artifacts path: src\bin\Release
- عبارت src به پوشه پروژه اصلی اشاره میکند. (در صورت نیاز آن را تغییر دهید)
- عبارت "Release_Artifacts" نام فایل Artifacts خروجی شماست که با این نام ذخیره میشود.
- مسیر "src\bin\Release" پوشه ای است که میخواهید محتوای آن را در Artifacts ذخیره کنید.
بعد از اتمام فرایند در صورت موفقیت آمیز بودن فرایند، فایل Artifacts را میتوانید از این قسمت دانلود کنید.
روش دیگری بجای استفاده از فایلهای bat
در انتهای بحث یک سری فایل bat معرفی شدند که کار اجرای دستورات مرتبط را سادهتر میکنند. روش دوم اجرای این نوع دستورات، استفاده از همان فایل package.json است. قسمت scripts آنرا به صورت ذیل تکمیل کنید:
سپس افزونهی NPM Task Runner را نیز نصب کنید.
اکنون اگر بر روی فایل package.json، در ویژوال استودیو کلیک راست کنید، گزینهی Task Runner Explorer اضافه شدهاست. با انتخاب آن امکانات ذیل ظاهر میشوند:
در اینجا با کلیک راست بر روی هر گزینه، امکان اجرای آن وجود خواهد داشت.
در انتهای بحث یک سری فایل bat معرفی شدند که کار اجرای دستورات مرتبط را سادهتر میکنند. روش دوم اجرای این نوع دستورات، استفاده از همان فایل package.json است. قسمت scripts آنرا به صورت ذیل تکمیل کنید:
"scripts": { "ng": "ng", "start": "ng serve", "build": "ng build", "test": "ng test", "lint": "ng lint", "e2e": "ng e2e", "_0-prerestore": "npm install", "_0-restore": "dotnet restore", "_1-ng-build-dev": "ng build --watch", "_1-ng-build-prod": "ng build --prod --watch", "_2-dotnet-run": "dotnet watch run", "_2-ng-serve-proxy": "ng serve --proxy-config proxy.config.json -o" },
اکنون اگر بر روی فایل package.json، در ویژوال استودیو کلیک راست کنید، گزینهی Task Runner Explorer اضافه شدهاست. با انتخاب آن امکانات ذیل ظاهر میشوند:
در اینجا با کلیک راست بر روی هر گزینه، امکان اجرای آن وجود خواهد داشت.
یکی از مهمترین تغییرات ASP.NET Core 2.0، نسبت به نگارشهای قبلی آن، ارائهی یک «متا پکیج» جدید به نام Microsoft.AspNetCore.All است. این بسته به همراه تمام وابستگیهای مورد نیاز جهت توسعهی برنامههای ASP.NET Core 2.0 است؛ این «تمام» شامل تمام بستههای Razor، بستههای MVC، بستههای EF Core و غیره است. به این ترتیب به روز رسانی بستههای وابستهی به هم، بسیار ساده خواهد شد و همچنین به فایلهای csproj بسیار خلوت و قابل مدیریتی، خواهیم رسید.
بستهی Microsoft.AspNetCore.All فقط مخصوص پروژههای netcoreapp2.0 است
این «متا پکیج» تنها در پروژههایی که TargetFramework آنها به netcoreapp2.0 تنظیم شدهاست، قابل استفاده میباشد:
اگر TargetFramework تنظیمی netstandard2.0 باشد، قادر به استفادهی از آن نخواهید بود. در این حالت باید مانند سابق، تک تک بستههای مورد نیاز را در فایل csproj به صورت جداگانهای تعریف کنید.
نحوهی به روز رسانی پروژهها جهت استفادهی از Microsoft.AspNetCore.All
پیش از ناقص کردن برنامه و حذف بستههای نیوگتی که نباید از فایل csproj حذف شوند، ابتدا باید لیستی را که توسط «متا پکیج» Microsoft.AspNetCore.All ارائه میشود، بررسی کرد. این لیست را پس از نصب SDK جدید، در آدرس ذیل میتوانید مشاهده کنید:
روش دیگر یافتن این لیست، مراجعهی به سایت نیوگت و بررسی قسمت dependencies آدرس https://www.nuget.org/packages/Microsoft.AspNetCore.All است:
سپس به فایل csproj ایی که دارای TargetFramework مساوی netcoreapp2.0 است مراجعه کرده و هر کدام از بستههایی را که در این لیست قرار دارند ... حذف کنید. در آخر بجای تمام این مداخل حذف شده، یک مدخل کلی ذیل را تعریف کنید:
سؤال: آیا استفادهی از بستهی Microsoft.AspNetCore.All، ارائهی نهایی برنامه را حجیم نمیکند؟
اگر به مسیر dotnet\store ایی که پیشتر عنوان شد مراجعه کنید، در اینجا بیش از 180 بسته را خواهید یافت. در این حالت شاید به نظر برسد که حجم نهایی قابل توزیع برنامههای ASP.NET Core با استفاده از تک مدخل Microsoft.AspNetCore.All بسیار بالا خواهد رفت. اما ... خیر.
NET Core 2.0. به همراه ویژگی جدیدی است به نام Runtime store. هدف از آن، پیش نصب بستهها بر روی سیستم جاری، در یک مکان مرکزی است تا دیگر در حین توزیع نهایی برنامه، نیازی به توزیع مجدد آنها نباشد. به همین جهت، به آن میتوان شبیه به مفهوم پیشین Global assembly cache یا GAC مخصوص NET Core. نگاه کرد. به علاوه تمام این بستهها ngen شده و سرعت آغاز و اجرای برنامهها را بهبود میبخشند.
زمانیکه SDK جدید NET Core 2.0. را نصب میکنید، تمام بستههای مورد نیاز آن، در مسیر مرکزی C:\Program Files\dotnet\store نصب میشوند. بنابراین سیستمی که به همراه این SDK باشد، حتما حاوی تمام وابستگیهای ذکر شدهی در متاپکیج Microsoft.AspNetCore.All نیز خواهد بود و در این حالت نیازی به توزیع مجدد آنها نیست.
پس از آن مهمترین تفاوتی را که مشاهده خواهید کرد، کاهش حجم نهایی برنامههای ASP.NET Core 2.0 نسبت به نگارشهای 1x است. برای آزمایش، یک برنامهی ASP.NET Core 1.x و سپس یک برنامهی سادهی ASP.NET Core 2.x را publish کنید.
این تصویر، پوشهی نهایی قابل توزیع یک برنامهی ASP.NET Core 1.x را پس از publish نمایش میدهد:
بالا رفتن کارآیی تازه واردان به دنیای ASP.NET Core با متاپکیج جدید Microsoft.AspNetCore.All
یکی از مشکلاتی که به همراه کار با ASP.NET Core 1.x وجود دارد، مشخص نبودن محل قرارگیری ویژگیهای جدید و بستههای مرتبط با آنها است. همچنین به ازای هر ویژگی جدید باید یک بستهی نیوگت جدید را نصب کرد و عموما یافتن اینها و یا دانستن وجود آنها، کار دشواری میباشد.
اما زمانیکه متابستهی Microsoft.AspNetCore.All به قسمت ارجاعات پروژه اضافه میشود، در آغاز کار برنامه، سیستم IntelliSense آنها را پردازش کرده و بلافاصله در اختیار برنامه نویس قرار میگیرند. این قابلیت حتی در VSCode نیز همانند Visual Studio کار میکند و توسعه دهندهها بلافاصله IntelliSense بسیار کاملی را از قابلیتهای موجود در اختیار خواهند داشت؛ به همراه ویژگیهای تکمیلی دیگری مانند افزودن و یا اصلاح سادهتر فضاهای نام مرتبط.
بستهی Microsoft.AspNetCore.All فقط مخصوص پروژههای netcoreapp2.0 است
این «متا پکیج» تنها در پروژههایی که TargetFramework آنها به netcoreapp2.0 تنظیم شدهاست، قابل استفاده میباشد:
<TargetFramework>netcoreapp2.0</TargetFramework>
نحوهی به روز رسانی پروژهها جهت استفادهی از Microsoft.AspNetCore.All
پیش از ناقص کردن برنامه و حذف بستههای نیوگتی که نباید از فایل csproj حذف شوند، ابتدا باید لیستی را که توسط «متا پکیج» Microsoft.AspNetCore.All ارائه میشود، بررسی کرد. این لیست را پس از نصب SDK جدید، در آدرس ذیل میتوانید مشاهده کنید:
C:\Program Files\dotnet\store\x64\netcoreapp2.0
روش دیگر یافتن این لیست، مراجعهی به سایت نیوگت و بررسی قسمت dependencies آدرس https://www.nuget.org/packages/Microsoft.AspNetCore.All است:
سپس به فایل csproj ایی که دارای TargetFramework مساوی netcoreapp2.0 است مراجعه کرده و هر کدام از بستههایی را که در این لیست قرار دارند ... حذف کنید. در آخر بجای تمام این مداخل حذف شده، یک مدخل کلی ذیل را تعریف کنید:
<ItemGroup> <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> </ItemGroup>
سؤال: آیا استفادهی از بستهی Microsoft.AspNetCore.All، ارائهی نهایی برنامه را حجیم نمیکند؟
اگر به مسیر dotnet\store ایی که پیشتر عنوان شد مراجعه کنید، در اینجا بیش از 180 بسته را خواهید یافت. در این حالت شاید به نظر برسد که حجم نهایی قابل توزیع برنامههای ASP.NET Core با استفاده از تک مدخل Microsoft.AspNetCore.All بسیار بالا خواهد رفت. اما ... خیر.
NET Core 2.0. به همراه ویژگی جدیدی است به نام Runtime store. هدف از آن، پیش نصب بستهها بر روی سیستم جاری، در یک مکان مرکزی است تا دیگر در حین توزیع نهایی برنامه، نیازی به توزیع مجدد آنها نباشد. به همین جهت، به آن میتوان شبیه به مفهوم پیشین Global assembly cache یا GAC مخصوص NET Core. نگاه کرد. به علاوه تمام این بستهها ngen شده و سرعت آغاز و اجرای برنامهها را بهبود میبخشند.
زمانیکه SDK جدید NET Core 2.0. را نصب میکنید، تمام بستههای مورد نیاز آن، در مسیر مرکزی C:\Program Files\dotnet\store نصب میشوند. بنابراین سیستمی که به همراه این SDK باشد، حتما حاوی تمام وابستگیهای ذکر شدهی در متاپکیج Microsoft.AspNetCore.All نیز خواهد بود و در این حالت نیازی به توزیع مجدد آنها نیست.
پس از آن مهمترین تفاوتی را که مشاهده خواهید کرد، کاهش حجم نهایی برنامههای ASP.NET Core 2.0 نسبت به نگارشهای 1x است. برای آزمایش، یک برنامهی ASP.NET Core 1.x و سپس یک برنامهی سادهی ASP.NET Core 2.x را publish کنید.
این تصویر، پوشهی نهایی قابل توزیع یک برنامهی ASP.NET Core 1.x را پس از publish نمایش میدهد:
و این تصویر، پوشهی نهایی قابل توزیع یک برنامهی ASP.NET Core 2.x را پس از publish نمایش میدهد:
در این حالت پوشهی نهایی نگارش 1x شامل 94 آیتم و پوشهی نهایی نگارش 2x شامل 13 آیتم است. یعنی حجم نهایی را که باید ارائه داد، به شدت کاهش یافتهاست.
بالا رفتن کارآیی تازه واردان به دنیای ASP.NET Core با متاپکیج جدید Microsoft.AspNetCore.All
یکی از مشکلاتی که به همراه کار با ASP.NET Core 1.x وجود دارد، مشخص نبودن محل قرارگیری ویژگیهای جدید و بستههای مرتبط با آنها است. همچنین به ازای هر ویژگی جدید باید یک بستهی نیوگت جدید را نصب کرد و عموما یافتن اینها و یا دانستن وجود آنها، کار دشواری میباشد.
اما زمانیکه متابستهی Microsoft.AspNetCore.All به قسمت ارجاعات پروژه اضافه میشود، در آغاز کار برنامه، سیستم IntelliSense آنها را پردازش کرده و بلافاصله در اختیار برنامه نویس قرار میگیرند. این قابلیت حتی در VSCode نیز همانند Visual Studio کار میکند و توسعه دهندهها بلافاصله IntelliSense بسیار کاملی را از قابلیتهای موجود در اختیار خواهند داشت؛ به همراه ویژگیهای تکمیلی دیگری مانند افزودن و یا اصلاح سادهتر فضاهای نام مرتبط.
در مطلب «معرفی Reactive extensions» با نحوهی تبدیل IEnumerableها به نمونههای Observable آشنا شدیم. اما سایر حالات چطور؟ آیا Rx صرفا محدود است به کار با IEnumerableها؟ در ادامه نگاهی خواهیم داشت به نحوهی تبدیل بسیاری از منابع داده دیگر به توالیهای Observable قابل استفاده در Rx.
روشهای متفاوت ایجاد توالی (sequence) در Rx
الف) استفاده از متدهای Factory
1) Observable.Create
نمونهای از استفاده از آنرا در مطلب «معرفی Reactive extensions» مشاهده کردید.
کار آن، تدارک delegate ایی است که توسط متد Subscribe، به ازای هربار پردازش مقدار موجود در توالی معرفی شده به آن، فراخوانی میگردد و هدف اصلی از آن این است که به صورت دستی اینترفیس IObservable را پیاده سازی نکنید (امکان پیاده سازی inline یک اینترفیس توسط Actionها).
البته در این مثال فقط delegate مربوط به onNext را ملاحظه میکند. توسط سایر overloadهای آن امکان ذکر delegateهای OnError/OnCompleted نیز وجود دارد.
2) Observable.Return
برای ایجاد یک خروجی Observable از یک مقدار مشخص، میتوان از متد جنریک Observable.Return استفاده کرد. برای مثال:
در ادامه نحوهی پیاده سازی این متد را توسط Observable.Create مشاهده میکنید:
البته دو سطر نوشته شده در اصل معادل هستند با سطرهای ذیل؛ که ذکر نوع جنریک آنها ضروری نیست. زیرا به صورت خودکار از نوع آرگومان معرفی شده، تشخیص داده میشود:
3) Observable.Empty
برای بازگشت یک توالی خالی که تنها کار اطلاع رسانی onCompleted را انجام میدهد.
در کدهای ذیل، پیاده سازی این متد را توسط Observable.Create مشاهده میکنید:
4) Observable.Never
برای بازگشت یک توالی بدون قابلیت اطلاع رسانی و notification
این متد به نحو زیر توسط Observable.Create پیاده سازی شدهاست:
5) Observable.Throw
برای ایجاد یک توالی که صرفا کار اطلاع رسانی OnError را توسط استثنای معرفی شده به آن انجام میدهد.
در ادامه نحوهی پیاده سازی این متد را توسط Observable.Create مشاهده میکنید:
6) توسط Observable.Range
به سادگی میتوان بازهی Observable ایی را ایجاد کرد:
7) Observable.Generate
اگر بخواهیم عملیات Observable.Range را پیاده سازی کنیم، میتوان از متد Observable.Generate استفاده کرد:
توسط پارامتر initialState، مقدار آغازین را دریافت میکند. پارامتر condition، مشخص میکند که توالی چه زمانی باید خاتمه یابد. در پارامتر iterate، مقدار جاری دریافت شده و مقدار بعدی تولید میشود. resultSelector کار تبدیل و بازگشت مقدار خروجی را به عهده دارد.
8) Observable.Interval
عموما از انواع و اقسام تایمرهای موجود در دات نت مانند System.Timers.Timer ، System.Threading.Timer و System.Windows.Threading.DispatcherTimer برای ایجاد یک توالی از رخدادها استفاده میشود. تمام اینها را به سادگی میتوان توسط متد Observable.Interval، که قابل انتقال به تمام پلتفرمهایی است که Rx برای آنها تهیه شدهاست، جایگزین کرد:
در اینجا تایمر تهیه شده، هر 450 میلیثانیه یکبار اجرا میشود. برای خاتمهی آن باید شیء interval را Dispose کنید.
Overload دوم این متد، امکان معرفی scheduler و اجرای بر روی تردی دیگر را نیز میسر میکند.
9) Observable.Timer
تفاوت Observable.Timer با Observable.Interval در مفهوم پارامتر ارسالی به آنها است:
یکی due time دارد (مدت زمان صبر کردن تا تولید اولین خروجی) و دیگری period (به صورت متوالی تکرار میشود).
خروجی Observable.Interval مثال زده شده به نحو زیر است و خاتمهای ندارد:
0
1
2
3
4
5
اما خروجی Observable.Timer به نحو ذیل بوده و پس از یک ثانیه، خاتمه مییابد:
0
completed
متد Observable.Timer دارای هفت overload متفاوت است که توسط آنها dueTime (مدت زمان صبر کردن تا تولید اولین خروجی)، period (کار Observable.Timer را به صورت متوالی در بازهی زمانی مشخص شده تکرار میکند) و scheduler (تعیین ترد اجرایی عملیات) قابل مقدار دهی هستند.
اگر میخواهید Observable.Timer بلافاصله شروع به کار کند، مقدار dueTime آنرا مساوی TimeSpan.Zero قرار دهید. به این ترتیب یک Observable.Interval را به وجود آوردهاید که بلافاصله شروع به کار کرده است و تا مدت زمان مشخص شدهای جهت اجرای اولین callback خود صبر نمیکند.
ب) تبدیلگرهایی که خروجی IObservable ایجاد میکنند
برای تبدیل مدلهای برنامه نویسی Async قدیمی دات نت مانند APM، رخدادها و امثال آن به معادلهای Rx، متدهای الحاقی خاصی تهیه شدهاند.
1) تبدیل delegates به معادل Observable
متد Observable.Start، امکان تبدیل یک Func یا Action زمانبر را به یک توالی observable میسر میکند. در این حالت به صورت پیش فرض، پردازش عملیات بر روی یکی از تردهای ThreadPool انجام میشود.
در اینجا دو مثال از بکارگیری Action و Funcها را توسط Observable.Start مشاهده میکنید.
زمانیکه از Func استفاده میشود، تابع یک خروجی را ارائه داده و سپس توالی خاتمه مییابد. اگر از Action استفاده شود، نوع Observable بازگشت داده شده از نوع Unit است که در برنامه نویسی functional معادل void است و هدف از آن مشخص سازی پایان عملیات Action میباشد. Unit دارای مقداری نبوده و صرفا سبب اجرای اطلاع رسانی OnNext میشود.
تفاوت مهم Observable.Start و Observable.Return در این است که Observable.Start مقدار تابع را به صورت تنبل (lazily) پردازش میکند، اما Observable.Return پردازش حریصانهای (eagrly) را به همراه خواهد داشت. به این ترتیب Observable.Start بسیار شبیه به یک Task (پردازشهای غیرهمزمان) عمل میکند.
در اینجا شاید این سؤال مطرح شود که استفاده از قابلیتهای Async سیشارپ 5 برای اینگونه کارها مناسب است یا Rx؟ قابلیتهای Async بیشتر به اعمال مخصوص IO bound مانند کار با شبکه، دریافت فایل از اینترنت، کار با یک بانک اطلاعاتی خارج از مرزهای سیستم، مرتبط میشوند؛ اما اعمال CPU bound مانند محاسبات سنگین حاصل از توالیهای observable را به خوبی میتوان توسط Rx مدیریت کرد.
2) تبدیل Events به معادل Observable
دات نت از روزهای اول خود به همراه یک event driven programming model بودهاست. Rx متدهایی را برای دریافت یک رخداد و تبدیل آن به یک توالی Observable ارائه دادهاست. برای نمونه ObservableCollection زیر را درنظر بگیرید
اگر بخواهیم مانند روشهای متداول، حذف شدن آیتمهای آنرا تحت نظر قرار دهیم، میتوان نوشت:
این نوع کدها در WPF زیاد کاربرد دارند. اکنون معادل کدهای فوق با Rx به صورت زیر هستند:
با استفاده از متد Observable.FromEventPattern میتوان معادل Observable رخداد CollectionChanged را تهیه کرد. پارامتر اول جنریک آن، نوع رخداد است و پارامتر اختیاری دوم آن، EventArgs این رخداد. همچنین با توجه به قسمت Where نوشته شده، در این بین مواردی را که Action مساوی حذف شدن را دارا هستند، فیلتر کرده و نهایتا لیست Observable آنها بازگشت داده میشوند. اکنون میتوان با استفاده از متد Subscribe، این تغییرات را دریافت کرد. برای مثال با فراخوانی
بلافاصله خروجی Removed item1 ظاهر میشود.
3) تبدیل Task به معادل Observable
متد ToObservable واقع در فضای نام System.Reactive.Threading.Tasks را بر روی یک Task نیز میتوان فراخوانی کرد:
البته باید دقت داشت استفاده از Task دات نت 4.5 که بیشتر جهت پردازشهای async اعمال I/O-bound طراحی شدهاست، بر IObservable مقدم است. صرفا اگر نیاز است این Task را با سایر observables ادغام کنید از متد ToObservable برای کار با آن استفاده نمائید.
4) تبدیل IEnumerable به معادل Observable
با این مورد تاکنون آشنا شدهاید. فقط کافی است متد ToObservable را بر روی یک IEnumerable، جهت تهیه خروجی Observable فراخوانی کرد.
5) تبدیل APM به معادل Observable
APM یا Asynchronous programming model، همان روش کار با متدهای Async با نامهای BeginXXX و EndXXX است که از نگارشهای آغازین دات نت به همراه آن بودهاند. کار کردن با آن مشکل است و مدیریت آن به همراه پراکندگیهای بسیاری جهت کار با callbacks آن است. برای تبدیل این نوع روش برنامه نویسی به روش Rx نیز متدهایی پیش بینی شدهاست؛ مانند Observable.FromAsyncPattern.
یک نکته
کتابخانهای به نام Rxx بسیاری از این محصور کنندهها را تهیه کردهاست:
http://Rxx.codeplex.com
ابتدا بستهی نیوگت آنرا نصب کنید:
سپس برای نمونه، برای کار با یک فایل استریم خواهیم داشت:
متد ReadToEndObservable یکی از متدهای الحاقی کتابخانهی Rxx است.
روشهای متفاوت ایجاد توالی (sequence) در Rx
الف) استفاده از متدهای Factory
1) Observable.Create
نمونهای از استفاده از آنرا در مطلب «معرفی Reactive extensions» مشاهده کردید.
var query = Enumerable.Range(1, 5).Select(number => number); var observableQuery = query.ToObservable(); var observer = Observer.Create<int>(onNext: number => Console.WriteLine(number)); observableQuery.Subscribe(observer);
البته در این مثال فقط delegate مربوط به onNext را ملاحظه میکند. توسط سایر overloadهای آن امکان ذکر delegateهای OnError/OnCompleted نیز وجود دارد.
2) Observable.Return
برای ایجاد یک خروجی Observable از یک مقدار مشخص، میتوان از متد جنریک Observable.Return استفاده کرد. برای مثال:
var observableValue1 = Observable.Return("Value"); var observableValue2 = Observable.Return(2);
public static IObservable<T> Return<T>(T value) { return Observable.Create<T>(o => { o.OnNext(value); o.OnCompleted(); return Disposable.Empty; }); }
var observableValue1 = Observable.Return<string>("Value"); var observableValue2 = Observable.Return<int>(2);
3) Observable.Empty
برای بازگشت یک توالی خالی که تنها کار اطلاع رسانی onCompleted را انجام میدهد.
var emptyObservable = Observable.Empty<string>();
public static IObservable<T> Empty<T>() { return Observable.Create<T>(o => { o.OnCompleted(); return Disposable.Empty; }); }
4) Observable.Never
برای بازگشت یک توالی بدون قابلیت اطلاع رسانی و notification
var neverObservable = Observable.Never<string>();
public static IObservable<T> Never<T>() { return Observable.Create<T>(o => { return Disposable.Empty; }); }
5) Observable.Throw
برای ایجاد یک توالی که صرفا کار اطلاع رسانی OnError را توسط استثنای معرفی شده به آن انجام میدهد.
var throwObservable = Observable.Throw<string>(new Exception());
public static IObservable<T> Throws<T>(Exception exception) { return Observable.Create<T>(o => { o.OnError(exception); return Disposable.Empty; }); }
6) توسط Observable.Range
به سادگی میتوان بازهی Observable ایی را ایجاد کرد:
var range = Observable.Range(10, 15); range.Subscribe(Console.WriteLine, () => Console.WriteLine("Completed"));
7) Observable.Generate
اگر بخواهیم عملیات Observable.Range را پیاده سازی کنیم، میتوان از متد Observable.Generate استفاده کرد:
public static IObservable<int> Range(int start, int count) { var max = start + count; return Observable.Generate( initialState: start, condition: value => value < max, iterate: value => value + 1, resultSelector: value => value); }
8) Observable.Interval
عموما از انواع و اقسام تایمرهای موجود در دات نت مانند System.Timers.Timer ، System.Threading.Timer و System.Windows.Threading.DispatcherTimer برای ایجاد یک توالی از رخدادها استفاده میشود. تمام اینها را به سادگی میتوان توسط متد Observable.Interval، که قابل انتقال به تمام پلتفرمهایی است که Rx برای آنها تهیه شدهاست، جایگزین کرد:
var interval = Observable.Interval(period: TimeSpan.FromMilliseconds(250)); interval.Subscribe(Console.WriteLine, () => Console.WriteLine("completed"));
Overload دوم این متد، امکان معرفی scheduler و اجرای بر روی تردی دیگر را نیز میسر میکند.
9) Observable.Timer
تفاوت Observable.Timer با Observable.Interval در مفهوم پارامتر ارسالی به آنها است:
var timer = Observable.Timer(dueTime: TimeSpan.FromSeconds(1)); timer.Subscribe(Console.WriteLine, () => Console.WriteLine("completed"));
خروجی Observable.Interval مثال زده شده به نحو زیر است و خاتمهای ندارد:
0
1
2
3
4
5
اما خروجی Observable.Timer به نحو ذیل بوده و پس از یک ثانیه، خاتمه مییابد:
0
completed
متد Observable.Timer دارای هفت overload متفاوت است که توسط آنها dueTime (مدت زمان صبر کردن تا تولید اولین خروجی)، period (کار Observable.Timer را به صورت متوالی در بازهی زمانی مشخص شده تکرار میکند) و scheduler (تعیین ترد اجرایی عملیات) قابل مقدار دهی هستند.
اگر میخواهید Observable.Timer بلافاصله شروع به کار کند، مقدار dueTime آنرا مساوی TimeSpan.Zero قرار دهید. به این ترتیب یک Observable.Interval را به وجود آوردهاید که بلافاصله شروع به کار کرده است و تا مدت زمان مشخص شدهای جهت اجرای اولین callback خود صبر نمیکند.
ب) تبدیلگرهایی که خروجی IObservable ایجاد میکنند
برای تبدیل مدلهای برنامه نویسی Async قدیمی دات نت مانند APM، رخدادها و امثال آن به معادلهای Rx، متدهای الحاقی خاصی تهیه شدهاند.
1) تبدیل delegates به معادل Observable
متد Observable.Start، امکان تبدیل یک Func یا Action زمانبر را به یک توالی observable میسر میکند. در این حالت به صورت پیش فرض، پردازش عملیات بر روی یکی از تردهای ThreadPool انجام میشود.
static void StartAction() { var start = Observable.Start(() => { Console.Write("Observable.Start"); for (int i = 0; i < 10; i++) { Thread.Sleep(100); Console.Write("."); } }); start.Subscribe( onNext: unit => Console.WriteLine("published"), onCompleted: () => Console.WriteLine("completed")); } static void StartFunc() { var start = Observable.Start(() => { Console.Write("Observable.Start"); for (int i = 0; i < 10; i++) { Thread.Sleep(100); Console.Write("."); } return "value"; }); start.Subscribe( onNext: Console.WriteLine, onCompleted: () => Console.WriteLine("completed")); }
زمانیکه از Func استفاده میشود، تابع یک خروجی را ارائه داده و سپس توالی خاتمه مییابد. اگر از Action استفاده شود، نوع Observable بازگشت داده شده از نوع Unit است که در برنامه نویسی functional معادل void است و هدف از آن مشخص سازی پایان عملیات Action میباشد. Unit دارای مقداری نبوده و صرفا سبب اجرای اطلاع رسانی OnNext میشود.
تفاوت مهم Observable.Start و Observable.Return در این است که Observable.Start مقدار تابع را به صورت تنبل (lazily) پردازش میکند، اما Observable.Return پردازش حریصانهای (eagrly) را به همراه خواهد داشت. به این ترتیب Observable.Start بسیار شبیه به یک Task (پردازشهای غیرهمزمان) عمل میکند.
در اینجا شاید این سؤال مطرح شود که استفاده از قابلیتهای Async سیشارپ 5 برای اینگونه کارها مناسب است یا Rx؟ قابلیتهای Async بیشتر به اعمال مخصوص IO bound مانند کار با شبکه، دریافت فایل از اینترنت، کار با یک بانک اطلاعاتی خارج از مرزهای سیستم، مرتبط میشوند؛ اما اعمال CPU bound مانند محاسبات سنگین حاصل از توالیهای observable را به خوبی میتوان توسط Rx مدیریت کرد.
2) تبدیل Events به معادل Observable
دات نت از روزهای اول خود به همراه یک event driven programming model بودهاست. Rx متدهایی را برای دریافت یک رخداد و تبدیل آن به یک توالی Observable ارائه دادهاست. برای نمونه ObservableCollection زیر را درنظر بگیرید
var items = new System.Collections.ObjectModel.ObservableCollection<string> { "Item1", "Item2", "Item3" };
items.CollectionChanged += (sender, ea) => { if (ea.Action == NotifyCollectionChangedAction.Remove) { foreach (var oldItem in ea.OldItems.Cast<string>()) { Console.WriteLine("Removed {0}", oldItem); } } };
var removals = Observable.FromEventPattern<NotifyCollectionChangedEventHandler, NotifyCollectionChangedEventArgs> ( addHandler: handler => items.CollectionChanged += handler, removeHandler: handler => items.CollectionChanged -= handler ) .Where(e => e.EventArgs.Action == NotifyCollectionChangedAction.Remove) .SelectMany(c => c.EventArgs.OldItems.Cast<string>()); var disposable = removals.Subscribe(onNext: item => Console.WriteLine("Removed {0}", item));
items.Remove("Item1");
3) تبدیل Task به معادل Observable
متد ToObservable واقع در فضای نام System.Reactive.Threading.Tasks را بر روی یک Task نیز میتوان فراخوانی کرد:
var task = Task.Factory.StartNew(() => "Test"); var source = task.ToObservable(); source.Subscribe(Console.WriteLine, () => Console.WriteLine("completed"));
4) تبدیل IEnumerable به معادل Observable
با این مورد تاکنون آشنا شدهاید. فقط کافی است متد ToObservable را بر روی یک IEnumerable، جهت تهیه خروجی Observable فراخوانی کرد.
5) تبدیل APM به معادل Observable
APM یا Asynchronous programming model، همان روش کار با متدهای Async با نامهای BeginXXX و EndXXX است که از نگارشهای آغازین دات نت به همراه آن بودهاند. کار کردن با آن مشکل است و مدیریت آن به همراه پراکندگیهای بسیاری جهت کار با callbacks آن است. برای تبدیل این نوع روش برنامه نویسی به روش Rx نیز متدهایی پیش بینی شدهاست؛ مانند Observable.FromAsyncPattern.
یک نکته
کتابخانهای به نام Rxx بسیاری از این محصور کنندهها را تهیه کردهاست:
http://Rxx.codeplex.com
ابتدا بستهی نیوگت آنرا نصب کنید:
PM> Install-Package Rxx
using (new FileStream("file.txt", FileMode.Open) .ReadToEndObservable() .Subscribe(x => Console.WriteLine(x.Length))) { Console.ReadKey(); }
نظرات مطالب
Minimal API's در دات نت 6 - قسمت اول - معرفی
اگر میخواهید از طریق خط فرمان (غیر ویندوزی) پروژه سری جاری را ایجاد و دستورات آن را اجرا کنید:
mkdir MinimalAPI && cd "$_" dotnet new sln --name MinimalAPI mkdir src && cd "$_" dotnet new classlib --name MinimalBlog.Dal dotnet new classlib --name MinimalBlog.Domain dotnet new console --name MinimalBlog.Api cd .. dotnet sln add src/MinimalBlog.Dal dotnet sln add src/MinimalBlog.Domain dotnet sln add src/MinimalBlog.Api dotnet sln list Project(s) ---------- src/MinimalBlog.Api/MinimalBlog.Api.csproj src/MinimalBlog.Dal/MinimalBlog.Dal.csproj src/MinimalBlog.Domain/MinimalBlog.Domain.csproj cd src/MinimalBlog.Dal dotnet add reference ../MinimalBlog.Domain/ dotnet add package Microsoft.EntityFrameworkCore dotnet add package Microsoft.EntityFrameworkCore.SqlServer dotnet add package Microsoft.EntityFrameworkCore.Tools cd .. cd MinimalBlog.Api dotnet add reference ../MinimalBlog.Dal/ dotnet add reference ../MinimalBlog.Domain/ dotnet build dotnet tool update --global dotnet-ef dotnet build cd MinimalBlog.Dal dotnet ef migrations add $(date +%s) --startup-project ../MinimalBlog.Api --context MinimalBlogDbContext dotnet ef --startup-project ../MinimalBlog.Api/ database update --context MinimalBlogDbContext