Quantcast
Channel: ‫فید مطالب .NET Tips
Viewing all 1980 articles
Browse latest View live

‫بازسازی کد: جایگزینی آرایه با شیء (Replace array with object)

$
0
0
از آرایه برای ذخیره سازی آیتم‌های مشابه استفاده می‌شود. این تشابه باید علاوه بر اینکه در نوع داده‌ای آیتم‌ها رعایت شود، باید از نظر مفهومی نیز رعایت شود.
زمانیکه از یک آرایه برای نگهداری المنت‌های غیر مشابه استفاده می‌شود، نیاز به چنین بازسازی کدی است. به طور مثال آرایه‌ای که آیتم اول آن "نام" و آیتم دوم آن "امتیاز" است. قطعا کار با چنین آرایه‌ای بسیار مشکل خواهد بود. زمانیکه یک آرایه را از نوع داده‌ای عمومی‌تری (مثلا object در سی شارپ) تعریف و انواع داده‌ای متفاوت را در آیتم‌های آن نگهداری کنیم، اوضاع بسیار بدتر خواهد شد. 
محور اصلی بازسازی کد "جایگزینی آرایه با شیء" ایجاد یک کلاس، برای ذخیره اطلاعات آرایه است. به این صورت که برای هر آیتم آرایه، یک خصوصیت در کلاس مربوطه ایجاد می‌شود. 
به طور مثال به آرایه زیر توجه نمایید:
var row = new string[3]; 
row[0] = "Liverpool"; 
row[0] = "15";
در آرایه بالا، آیتم اول نشان دهنده نام تیم و آیتم دوم نشان دهنده امتیاز تیم است. با وجود اینکه این مثال کمی غیر واقعی به نظر میرسد، اما چنین مثال‌هایی در برنامه نویسی روزمره ممکن است به اشکال مختلفی مشاهده شود. مانند استفاده از dictionary برای دریافت اطلاعات فرم وب، استفاده از Tuple (در زبان سی شارپ) برای انتقال اطلاعات و … 
در این مثال طراحی بهتر، ایجاد یک کلاس یا ساختار (بسته به شرایط کلی مسئله) برای نشان دادن امتیاز تیم است:  
public class Performance 
{ 
       public string TeamName { get; set; } 
       public int Score { get; set; } 
}
همانطور که مشاهده می‌کنید، به ازای هر یک از آیتم‌های آرایه، خصوصیتی در کلاس جدید ایجاد شده‌است. همچنین انتخاب انواع داده‌ای نیز در طراحی جدید، ساده‌تر و اصولی‌تر انجام خواهد شد.
تمامی استفاده‌ها از آرایه‌ها، در دسته بندی این نوشتار برای بازسازی کد قرار نمی‌گیرند. آرایه‌هایی که اصل مشابه بودن آیتم‌ها را رعایت می‌کنند، معمولا نیازی به بازسازی کد ندارند. به طور مثال در نرم افزارهای فروشگاه اینترنتی، خصوصیات کالا به صورت داینامیک ذخیره شده و احتمالا برای دسترسی و مدیریت آن، از آرایه یا لیست استفاده می‌شود. اما با کمی دقت خواهیم دید، این استفاده از آرایه، با تعریف مشابه بودن آیتم‌ها همخوانی دارد. زیرا تمامی آیتم‌های آرایه به طور مثال از نوع خصوصیت کالا هستند. همچنین عملا امکان بازسازی و ایجاد کلاس در این مثال وجود ندارد؛ زیرا خصوصیات کالاها در زمان توسعه مشخص نیستند و در زمان اجرای برنامه تنظیم می‌شوند. 

‫کاهش حجم قابل ملاحظه‌ی برنامه‌های Angular با استفاده از RxJS 5.5

$
0
0
Angular 5.x به همراه پشتیبانی از RxJS 5.5.x منتشر شده‌است. RxJS 5.5 نیز به همراه تغییر قابل ملاحظه‌ای در نحوه‌ی import اجزای آن توسط ویژگی جدید lettable operators است. در این مطلب نحوه‌ی ارتقاء برنامه‌های قبلی به این نگارش جدید و همچنین اثر آن‌را بر اندازه‌ی برنامه‌ی نهایی تولید شده، بررسی می‌کنیم.


روش جدید import اجزای RxJS در نگارش 5.5 آن

تغییرات تعاریف عملگرها:
تا پیش از Angular 5 و RxJS 5.5 (و یا Angular CLI versions <1.5.0)، اگر نیاز به عملگری (operator/function) مانند map وجود داشت، روش import آن به صورت زیر بود:
import 'rxjs/add/operator/map';
اما پس از RxJS 5.5 امکان import آن‌ها با روش مخصوص ES 6میسر شده‌است (به نام جمع operators دقت داشته باشید؛ چون مسیر rxjs/observable نیز وجود دارد):
import { map } from 'rxjs/operators';
بنابراین در این حالت دیگر روش import یکجای این تعاریف در فایلی مانند «rxjs-operators.ts» وجود ندارد و این تعاریف باید به ازای هر فایلی که از آن‌ها استفاده می‌کنند، مانند سایر importهای ES 6 یکبار دیگر مجددا ذکر شوند؛ مانند:
import { map, catchError, tap } from 'rxjs/operators';
در حالت کلی مسیر node_modules/rxjs/operators را برای یافتن متدهای جدید بررسی کنید.

همچنین در این نگارش، Observable بجای rxjs/Rx :
import { Observable } from 'rxjs/Rx';
از rxjs/Observable دریافت می‌شود:
import { Observable } from 'rxjs/Observable';
تا بتوان از قابلیت‌های جدید آن استفاده کرد.

تغییرات تعاریف statics:
برای صدور خطاها بجای throw قبلی:
import 'rxjs/add/observable/throw';

Observable.throw('error');
خواهیم داشت:
import { ErrorObservable } from 'rxjs/observable/ErrorObservable';

ErrorObservable.create('error');

و برای ایجاد تایمر، بجای timer پیشین:
import "rxjs/add/observable/timer";

const timerSource$ = Observable.timer(initialDelay);
خواهیم داشت:
import { timer } from 'rxjs/observable/timer';  

const timerSource$ = timer(initialDelay);
و به طور کلی مسیر node_modules\rxjs\observable را برای یافتن تعاریف static قبلی جستجو کنید.


معرفی lettable operators

Lettable Operatorsتوابعی هستند که یک observable را دریافت و یک observable را بازگشت می‌دهند؛ به آن‌ها pipeable operators هم می‌گویند. از این جهت که در اینجا متد جدید pipe، برای ترکیب چندین تابع عملگر بر روی مقادیر observable توسط آن، ارائه شده‌است.
مزیت این روش این است که pipeable/lettable operators، یک سری تابع محض هستند و اگر مورد استفاده قرار نگیرند، به سادگی توسط سیستم و ابزار ساخت برنامه، از فایل نهایی حذف خواهند شد؛ یا اصطلاحا tree-shakable هست. اما روش پیشین تعریف این عملگرها، tree-shakable نبوده و حتی اگر توسط برنامه مورد استفاده قرار نگیرند، در بسته‌ی نهایی تولید شده، حضور خواهند داشت. Tree-shaking به معنای پروسه‌ی حذف کدهای مرده است. روش جدید استفاده‌ی از importهای ES 6، امکان تشخیص عملگرهای استفاده نشده را توسط ابزارهایی مانند TS-Lint و تنظیمات کامپایلر TypeScriptبه سادگی میسر می‌کنند و به این ترتیب با حذف متدها و ماژول‌های استفاده نشده، می‌توان به حجم نهایی بسیار کمتری رسید.


روش قبلی تعریف عملگرهای Observable، اصطلاحا Patching نامیده می‌شود. به این معنا که هر متد جدید import شده‌ی در برنامه، به Observable.prototype اصلی اضافه و وصله می‌شود. اما در این روش جدید، تنها متد وصله شده‌ی از پیش موجود، Observable.prototype.pipe است و تمام متدهای دیگر import شده، توابع محض هستند و نه وصله‌ای به Observable.prototype اصلی. زمانیکه وصله‌ای به Observable.prototype متصل می‌شود، دیگر امکان حذف آن توسط ابزارهای ساخت برنامه وجود ندارد (حتی اگر استفاده نشده باشند)؛ اما اگر این متدها به صورت خالص و مجزای از Observable.prototype ارائه شوند، امکان حذف کدهای مرده و استفاده نشده، به سادگی میسر خواهد شد؛ چون توابعی خالص و متکی به خود هستند.

یک نمونه مثال استفاده‌ی از pipeable/lettable operators را در کد زیر مشاهده می‌کنید:
import { from} from 'rxjs/observable/from';
import { map, scan, filter } from 'rxjs/operators';

const source$ = range(1,10);

const sumOfSquaredOddNumbers$ = source$.pipe(
   filter(n => n % 2 !== 0), 
   map(n => n * n),
   scan((acc,s) => acc + s, 0)
);
sumOfSquaredOddNumbers$.subscribe(v => console.log(v));

/*** Output ****/ 
1
10
35
84
165
این مثال، جمع به توان 2 اعداد را در یک بازه‌ی مشخص، محاسبه می‌کند. برای این منظور ابتدا یک منبع Observable توسط متد range ایجاد شده‌است.
در اینجا روش تعریف Observableها نیز تغییر کرده‌است و از متد of جهت کار با تعدادی ورودی مشخص و یا متد range برای کار با بازه‌ای از اعداد، استفاده می‌شود:
import { of } from 'rxjs/observable/of';
import { from } from 'rxjs/observable/from';
import { range } from 'rxjs/observable/range';

const source$ = of(1,2,3);
const rangeSource$ = range(0,5);
سپس توسط متد pipe، ترکیبی از متدهای RxJS را مشاهده می‌کند که بر روی منبع Observable اصلی کار می‌کنند.
متد filter، اعداد فرد بازه را انتخاب می‌کند. متد map این اعداد انتخابی را به توان 2 می‌رساند و سپس متد scan آن‌ها را با هم جمع می‌زند و نتیجه توسط متد pipe به صورت یک Observable دیگر بازگشت داده می‌شود که می‌توان مشترک آن شد و برای مثال خروجی فوق را در console درج کرد.


تغییر نام عملگرهای قبلی RxJS

تا اینجا دریافتیم که هدف اصلی pipeable/lettable operators، عدم معرفی آن‌ها به صورت یک وصله‌ی جدید جدانشدنی از Observable.prototype، به صورت توابع خالص است. اکنون که این عملگرها، تبدیل به متدهای خالص و متکی به خود شده‌اند، نباید با متدهای اصلی جاوا اسکریپت تداخل نام پیدا کنند؛ به همین جهت برای ارتقاء کدهای قدیمی خود، به این تغییر نام‌ها نیاز خواهید داشت: متد do به tap تغییر نام یافته‌است. متد switch شده‌است switchAll. بجای catch اینبار catchError داریم و finally شده‌است finalize.


مثالی از ارتقاء کدهای قدیمی به روش جدید RxJS 5.5

اگر مثال روش قدیمی مبتنی بر وصله کردن Observable.prototype، به صورت زیر باشد:
import { Observable } from 'rxjs/Observable';
import 'rxjs/add/operator/map';
import 'rxjs/add/operator/filter';

names = allUserData.
         map(user => user.name).
         filter(name => name);
معادل جدید آن به این صورت تغییر می‌کند:
import { Observable } from 'rxjs/Observable';
import { map, filter } from 'rxjs/operators';

names = allUserData.pipe(
   map(user => user.name),
   filter(name => name),
);
زمانیکه تعریف Observable از مسیر rxjs/Observable درخواست می‌شود، به همراه عملگر وصله شده‌ی pipe نیز هست. به همین جهت نیازی به تعریف مجدد آن نیست. پس از آن متدهای map و filter، به داخل pipe منتقل می‌شوند. در این بین نیاز است تغییر نام متدها را که پیشتر نیز ذکر شد، مدنظر داشته باشید.
به عنوان یک مثال تکمیلی، کدهای سری «احراز هویت و اعتبارسنجی کاربران در برنامه‌های Angular» جهت استفاده‌ی از pipeable/lettable operators به روز رسانی شده‌اند. لیست تغییرات آن‌ها را در اینجامی‌توانید مشاهده کنید.

‫مقدمه ای بر Docker، قسمت پنجم

$
0
0
  در قسمت‌های قبلبا کلیات مفاهیم داکر آشنا شدیم. اما بنا داریم در این قسمت با اصول اولیه‌ی تهیه‌ی docker-compose آشنا شده و دستورالعمل اجرای کانتینر‌های مختلف را درون یک فایل نوشته و مدیریت نماییم. در واقع، compose ابزاری است برای تعریف و اجرای اپلیکیشن‌های multi-container.
با استفاده از YAML، دستورالعمل‌های سرویس‌های مختلف را نوشته و با یک دستور همه‌ی آنها را با هم اجرا مینماییم. از compose در تمامی مراحل production, staging, development, testing و همچنین CI workflow استفاده میشود.

برای استفاده از compose سه عمل زیر باید انجام شود:
1- ساخت  و تعریف dockerfile برای هر سرویس.
2- ساخت و تعریف docker-compose.yml. بنابراین هر سرویس میتواند در محیط ایزوله‌ی خود اجرا شود.
3- اجرای دستور docker-compose up.

در قسمت‌های قبلی مراحل ساخت و اجرای image‌ها درون کانتینر و همچنین متصل کردن آن‌ها را به شبکه، بررسی کرده ایم؛ اما در این قسمت میخواهیم با استفاده از docker-compose مدیریت build و اجرای همه‌ی image‌ها را بر عهده بگیریم.
عملا با این ساختار، قابلیت ایجاد شبکه، volume و غیره را خواهیم داشت. بنابراین با استفاده از این config توانایی توزیع برنامه را فقط با یک فایل YAML، خواهیم داشت.


ایجاد پروژه:

فرض کنید نرم افزار ما از دو سرویس Nodejsی همچنین یک دیتابیس Mongo تشکیل شده است. در نهایت باید به چیزی شبیه به تصویر زیر برسیم:


دایرکتوری root این پروژه از دو پوشه به نام‌های nodeapp1 و nodeapp2 تشکیل شده است که داخل هر کدام یک فایل index.js و همچنین package.json و dockerfile وجود دارد؛ همانند مطالب پیشین.
اما چیزی که اینجا اضافه شده است، فایل docker-compose.yml جهت مدیریت و اجرای این برنامه میباشد که حاوی ساختار زیر است:
version: '3'
networks:
  shared-network:
services:
  nodeapp1:
    image: nodeapp1
    build:
      context: nodeapp1
      dockerfile: dockerfile
    ports:
     - "8181:80"
    networks:
     - shared-network
  nodeapp2:
    image: nodeapp2
    build:
      context: nodeapp2
      dockerfile: dockerfile
    ports:
     - "8182:80"
    networks:
     - shared-network
  mongo:
    image: mongo
    ports:
      - "27017:27017"
    networks:
      - shared-network
1) ابتدا یک شبکه از نوع bridge را به نام shared-network میسازیم.
2) برای مشخص کردن سرویس‌های این برنامه از services استفاده کرده و آن‌ها را تعریف مینماییم.
3) سرویس nodeapp1 که قرار است تصویری به نام nodeapp1 را ایجاد کند (هدف آن build کردن اولین سرویس میباشد. همانطور که مشخص است context برنامه، اسم پوشه‌ی nodeapp1 درون ریشه‌ی پروژه است. ضمن اینکه نام dockerfile را هم درون آن پوشه بدان اضافه کرده‌ایم).
4) پورت 8181 را بر روی پورت 80 درون این کانتینر هدایت می‌کنیم.
5) این سرویس، درون شبکه‌ی ایجاد شده‌ی shared-network قرار می‌گیرد.
5) سرویس nodeapp2 را هم به همین شکل اضافه می‌کنیم.
6) سرویس mongo قرار نیست هیچ کدی را build کند و هدف، فقط اجرای mongo درون شبکه‌ی shared-network است که بقیه سرویس‌ها بتوانند بدان وصل شوند.


برای ساخت و اجرا نیز در ریشه‌ی این پروژه، ترمینال خود را باز کرده و دستورات زیر را وارد مینماییم:
برای build کردن:
 docker-compose build
برای اجرا کردن:
 docker-compose up
برای حذف کردن:
 docker-compose down
برای stop کردن موقتی:
 docker-compose stop
برای start کردن مجدد:
 docker-compose start

و اگر بخواهیم بعد از build کردن، بصورت خودکار نیز اجرا شود، از دستور زیر استفاده میکنیم:
 docker-compose run --build

dockerfile هر دو سرویس نیز بصورت ساده همانند مطالب پیشین در نظر گرفته شده‌است:
FROM node
COPY . /var/www
WORKDIR /var/www
RUN npm i
EXPOSE 80
ENTRYPOINT node index

در صورتیکه بخواهیم نگاهی هم به کد‌های نوشته شده بیندازیم، نکته‌ی جالبی مد نظر قرار میگیرد؛ بطور مثال از آنجائیکه همه‌ی کانتینر‌های اجرا شده، درون یک شبکه هستند، برای فراخوانی سرویس‌های دیگر کافیست با نامشان صدا زده شوند. بطور مثال در nodeapp1 برای فراخوانی nodeapp2 به راحتی با نام صدا زده شده است و احتیاجی به فراخوانی با ip نیست. کدهای زیر مربوط به فایل index.js در سرویس nodeapp1 میباشند (بدلیل اینکه روی پورت 80 درون کانتینر قرار گرفته‌است، دیگر لازم به وارد نمودن پورت نبودیم؛ در غیر اینصورت بطور مثال باید درخواستی بصورت http://nodeapp2:5000 را ارسال مینمودیم):
const express = require('express');
const fetch = require('node-fetch');
const app = express();

app.get('/', async (req, res) => {
    let response = await fetch("http://nodeapp2/");
    text = await response.text();
    res.send(text);
})

app.listen(80, () => console.log(`listening on port 80!`))
 بعد از اجرا کردن docker-compose، به راحتی سرویس‌های ما از طریق پورت 8181 و 8182 قابلیت فراخوانی را دارند. 

نکته: override کردن compose‌ها نیز قابل انجام است. بدین معنا که شما یک نسخه برای build و استفاده در محیط development و نسخه‌های دیگری بطور مثال برای production خود تعریف مینمایید؛ مثلا روی پروداکشن، environment variables‌های متفاوتی را در نظر میگیرید. YAML زیر را مشاهده کنید:
 version: '3'

services:
nodeapp1:
  environment:
- PRODUCTION: 'true'
nodeapp2:
  environment:
- PRODUCTION: 'true'

فرض کنید که قرار است YAML فوق بر روی فایل قبلی، بازنویسی شود؛ با استفاده از دستور زیر:
 docker-compose -f docker-compose.yml -f docker-compose.prod.yml up

تمام کد‌های فوق از اینجا «node.rar» قابل دریافت میباشد.

‫فعالسازی امکانات Refactoring افزونه‌ی Roslynator در VSCode

$
0
0
یکی از قابلیت‌های افزونه‌ی C# for Visual Studio Codeپس از نگارش 1.10.0 آن، امکان بارگذاری افزونه‌های مخصوص Roslyn است که قابلیت‌های Refactoring را به همراه دارند؛ مانند افزونه‌ی معروف و جامع Roslynator. البته هنوز افزونه‌های Analyzers مبتنی بر Roslyn، با VSCode سازگاری ندارند که قرار است در نگارش‌های آتی افزوده شوند. در این مطلب، نحوه‌ی فعالسازی افزونه‌های Roslyn refactoring ثالث را بررسی خواهیم کرد.


فعالسازی قدم به قدم Roslyn refactoring افزونه‌ی Roslynator

الف) فایل VSIX آن‌را از اینجادریافت کنید و سپس پسوند آن‌را به zip تغییر دهید.
ب) این فایل zip را در پوشه‌ای مشخص باز کنید.
ج) پس از باز کردن این فایل zip، دو فایل Roslynator.VisualStudio.Core.dll و Roslynator.VisualStudio.dll آن‌را حذف کنید. این فایل‌ها مخصوص نگارش کامل ویژوال استودیو هستند و در صورت وجود، با سیستم بارگذاری افزونه‌های OmniSharp تداخل می‌کنند.
د) در آخر مسیر زیر را گشوده:
%USERPROFILE%/.omnisharp
و سپس فایل جدید omnisharp.json را با محتوای ذیل، در آن مسیر ایجاد کنید:
{
  "RoslynExtensionsOptions": {
    "LocationPaths": [
      "C:\\lib\\roslynator"
    ]
  }
}
که در اینجا مسیر ذکر شده، به پوشه‌ای اشاره می‌کند که فایل zip افزونه را در آنجا گشوده‌اید (به ذکر \\ هم دقت داشته باشید؛ تا فایل json نهایی، به درستی تشکیل شود).

اکنون اگر VSCode را اجرا کنید، شاهد افزوده شدن امکانات Refactoring مخصوص افزونه‌ی Roslynator به لیست Refactoring پیش‌فرض OmniSharp خواهید بود:



خودکار سازی دریافت، نصب و فعالسازی Roslyn refactoring افزونه‌ی Roslynator

مراحل فوق را می‌توان تبدیل به یک اسکریپت پاورشل کرد که با هر بار اجرای آن، به صورت خودکار کار دریافت و نصب این افزونه صورت گیرد:
Write-Host "Download, unzip and enable Roslynator for Visual Studio Code"

$name = "josefpihrt.Roslynator2017"
$url = "https://marketplace.visualstudio.com/items?itemName=$name"
$currentDir = $PSScriptRoot
$file = "$currentDir\Roslynator.zip"

$pattern = "<script class=`"vss-extension`" defer=`"defer`" type=`"application\/json`">(.*?)<\/script>"
$regex = [regex]"(?m)$pattern"
Write-Host "Grab the home page of the $name."
$dom = (New-Object Net.WebClient).DownloadString($url); 
if($dom -and $dom -match $pattern) 
{
    $matches = $regex.Match($dom)
    $jsonText = $matches[0].Groups[1]

    $json = ConvertFrom-Json $jsonText

    $version = $Json.versions[0].version # Parse the json in the page for the latest version number
    $parts = $name.Split(".")
    $publisher = $parts[0]
    $package = $parts[1]

    # Assemble the url for the vsix package
    $packageUrl = "https://marketplace.visualstudio.com/_apis/public/gallery/publishers/$publisher/vsextensions/$package/$version/vspackage"
    Write-Host "Download the vsix package: $packageUrl"
    (New-Object Net.WebClient).DownloadFile($packageUrl, $file)

    Write-Host "Using $currentDir as the current dir."
    Write-Host "Unzip $file."
    $shellApp = new-object -com shell.application 
    $zipFile = $shellApp.namespace($file) 
    $destination = $shellApp.namespace($currentDir) 
    $destination.Copyhere($zipFile.items(), 0x14)# overwrite and be silent

    Write-Host "Delete VS specific files. Otherwise they will interfere with the MEF services inside OmniSharp."
    Remove-Item "$currentDir\Roslynator.VisualStudio.Core.dll","$currentDir\Roslynator.VisualStudio.dll", "$currentDir\Roslynator.VisualStudio.pkgdef"

    $omnisharpJsonFilePath = "$env:USERPROFILE\.omnisharp\omnisharp.json";
    Write-Host "Create $omnisharpJsonFilePath file."
    $omnisharpJson = @" 
{{
  "RoslynExtensionsOptions": {{
    "LocationPaths": [
      "{0}"
    ]
  }}
}}
"@ -f $currentDir -Replace "\\","\\"
    $omnisharpJson | Out-File "$omnisharpJsonFilePath" -Confirm

    Write-Host "Done!"
}
else
{
    Write-Host "Failed to find the packageUrl!"
}
کدهای فوق را با نام فرضی update.ps1 ذخیره کنید (و یا از اینجا دریافت کنید: update.zip). سپس می‌توانید آن‌را با اجرای دستور update.ps1\.، اجرا کرده و به صورت خودکار شاهد این مراحل باشید:
PS D:\Prog\1396\RoslynatorVSCode> .\update.ps1
Download, unzip and enable Roslynator for Visual Studio Code
Grab the home page of the josefpihrt.Roslynator2017.
Download the vsix package: https://marketplace.visualstudio.com/_apis/public/gallery/publishers/josefpihrt/vsextensions/Roslynator2017/1.7.0/vspackage
Using D:\Prog\1396\RoslynatorVSCode as the current dir.
Unzip D:\Prog\1396\RoslynatorVSCode\Roslynator.zip.
Delete VS specific files. Otherwise they will interfere with the MEF services inside OmniSharp.
Create C:\Users\Vahid\.omnisharp\omnisharp.json file.

Confirm
Are you sure you want to perform this action?
Performing the operation "Output to File" on target "C:\Users\Vahid\.omnisharp\omnisharp.json".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):
Done!
ابتدا صفحه‌ی اصلی این افزونه دریافت می‌شود. سپس از داخل آن، پارامترهای مخصوص دانلود افزونه استخراج و آدرس دریافت نهایی آن تشکیل می‌شود.
در ادامه این افزونه دریافت شده و در پوشه‌ی جاری باز خواهد شد. سپس فایل omnisharp.json نیز به صورت خودکار تشکیل و مقدار دهی می‌شود.
اکنون اگر VSCode را اجرا کنید، همه چیز آماده بوده و امکانات این افزونه در دسترس خواهند بود.

‫Span در C# 7.2

$
0
0
C# 7.2 به همراه تعداد کوچکی از بهبودهای کامپایلر است و با Visual Studio 2017 نگارش 15.5 ارائه شده و روش فعالسازی آن با نگارش 7.1 آن یکی است (انتخاب گزینه‌ی «C# latest minor version (latest)» در تنظیمات پیشرفته‌ی Build خواص پروژه). همچنین اگر از VSCode استفاده می‌کنید، نگارش 1.14 افزونه‌ی #C آن، پشتیبانی کاملی را از C# 7.2 به همراه دارد؛ در اینجا، افزودن خاصیت <LangVersion>latest</LangVersion> به فایل csproj برنامه برای استفاده‌ی از آخرین نگارش کامپایلر نصب شده، کفایت می‌کند.


نوع‌های جدید <Span<T و  <ReadOnlySpan<T در C# 7.2

نوع‌های جدید <Span<T و <ReadOnlySpan<T جهت ارائه‌ی ناحیه‌های اختیاری پیوسته‌ای از حافظه، شبیه به آرایه‌ها تدارک دیده شده‌اند و هدف استفاده‌ی از آن‌ها، تولید برنامه‌های سمت سرور با کارآیی بالا است.
برای کار با این نوع‌ها، هم نیاز به کامپایلر C# 7.2 است و هم نصب بسته‌ی نیوگت System.Memory:
<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>netcoreapp2.0</TargetFramework><LangVersion>latest</LangVersion></PropertyGroup><ItemGroup><PackageReference Include="System.Memory" Version="4.4.0-preview1-25305-02" /></ItemGroup></Project>
این بسته از .NETStandard 1.0. به بعد را پشتیبانی می‌کند؛ یعنی با +NET 4.5+ ،Mono 4.6.  و +NET Core 1.0. سازگار است.


Spanها و امکان دسترسی به انواع حافظه

Spanها می‌توانند به حافظه‌ی مدیریت شده، حافظه‌ی بومی (native) و حافظه‌ی اختصاص داده شده‌ی در Stack اشاره کنند. به عبارتی Spanها یک لایه انتزاعی، برفراز تمام انواع و اقسام حافظه‌هایی هستند که می‌توانند در اختیار توسعه دهندگان NET. باشند.
- البته اکثر توسعه دهندگان دات نت از حافظه‌ی مدیریت شده استفاده می‌کنند. برای مثال Stack memory تنها از طریق کدهای unsafe و واژه‌ی کلیدی stackalloc قابل تخصیص است. این نوع حافظه بسیار سریع است و همچنین بسیار کوچک؛ کمتر از یک مگابایت که به خوبی در CPU cache جا می‌شود. اما اگر در این بین حجم حافظه‌ی تخصیصی بیشتر از یک مگابایت شود، بلافاصله استثنای StackOverflowException غیرقابل مدیریتی را به همراه خاتمه‌ی فوری برنامه به همراه خواهد داشت. برای نمونه از این نوع حافظه در جهت مدیریت رخ‌دادهای داخلی corefx زیاد استفاده می‌شود.
- حافظه‌ی مدیریت شده، همان حافظه‌ای است که توسط واژه‌ی کلیدی new در برنامه، جهت ایجاد اشیاء، تخصیص داده می‌شود و طول عمر آن تحت مدیریت GC است.
- حافظه‌ی مدیریت نشده یا بومی از دید GC مخفی است و توسط متدهایی مانند Marshal.AllocHGlobal و Marshal.AllocCoTaskMem در اختیار برنامه قرار می‌گیرند. این حافظه باید به صورت صریحی توسط توسعه دهنده به کمک متدهایی مانند Marshal.FreeHGlobal و Marshal.FreeCoTaskMem آزاد شود. وب سرور Kestrel مخصوص ASP.NET Core، از این روش جهت کار با آرایه‌های حجیم، جهت کاهش بار GC استفاده می‌کند.

مزیت کار با Spanها این است که دسترسی امن و type safeایی را به انواع حافظه‌های مهیا، جهت توسعه دهندگانی که عموما کدهای unsafe ایی را نمی‌نویسند و با اشاره‌گرها به صورت مستقیم کار نمی‌کنند، میسر می‌کند. برای مثال تا پیش از معرفی Spanها، برای دسترسی به 1000 عنصر یک آرایه‌ی 10 هزار عنصری و ارسال آن به یک متد، نیاز بود تا ابتدا یک کپی از این 1000 عنصر را تهیه کرد. این عملیات از لحاظ میزان مصرف حافظه و همچنین زمان انجام آن، بسیار هزینه‌بر است. با استفاده از <Span<T می‌توان یک دید مجازی از آن آرایه را بدون اختصاص آرایه‌ای و یا آرایه‌هایی جدید، ارائه کرد.


مثالی از کاربرد Spanها جهت کاهش تعداد بار تخصیص‌های حافظه

برای نمونه، متد IsValidName زیر، بررسی می‌کند که طول رشته‌ی دریافتی حداقل 2 باشد و حتما با یک حرف شروع شده باشد:
    static class NameValidatorUsingString
    {
        public static bool IsValidName(string name)
        {
            if (name.Length < 3)
                return false;

            if (char.IsLetter(name[0]))
                return true;

            return false;
        }
    }
در این حالت یک نمونه مثال از استفاده‌ی آن می‌تواند به صورت زیر باشد:
string fullName = "User 1";
string firstName = fullName.Substring(0, 4);
NameValidatorUsingString.IsValidName(firstName);
در اینجا زمانیکه از متد Substring استفاده می‌شود، در حقیقت تخصیص حافظه‌ی دومی جهت تولید firstName رخ می‌دهد.

همچنین اگر این اطلاعات را از طریق شبکه دریافت کرده باشیم، ممکن است به صورت آرایه‌ای از حروف دریافت شوند:
char[] anotherFullName = { 'A', 'B' };
که به صورت مستقیم در متد IsValidName قابل استفاده نیست و خطای عدم امکان تبدیل []char به string، از طرف کامپایلر صادر می‌شود:
NameValidatorUsingString.IsValidName(anotherFullName);
در این حالت برای استفاده‌ی از این آرایه، نیاز است یک تخصیص حافظه‌ی دیگر نیز صورت گیرد:
NameValidatorUsingString.IsValidName(new string(anotherFullName));

اکنون در C# 7.2، بازنویسی این متد توسط ReadOnlySpan، به صورت ذیل است:
    static class NameValidatorUsingSpan
    {
        public static bool IsValidName(ReadOnlySpan<char> name)
        {
            if (name.Length < 3)
                return false;

            if (char.IsLetter(name[0]))
                return true;

            return false;

        }
    }
که این مزایا را به همراه دارد:
ReadOnlySpan<char> fullName = "User 1".AsSpan();
ReadOnlySpan<char> firstName = fullName.Slice(0, 4);
NameValidatorUsingSpan.IsValidName(firstName);
کار با API مربوط به Spanها به همراه تخصیص حافظه‌ی جدیدی نیست. برای نمونه در اینجا متد Slice این API، سبب تخصیص حافظه‌ی جدیدی نمی‌شود (برخلاف متد Substring) و فقط به قسمتی از حافظه‌ی موجود اشاره می‌کند (بدون نیاز به کار مستقیم با اشاره‌گرها و کدهای unsafe).

و یا اینبار امکان استفاده‌ی از آرایه‌ای از کاراکترها، بدون نیاز به تخصیص حافظه‌ای جدید، برای بررسی اعتبار مقادیر دریافتی میسر است:
char[] anotherFullName = { 'A', 'B' };
NameValidatorUsingSpan.IsValidName(anotherFullName);

برای نمونه از یک چنین APIایی در پشت صحنه‌ی کتابخانه‌هایی مانند SignalR و یا Roslyn، برای بالا بردن کارآیی برنامه، با کاهش تعداد بار تخصیص‌های حافظه‌ی مورد نیاز، بسیار استفاده شده‌است. برای نمونه در NET Core 2.1.، حجم رشته‌های تخصیص داده شده‌ی در فریم ورک‌های وابسته، به این ترتیب به شدت کاهش یافته‌است.


مثال‌هایی از کار با API نوع Span

امکان ایجاد یک Span از یک array
var arr = new byte[10];
Span<byte> bytes = arr; // Implicit cast from T[] to Span<T>
پس از آن کار با این span همانند کار با آرایه‌های معمولی است؛ با این تفاوت که این span تنها یک دید مجازی از قسمتی از این آرایه را ارائه می‌دهد؛ بدون سربار تخصیص حافظه‌ی اضافی و کپی اطلاعات:
Span<byte> slicedBytes = bytes.Slice(start: 5, length: 2);
slicedBytes[0] = 42;
slicedBytes[1] = 43;
slicedBytes[2] = 44; // Throws IndexOutOfRangeException
bytes[2] = 45; // OK
در اینجا slicedBytes یک دید مجازی از ایندکس 5 تا 7 آرایه‌ی arr را ارائه می‌دهد. کار کردن با آن نیز همانند آرایه‌ها، توسط ایندکس‌ها میسر است.
همچنین تغییرات بر روی Span (غیر read only) بر روی آرایه‌ی اصلی نیز تاثیر گذار است. برای مثال در اینجا با تغییر bytes[2]، مقدار arr[2] نیز تغییر می‌کند.

و یا روش دیگر ایجاد Span استفاده از متد AsSpan است:
var array = new byte[100];
Span<byte> interiorRef1 = array.AsSpan().Slice(start: 20);
همین عملیات را توسط new Span نیز می‌توان به صورت ساده‌تری ارائه داد:
Span<byte> interiorRef2 = new Span<byte>(array: array, start: 20, length: array.Length - 20);


محدودیت‌های کار با Spanها

- Span تنها یک نوع stack-only است.
- Spanها در بین تردها به اشتراک گذاشته نمی‌شوند. هر استک در یک زمان تنها توسط یک ترد قابل دسترسی است. بنابراین Spanها thread-safe هستند.
- طول عمر Spanها کوتاه است و قابلیت قرارگیری بر روی heap با طول عمر بیشتر را ندارند؛ یعنی:
  • به صورت فیلد در یک نوع non-stackonly قابل تعریف نیستند:
class Impossible
{
   Span<byte> field;
}
فیلدهای یک کلاس در heap ذخیره می‌شوند. بنابراین محل ذخیره سازی spanها نیستند.
  • به عنوان پارامترهای متدهای async قابل استفاده نیستند. چون در این بین در پشت صحنه یک AsyncMethodBuilder تشکیل می‌شود که در قسمتی از آن، پارامترها بر روی heap قرار می‌گیرند.
  • هرجائیکه عملیات boxing صورت گیرد، نتیجه‌ی عملیات بر روی heap قرار می‌گیرد. بنابراین در یک چنین مواردی نمی‌توان از Spanها استفاده کرد. برای مثال تعریف Func<T> valueProvider و سپس فراخوانی ()valueProvider.Invoke به همراه یک boxing است. بنابراین نمی‌توان از spanها به عنوان نوع آرگومان جنریک استفاده کرد. این مورد هرچند کامپایل می‌شود، اما در زمان اجرا سبب خاتمه‌ی برنامه خواهد شد و یا نمونه‌ی دیگر، عدم امکان دسترسی به آن‌ها توسط reflection invoke APIs است که سبب boxing می‌شود.


معرفی نوع <Memory<T

با توجه به محدودیت‌های Span و خصوصا اینکه به عنوان پارامتر متدهای async قابل استفاده نیست (چون بر روی stack ذخیره می‌شوند)، نوع دیگری به نام <Memory<T نیز به همراه C# 7.2 ارائه شده‌است. البته این نوع هنوز به بسته‌ی نیوگت فوق اضافه نشده‌است و به همراه ارائه نهایی NET Core 2.1. ارائه خواهد شد.
این نوع، محدودیت <Span<T را نداشته و قابلیت ذخیره سازی بر روی heap را دارا است.
static async Task<int> ChecksumReadAsync(Memory<byte> buffer, Stream stream)
{
   int bytesRead = await stream.ReadAsync(buffer);
   return Checksum(buffer.Span.Slice(0, bytesRead));
   // Or buffer.Slice(0, bytesRead).Span
}
در اینجا نیز می‌توان از یک آرایه، یک <Memory<T را ایجاد و سپس یک <Span<T را از آن دریافت و با Sliceهای آن کار کرد.

‫بازسازی کد: ارتباط یک طرفه و دو طرفه بین کلاس ها

$
0
0
در طراحی شیء گرا، ارتباط کلاس‌ها امری عادی است. در صورتیکه فقط یکی از کلاس‌ها نیاز به شیء کلاس دیگری را داشته باشد، این ارتباط یک طرفه نامیده می‌شود و زمانیکه هر دو کلاس به اشیاء یکدیگر نیاز داشته باشند، دو طرفه نامیده می‌شود.
زمانیکه ارتباطی به صورت یک طرفه پیاده سازی شده باشد، ممکن است پس از مدتی نیاز به ارتباط برعکس بین کلاس‌ها بوجود بیاید. در این صورت ارتباط دوطرفه را با اضافه کردن یک خصوصیت ایجاد می‌کنیم. به طور مثال نرم افزاری را در نظر بگیرید که در آن دو موجودیت مشتری و سفارش وجود دارند و این موجودیت‌ها به صورت زیر طراحی شده‌اند:   

 
public class Customer 
{     public string Name { get; set; } 
} 
public class Order 
{     public Customer Customer { get; set; } 
}
در این طراحی، از شیء سفارش می‌توان در صورت نیاز به شیء مشتری مربوط به آن رسید. اما با در دست داشتن شیء مشتری، نمی‌توان به سفارش‌های آن دسترسی داشت؛ زیرا رفرنسی به سفارش در آن وجود ندارد. به عبارتی طراحی بالا نمایانگر شرایطی است که در آن زمان ثبت قرارداد می‌توانیم مشتری جدیدی را نیز ایجاد کنیم.
در صورت نیاز به ارتباط دوطرفه، برای ایجاد آن در این شرایط، خصوصیتی را که نشان دهنده سفارشات مشتری باشد، به کلاس مشتری اضافه می‌کنیم. در نتیجه، طراحی به صورت زیر تغییر می‌کند. این شرایط ممکن است زمانی بوجود بیاید که نیاز داریم با در دست داشتن شیء یک مشتری بتوانیم سفارشات مورد نظر وی را ایجاد کنیم. 

public class Customer 
{     public string Name { get; set; }     public ICollection<Order> Orders { get; set; } 
} 
public class Order 
{     public Customer Customer { get; set; } 
}

همان طور که با مثالهای آورده شده قابل مشاهده است، تصمیم به استفاده از ارتباط یک طرفه یا دوطرفه، تصمیمی صرفا فنی نیست و به شرایط قواعد کسب و کار نیز ارتباط می‌یابد. 

اگر از ORM در طراحی لایه دسترسی داده استفاده شود، معمولا ارتباط‌های دوطرفه در نگاه اول مشکل ساز به نظر نمی‌رسند، یا حتی لازم خواهند بود (برای استفاده از امکانات mapping بر اساس قرارداد). اما ارتباطات دو طرفه معمولا امکان دسترسی به اقلام اطلاعاتی را بدون در نظر گرفتن قواعد کسب و کاری لازم، بوجود می‌آورند. یکی از اشکالات اصلی طراحی با ارتباط دو طرفه ارتباط بیش از اندازه کلاس‌ها با یکدیگر است. در این صورت ممکن است تغییر در یک کلاس، به کلاس‌های دیگری نفوذ کند که این مورد خود یک الگوی کد بد بو است.

عموما با توجه به هزینه‌ای که ارتباط دو طرفه ایجاد می‌کند، بهتر است استفاده از آن، تا آخرین لحظه نیاز به تعویق بیفتد و اولویت طراحی با ارتباط یک طرفه باشد.  

‫Value Types ارجاعی در C# 7.2

$
0
0
در C# 7.2 می‌توان با value types (مانند structs) همانند reference types (مانند کلاس‌ها) رفتار کرد. جائیکه کارآیی برنامه بسیار حائز اهمیت باشد (مانند بازی‌ها)، استفاده از structs و value types بسیار مرسوم است؛ از این جهت که این نوع‌ها بر روی heap تخصیص داده نمی‌شوند. اما مشکل آن‌ها این است که زمانیکه به متدها ارسال می‌شوند، مقدار آن‌ها ارسال خواهد شد و برای این منظور نیاز به ایجاد یک کپی جدید از آن‌ها می‌باشد. برای رفع این مشکل و کاهش سربار کپی کردن اشیاء، اکنون در C# 7.2 می‌توان value types را همانند reference types به متدها ارسال کرد.


واژه‌ی کلیدی جدید in

C# 7.2‌، واژه‌ی کلیدی جدیدی را به نام in جهت تعریف پارامترها، معرفی کرده‌است. زمانیکه از آن استفاده می‌شود به این معنا است که value type ارسالی به آن، توسط ارجاعی از آن، در اختیار متد قرار می‌گیرد و نه توسط مقدار کپی شده‌ی آن (حالت پیش‌فرض) و همچنین متد استفاده کننده‌ی از آن، مقدار این شیء را تغییر نمی‌دهد.
واژه‌ی کلیدی in مکمل واژه‌های کلیدی ref و out است که پیشتر به همراه زبان #C ارائه شده بودند:
- واژه‌ی کلیدی out: مقدار آرگومان مزین شده‌ی توسط آن، باید درون متد تنظیم شود و صرفا کاربرد ارائه‌ی یک خروجی اضافه‌تر توسط آن متد را دارد.
- واژه‌ی کلیدی ref: مقدار آرگومان مزین شده‌ی توسط آن، ممکن است درون متد تنظیم شود، یا خیر و همچنین توسط ارجاع به آن منتقل می‌شود.
- واژه‌ی کلیدی in: مقدار آرگومان مزین شده‌ی توسط آن، درون متد تغییر نخواهد کرد و همچنین توسط ارجاع به آن منتقل می‌شود.

برای مثال اگر پارامترهای value type متد زیر را از نوع in معرفی کنیم، امکان تغییر مقدار آن‌ها درون متد وجود نخواهد داشت:
public static int Add(in int number1, in int number2)
{
   number1 = 5; // Cannot assign to variable 'in int' because it is a readonly variable
   return number1 + number2;
}
و کامپایلر با صدور خطای readonly بودن پارامتر number1، از انجام اینکار جلوگیری می‌کند


واژه‌ی کلیدی جدید in تا چه اندازه‌ای بر روی کارآیی برنامه تاثیر دارد؟

زمانیکه یک value type را به متدی ارسال می‌کنیم، ابتدا به مکان جدیدی از حافظه کپی شده و سپس مقدار clone شده‌ی آن، به متد ارسال می‌شود. با استفاده از واژه‌ی کلیدی in، دقیقا همان ارجاع به مقدار اولیه، به متد ارسال خواهد شد؛ بدون ایجاد کپی اضافه‌تری از آن. برای بررسی تاثیر این عملیات بر روی کارآیی برنامه، می‌توان از BenchmarkDotNetاستفاده کرد. برای این منظور ابتدا ارجاعی را به BenchmarkDotNet اضافه می‌کنیم:
<ItemGroup><PackageReference Include="BenchmarkDotNet" Version="0.10.12" /></ItemGroup>
سپس متدهایی را که قرار است کارآیی آن‌ها بررسی شوند، با ویژگی Benchmark مزین خواهیم کرد:
using BenchmarkDotNet.Attributes;

namespace CS72Tests
{
    public struct Input
    {
        public decimal Number1;
        public decimal Number2;
    }

    [MemoryDiagnoser]
    public class InBenchmarking
    {
        const int loops = 50000000;
        Input inputInstance = new Input();

        [Benchmark(Baseline = true)]
        public decimal RunNormalLoop_Pass_By_Value()
        {
            decimal result = 0M;
            for (int i = 0; i < loops; i++)
            {
                result = Run(inputInstance);
            }
            return result;
        }

        [Benchmark]
        public decimal RunInLoop_Pass_By_Reference()
        {
            decimal result = 0M;
            for (int i = 0; i < loops; i++)
            {
                result = RunIn(in inputInstance);
            }
            return result;
        }

        public decimal Run(Input input)
        {
            return input.Number1;
        }

        public decimal RunIn(in Input input)
        {
            return input.Number1;
        }
    }
}
در آخر برای اجرای آن خواهیم داشت:
static void Main(string[] args)
{
    var summary = BenchmarkRunner.Run<InBenchmarking>();
و در این حالت برنامه را باید توسط دستور «dotnet run -c release» اجرا کرد (اندازه گیری کارآیی در حالت release و نه دیباگ پیش‌فرض)
با این خروجی نهایی:
                      Method |      Mean |    Error |   StdDev | Scaled | Allocated |
---------------------------- |----------:|---------:|---------:|-------:|----------:|
 RunNormalLoop_Pass_By_Value | 280.04 ms | 2.219 ms | 1.733 ms |   1.00 |       0 B |
 RunInLoop_Pass_By_Reference |  91.75 ms | 1.733 ms | 1.780 ms |   0.33 |       0 B |
همانطور که ملاحظه می‌کنید، کارآیی برنامه در حالت استفاده‌ی از پارامترهای in، حداقل 3 برابر شده‌است.


امکان استفاده‌ی از واژه‌ی کلیدی in در حین تعریف متدهای الحاقی

در حین تعریف متدهای الحاقی، واژه‌ی کلیدی in باید پیش از واژه‌ی کلیدی this ذکر شود:
    public static class Factorial
    {
        public static int Calculate(in this int num)
        {
            int result = 1;
            for (int i = num; i > 1; i--)
                result *= i;

            return result;
        }
    }
در این حالت اگر برنامه را به صورت زیر اجرا کنیم (یکبار با ذکر صریح in، بار دیگر بدون in و یکبار هم به صورت فراخوانی متد الحاقی بر روی عدد):
int num = 3;
Console.WriteLine($"(in num) -> {Factorial.Calculate(in num)}");
Console.WriteLine($"(num) -> {Factorial.Calculate(num)}");
Console.WriteLine($"num. -> {num.Calculate()}");
خروجی‌های ذیل را دریافت خواهیم کرد:
(in num) -> 6
(num) -> 6
num. -> 6
به عبارتی حین فراخوانی و استفاده‌ی از متدی که پارامتر آن به صورت in تعریف شده‌است، ذکر in ضروری نیست.

و به طور کلی استفاده‌ی از in در مکان‌های ذیل مجاز است:
• methods
• delegates
• lambdas
• local functions
• indexers
• operators
 

محدودیت‌های استفاده‌ی از پارامترهای in

الف) محدودیت استفاده از پارامترهای in در تعریف overloads
مثال زیر را در نظر بگیرید:
    public class CX
    {
        public void A(Input a)
        {
            Console.WriteLine("int a");
        }

        public void A(in Input a)
        {
            Console.WriteLine("in int a");
        }
    }
در اینجا overloadهای تعریف شده‌ی متد A تنها در ذکر واژه‌ی کلیدی in یا modifier متفاوت هستند.
اگر سعی کنیم وهله‌ای از این کلاس را ایجاد کرده و از متدهای A آن استفاده کنیم:
    public class Y
    {
        public void Test()
        {
            var inputInstance = new Input();
            var cx = new CX();
            cx.A(inputInstance); // The call is ambiguous between the following methods or properties: 'CX.A(Input)' and 'CX.A(in Input)'
        }
    }
خطای کامپایلر مبهم بودن متد A مورد استفاده صادر خواهد شد. یعنی نمی‌توان overload ایی را تعریف کرد که تنها در modifier از نوع in با دیگری متفاوت باشد؛ چون ذکر in در حین فراخوانی متد، اختیاری است.

ب) پارامترهای از نوع in را در متدهای iterator نمی‌توان استفاده کرد:
public IEnumerable<int> B(in int a) // Iterators cannot have ref or out parameters
{
   Console.WriteLine("in int a");
   yield return 1;
}

ج) پارامترهای از نوع in را در متدهای async نمی‌توان استفاده کرد:
public async Task C(in int a) // Async methods cannot have ref or out parameters
{
   await Task.Delay(1000);
}


تاثیر کار با متدهای داخلی تغییر دهنده‌ی وضعیت یک struct

مثال زیر را درنظر بگیرید. به نظر شما خروجی آن چیست؟
using System;

namespace CS72Tests
{
    struct MyStruct
    {
        public int MyValue { get; set; }

        public void UpdateMyValue(int value)
        {
            MyValue = value;
        }
    }

    public static class TestInStructs
    {
        public static void Run()
        {
            var myStruct = new MyStruct();
            myStruct.UpdateMyValue(1);

            UpdateMyValue(myStruct);

            Console.WriteLine(myStruct.MyValue);
        }

        static void UpdateMyValue(in MyStruct myStruct)
        {
            myStruct.UpdateMyValue(5);
        }
    }
}
در اینجا اگر متد TestInStructs.Run را اجرا کنیم، خروجی آن، نمایش عدد 1 خواهد بود.
در ابتدا مقدار struct را به 1 تنظیم و سپس ارجاع آن‌را به متدی دیگر که مقدار آن‌را به 5 تنظیم می‌کند، ارسال کردیم. در این حالت برنامه بدون مشکل کامپایل و اجرا می‌شود.  علت اینجا است که کامپایلر #C زمانیکه متدی را در داخل یک struct فراخوانی می‌کند، یک clone از آن struct را ایجاد کرده و متد را بر روی آن clone اجرا می‌کند؛ چون نمی‌داند که آیا این متد وضعیت و مقدار این struct را تغییر می‌دهد یا خیر. در این حالت کپی اصلی بدون تغییر باقی می‌ماند (در نهایت عدد 1 را مشاهده خواهیم کرد)، اما در آخر فراخوان، ارجاعی از struct را دریافت نکرده و بر روی کپی آن کار می‌کند. بنابراین مزیت بهبود کارآیی، از دست خواهد رفت.

البته در اینجا اگر می‌خواستیم مقدار MyValue را مستقیما تغییر دهیم، کامپایلر از آن جلوگیری می‌کرد و این کد هیچگاه کامپایل نمی‌شد:
static void UpdateMyValue(in MyStruct myStruct)
{
   myStruct.MyValue = 5; // Cannot assign to a member of variable 'in MyStruct' because it is a readonly variable
   myStruct.UpdateMyValue(5);
}

‫استفاده از مسیرهای مطلق در حین import ماژول‌ها در برنامه‌های مبتنی بر TypeScript

$
0
0
در حین import ماژول‌های TypeScript ایی پس از مدتی به یک چنین کدهایی خواهیم رسید:
import { SpecialCollection } from "../../special";
import { LoginComponent } from "../login";
import { TextUtils } from ".../../utils/text";
import { Router } from "../../../core/router";
در این حالت، در یک پوشه برای import ماژولی مشخص، چنین import ایی را خواهیم داشت:
import { Data } from '../data';
و در پوشه‌ی تو در توی دیگری، این تعریف به صورت زیر تغییر می‌کند:
import { Data } from '../../../data';
و در آخر برنامه پر می‌شود از مسیرهای نسبی ‘../../../..’ مانند. به این ترتیب جابجا کردن فایل‌ها و Refactoring آن‌ها، مشکل می‌شود.
خوشبختانه کامپایلر TypeScript به همراه تنظیمات baseUrl و paths است که توسط آن‌ها می‌توان این مسیرهای نسبی را به مسیرهای مطلق تبدیل کرد و در این حالت اهمیتی ندارد که ماژول مدنظر از چه سطحی و درون چه پوشه‌ی تو در تویی فراخوانی می‌شود، این مسیر import همواره ثابت خواهد بود.


تنظیمات فایل tsconfig.json برای معرفی مسیرهای مطلق ماژول‌ها

فرض کنید می‌خواهید از یکی از سرویس‌های Core Moduleاستفاده کنید:


بسته به عمق پوشه‌ی استفاده کننده، به یک چنین تعریفی خواهید رسید:
import { BrowserStorageService } from "./../../core/browser-storage.service";
برای بهبود این وضعیت، فایل tsconfig.json و یا همان تنظیمات کامپایلر TypeScript را به نحو ذیل تکمیل می‌کنیم:
{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@app/*": [
        "app/*"
      ],
      "@app/core/*": [
        "app/core/*"
      ],
      "@app/shared/*": [
        "app/shared/*"
      ],
      "@env/*": [
        "environments/*"
      ]
    }
  }
}
در اینجا baseUrl به پوشه‌ی src برنامه اشاره می‌کند و مسیرهای بعدی بر این اساس محاسبه می‌شوند. در ادامه در قسمت paths، ابتدا یک نام مستعار ذکر می‌شود و سپس مسیری که ارائه دهنده‌ی آن است. ذکر @ در اینجا اختیاری است؛ اما ذکر */‌ها اجباری است.
پس از این تغییرات، اکنون افزونه‌ی پیشنهاد دهنده‌ی imports، هر دو حالت استفاده‌ی از مسیر مطلق بر اساس نام مستعار تعریف شده:
 import { BrowserStorageService } from "@app/core/browser-storage.service";
و یا استفاده‌ی از مسیر نسبی را نیز پیشنهاد می‌دهد:
 import { BrowserStorageService } from "./../../core/browser-storage.service";


برای مثال اگر دقت کرده باشید، روش import اجزای خود Angular به صورت زیر است:
 import { Component } from '@angular/core';
علت اینجا است که Angular از تعریف مشابهی به صورت زیر برای نگاشت پوشه‌ی node_modules آن به angular@ استفاده می‌کند:
"paths": {
    "@angular/*": ["node_modules/@angular/*"]
},
و ذکر @ اختیاری هم از اینجا اقتباس شده‌است.


یک نکته‌ی مهم: تنظیمات فوق بدون تنظیمات معادل webpack ناقص هستند

اگر از برنامه‌ی Angular CLI استفاده می‌کنید، تنظیمات ذکر شده، تا همینجا به پایان می‌رسند؛ چون webpack جزئی از Angular CLI است و تنظیمات پیش فرض آن، قسمت baseUrl و paths فایل tsconfig.json را به صورت خودکار پردازش می‌کند. اما اگر از TypeScript در محیط‌های دیگری استفاده می‌کنید که از webpack به صورت مجزایی استفاده می‌کنند، نیاز است قسمت resolve.alias فایل webpack.config.js را نیز جهت معرفی این تغییرات، اصلاح کنید. از این جهت که کامپایلر TypeScript این مسیرهای مطلق را در حین تولید فایل‌های نهایی JavaScript ایی معادل، به مسیرهای نسبی بازنویسی نمی‌کند و در این حالت webpack نمی‌داند که چطور باید این ماژول‌ها را یافته و یکی کند.
resolve: {
  extensions: ['*', '.js', '.ts'],
  modules: [
    rootDir,
    path.join(rootDir, 'node_modules')
  ],
  alias: {
    '@app': 'src/app'
  }
},


کوتاه کردن مسیرهای مطلق با معرفی فایل ویژه‌ی index.ts

تا اینجا بجای ذکر مسیر
import { BrowserStorageService } from "./../../core/browser-storage.service";
به مسیر مطلق زیر رسیدیم (صرفنظر از محل قرارگیری ماژولی که قرار است آن‌را import کند):
import { BrowserStorageService } from "@app/core/browser-storage.service";
این را هم می‌خواهیم به صورت زیر کوتاه‌تر کنیم:
import { BrowserStorageService } from "@app/core";
یعنی فقط app/core@ را ذکر کنیم.

برای اینکار نیاز است فایل ویژه‌ای را به نام index.ts، در ریشه‌ی پوشه‌ی core ایجاد کنیم (src\app\core\index.ts)، با این محتوا:
export * from "./browser-storage.service";
export * from "./app-config.service";
export * from "./seo-service";
در اینجا تمام ماژول‌هایی که توسط Core Module ارائه می‌شوند را یکبار export می‌کنیم.
برای نمونه اگر به پوشه‌ی node_modules\@angular خود مجموعه‌ی Angular هم مراجعه کنید، هر پوشه‌ی src آن به همراه یک فایل index.d.ts شبیه تعاریف فوق نیز هست.

پس از افزودن فایل index.ts به ریشه‌ی پوشه‌ی مدنظر، اکنون در لیست پیشنهادات، ذکر app/core@ تنها نیز ظاهر شده و استفاده‌ی از آن مجاز است:


‫سیستم‌های توزیع شده در NET. - بخش هفتم- معرفی Apache Kafka

$
0
0
سرچشمه Kafka از LinkedIn آغاز و سپس در سال 2011 توسط Apache بصورت open source ارائه شد. هدف آن ارائهیک بستر جریان داده‌ای توزیع شده‌است که اساس آن، Publish-Subscribe می‌باشد . سادگی اضافه کردن قابلیت‌های مقیاس پذیری افقی، تحمل خطا و افزایش کارآیی توسط این بستر باعث شده‌است که هزاران شرکت از آن بعنوان بستر ارتباطی قسمتهای مختلف سیستمها و زیرسیستمهای خود استفاده کنند.
همانطور که گفته شد وظیفه و هدف اصلی Apache Kafka، ارائه یک بستر برای مدیریت و کنترل جریان‌های اطلاعاتی با کارآیی بسیار بالا، در سیستم‌ها و زیرسیستمهای مختلف است. یعنی شما می‌توانید با ایجاد کردن یک Pipeline برای جریان اطلاعات خود، وابستگی مستقیم سیستمها و زیرسیستمها را از بین ببرید؛ آن هم بصورتی که بروز مشکلی در هر قسمت، کمترین میزان تاثیر را در سایر قسمتها داشته باشد.
فرض کنید شما تعداد زیادی سیستم و زیرسیستم مختلف را داشته باشید که هر کدام از آنها نیازمند ارتباط با برخی از قسمتهای دیگر است. در این صورت شما دو راه دارید: اول اینکه در هر قسمت سرویس‌هایی را برای ارتباط با سایر قسمت‌ها پیاده سازی کنید و هر قسمت بصورت مستقیم با سایر قسمتها در ارتباط باشد.

مشخصا کنترل و مدیریت جریان اطلاعاتی در این پیاده سازی کار بسیار دشواری است. تغییر هر قسمت، تاثیر مستقیمی بر روی سایر قسمتها دارد و در صورتی که هریک از قسمتها با مشکلی روبرو شوند، سایر قسمتهای مرتبط نیز با مشکل روبرو می‌شوند. این مشکل زمانی بسیار نمایان می‌شود که در معماری‌هایی مانند میکروسرویس، بدلیل بالا رفتن تعداد زیرسیستم‌ها و ارتباطات آنها، مدیریت این ارتباطات کار بسیار دشوار، پرهزینه و پیچیده‌ای می‌شود.
روش Apache Kafka برای رفع مشکل فوق به این صورت است که Kafka با بر عهده گرفتن مدیریت ارتباطات و جریان داده‌ای قسمتهای مختلف، به شما کمک می‌کند تا تیم پیاده سازی، تنها تمرکزشان را بر روی Businessی که می‌خواهند پیاده سازی کنند، قرار دهند. با این روش می‌توانیم به راحتی سیستمهایی را پیاده سازی کنیم که از نظر ارتباطی در حالت معمول، پیچیده یا بسیار پیچیده‌اند.

همانطور که می‌بینید دیگر نیازی نیست تا قسمتهای مختلف بصورت مستقیم با یکدیگر در ارتباط باشند؛ تمامی ارتباطات از طریق Kafka انجام می‌شود. تغییر یک قسمت، تاثیر زیادی بر روی سایر قسمتها ندارد. از دسترس خارج شدن یا بروز هر گونه مشکلی در یک قسمت، بر روی کل سیستم تاثیر زیادی ندارد. پیامهای مربوط به یک قسمت تا زمانی که پردازش نشده‌اند از بین نمی‌روند. پس سیستمها می‌توانند در حالت Offline نیز به کار خود ادامه دهند. شما می‌توانید  در این روش تمامی قسمتهای  سیستم را بصورت یک Cluster پیاده سازی کنید. بنابراین احتمال از دسترس خارج شدن هر قسمت به کمترین میزان می‌رسد. اما حتی درصورتی که یک قسمت بصورت موقت از دسترس خارج شود، پیامهای مرتبط با آن قسمت تا زمانی که دوباره به جریان پردازش بازگردد، از بین نمی‌روند. پس از اضافه شدن قسمت از دسترس خارج شده، بلافاصله تمامی پیامهای مرتبط با آن قسمت برایش ارسال می‌شوند. برای بالا رفتن میزان کارآیی و تحمل خطا، به راحتی می‌توانید خود Kafka را نیز بصورت یک Cluster پیاده سازی کنید و با بالا رفتن تعداد درخواست، در صورت نیاز می‌توانید عملیات مقیاس پذیری افقی را به راحت‌ترین روش ممکن انجام دهید.

نمایی از معماری کلی Apache Kafka: 


برای شروع به آموزش Apache Kafka بهتر است ابتدا با مفاهیم و اصطلاحات آن آشنا شویم:

Producer:
  ارسال کننده پیام. Application، سیستم یا زیرسیستمی که عملیات Publish پیام را برای Topic خاص از Kafka Server انجام می‌دهد.

Consumer:
دریافت کننده پیام. Application، سیستم یا زیرسیستمی که بر روی یک یا چند Topic خاص، Subscribe کرده‌است (همچنین هر Consumer می‌تواند روی یک یا چند Partition از یک Topic خاص نیز Subscribe کند).

Consumer Group:
 گروهی از Consumer‌ها می‌باشند که با یک group.id، مشخص شده‌اند. عموما این گروه شامل یک Replicate از یک Application است؛ مانند گروه ارسال کننده ایمیل (یک زیر سیستم ارسال کننده ایمیل که چندین بار در سرور‌های مختلف اجرا شده است). Kafka این ضمانت را به ما می‌دهد که هر پیام ذخیره شده در یک Topic، برای تمامی Consumer Group‌های مرتبط ارسال شود؛ اما در هر Consumer Group، تنها یک دریافت کننده داشته باشد. یعنی هر پیام در هر Consumer Group، تنها توسط یک Consumer دریافت می‌شود.

Broker:
 قسمتی که تمامی پیامها را  از Producer دریافت می‌کند، سپس آن‌ها را در Log مربوط به Topic مشخص شده ذخیره می‌کند و پس از آن، پیام ذخیره شده را برای تمامی Consumerهای مرتبط ارسال می‌کند.

Topic: 
یک دسته بندی برای ذخیره کردن پیامهای Publish شده می‌باشد. Topicها همانند مفهوم Tableها در SQL Server می‌باشند. همانطور که می‌دانید هر Table از قبل تعریف شده‌است. یک کاربر با ارسال یک درخواست ثبت، داده‌ها را در آن ذخیره می‌کند و سپس گروهی از کاربران از داده‌های ثبت شده استفاده می‌کنند. در مفهموم Topic نیز ابتدا ما Topic مورد نظر را با خصوصیاتی که باید داشته باشد تعریف می‌کنیم (البته می‌توان بصورت Dynamic نیز آن را تعریف کرد؛ اما این روش توصیه نمی‌شود). سپس Producer پیام مربوطه را به همراه نام Topic برای Broker ارسال می‌کند. Broker پیام را در Partition مربوطه از Topic ذخیره می‌کند و سپس پیام برای تمامی Consumer‌های مربوطه ارسال می‌شود.

Partition:
یکی از تفاوتهای بسیار مهم Kafka با سایر Message broker‌ها مانند RabitMQ که باعث بالارفتن کارآیی آن نیز شده‌است، قابلیت Partition در Topic‌ها می‌باشد. در واقع هر Topic از یک یا چندین Partition برای ذخیره داده‌ها استفاده می‌کند. تعریف درست تعداد Partition‌ها در یک Topic، تاثیر مستقیمی بر درجه همزمانی و کارآیی در آن Topic و کل سیستم دارد. در Kafka تمامی پیامها به همان ترتیبی که وارد شده‌اند، در Partition‌های یک Topic ذخیره می‌شوند و به همان ترتیب نیز برای Consumer‌ها ارسال می‌شوند.
بطور مثال فرض کنید تعداد Partition‌های یک Topic با نام DepartmentMessage یک می‌باشد (از این Topic برای ذخیره پیامهای واحدهای مختلف یک سازمان استفاده می‌شود). در این صورت تمامی پیامهای دریافتی تنها در یک Partition ذخیره می‌شوند.

هر خانه از یک Partition، توسط یک شناسه از نوع int و با نام offsetدر دسترس است. تمامی پیامهای جدید ارسالی توسط Producer با offset ی بزرگتر از offset موجود در این Partition ذخیره می‌شوند؛ یعنی در انتهای آن قرار می‌گیرند. در مثال فوق در صورت دریافت پیام جدید، offset آن با عدد 10 مقداردهی می‌شود. همچنین عملیات خواندن نیز از کوچکترین offsetی که هنوز  مقدار آن توسط Consumer‌ها خوانده نشده‌است، انجام می‌شود. همانطور که مشخص است، بدلیل اینکه تعداد Partitionهای این مثال عدد یک می‌باشد، تمامی درخواست‌های Producer‌ها در یک Partition قرار می‌گیرند و تمامی Consumer‌ها نیز از طریق یک Partition به پیامها دسترسی دارند؛ یعنی در صورت بالا بردن تعداد Producer‌ها یا Consumer‌ها، کارآیی بالا نمی‌رود. البته با اینکه کنترل مقدار اولیه offset برای شروع یک Consumer به دست خود Consumer و Zookeeper است، اما در اکثر موارد تمامی Consumer‌های یک Topic باید از یک نقطه، شروع به خواندن داده‌ها کنند. در این حالت تا زمانیکه پیام با offset 1، توسط Consumerی خوانده نشود، هیچ Consumerی نمی‌تواند پیام شماره 2 را بخواند. استفاده کردن از یک Partition بیشتر زمانی کاربرد دارد که بخواهید تمامی پیامهایتان، واقعا در یک صف قرار بگیرند.
حال فرض کنید در سازمان شما سه واحد اداری، مالی و آموزش وجود دارد. در این صورت بدلیل اینکه تمامی پیامها در یک Partition ذخیره می‌شوند، تا زمانی که یک واحد تمامی پیامهای مرتبط با خود را از ابتدای Partition نخوانده‌است، دیگر واحدها نمی‌توانند به پیامهای مرتبط با خود دسترسی داشته باشند. پس در این صورت ما می‌توانیم تعداد Partition‌های این Topic را عدد 3 درنظر بگیریم؛ بصورتی که پیامهای مرتبط با هر واحد در یک Partition جدا قرار بگیرد.

در این روش هر Producer زمانیکه پیامی را برای این Topic ارسال می‌کند، یک Key نیز برای آن مشخص می‌کند و این Key نشان دهنده این است که پیام جدید باید در کدام Partition ذخیره شود. یعنی بصورت همزمان می‌توانید در هر سه Partition، پیامهایتان را ذخیره کنید؛ بصورتی که بطور مثال تمامی پیامهای مربوط به واحد اداری، در Partition 0  و تمامی پیامهای مربوط به واحد مالی، در Partition 1 و واحد آموزش، در Partition 2 ذخیره شوند و همچنین عملیات خواندن از این Topic نیز می‌تواند بصورت همزمان در واحدهای مختلف انجام شود.
باید در تعریف تعداد Partition‌های یک Topic این نکته را در نظر بگیرید که این تعداد کاملا به نیازمندی شما و کارآیی که شما مد نظر دارید، بستگی دارد. تعداد این Partition‌ها حتی می‌تواند به تعداد User‌های یک سیستم نیز تعریف شود. علاوه بر آن باید بدانید که هر Partition در هر زمان تنها توسط یک Primary Broker می‌تواند در دسترس سایر قسمتها قرار بگیرد و تمامی عملیات خواندن و نوشتن در Partition توسط این Kafka Server انجام می‌شود و در صورتیکه به هر دلیلی این سرور از دسترس خارج شود، مدیریت این Partition به سرور‌های دیگر داده می‌شود.

Cluster:
مجموعه ای از Brokerها می‌باشد که بصورت یک Cluster اجرا شده‌اند. این کار باعث بالا رفتن کارآیی و تحمل خطا می‌شود.

Primary Broker:
یک Kafka Server که مسئول خواندن و نوشتن در یک Partition است. در یک Cluster هر Partition در یک زمان تنها یک Primary Broker دارد. این Primary Broker همزمان می‌تواند برای Partition‌های دیگر نقش Replicas Broker را بازی کند. انتخاب یک Primary Broker برای یک Partition توسط ZooKeeper انجام می‌شود.

Replicas Brokers :
Kafka Serverهایی که شامل یک کپی از Partition می‌باشند. عملیات خواندن و نوشتن در Partition توسط Primary انجام می‌شود. در صورتیکه Primary از دسترس خارج شود، ZooKeeper یکی از Replicas Broker‌ها را بعنوان Primary در نظر می‌گیرد. همچنین این نکته را باید در نظر بگیرید که هر Replicate همزمان می‌تواند Primary پارتیشن‌های دیگر باشد.

Replication Factor :
این خصوصیت احتمال از دست دادن داده‌های یک Topic را به حداقل می‌رساند؛ به این صورت که هر پیام از یک Topic، در چندین سرور مختلف که تعداد آنها توسط این خصوصیت مشخص می‌شود، نگهداری می‌شود.

Apache ZooKeeper :
Kafka هیچ Stateی را نگه نمی‌دارد (اصطلاحا stateless می‌باشد). برای ذخیره کردن و مدیریت تمامی Stateها از جمله اینکه در حال حاضر Primary Broker برای یک Partition چه سروری است، یا اینکه پیامهای یک Partition تا کدام offset توسط Consumer‌ها خوانده شده‌اند یا اینکه کدام Consumer در حال حاضر در یک Consumer Group مسئول یک Partition می‌باشد، توسط Apache Zookeeper انجام می‌شود.

ضمانت‌هایی که Kafka می‌دهد:
  1. تمامی پیامهای دریافتی در یک Partition از یک Topic، به همان ترتیبی که دریافت می‌شوند ذخیره می‌شوند.
  2. Consumer‌ها تمامی پیامها را در یک Partition به همان ترتیبی که ذخیره شده‌اند، دریافت می‌کنند.
  3. در یک Topic با Replication Factorی با مقدار N، درجه تحمل خطا N - 1 می‌باشد.

تا اینجا با اهداف، مفاهیم و اصطلاحات Apache Kafka آشنا شدیم. در بخش بعد به راه اندازی قسمتهای مختلف آن در Ubuntu می‌پردازیم و می‌بینیم که به چه صورت می‌توان به راحتی یک Cluster از سرورهای Kafka را ایجاد کرد.

    ‫سیستم‌های توزیع شده در NET. - بخش هشتم- راه اندازی Apache Kafka

    $
    0
    0
    در این بخش نحوه راه اندازی Apache Kafka را در Ubuntu مورد بررسی قرار می‌دهیم و می‌بینیم که هر یک از تعاریف و اصطلاحاتی که در بخش قبل معرفی شد، چگونه پیاده سازی می‌شوند (در صورتی که امکان استفاده از Ubuntu را ندارید و می‌خواهید مراحل این بخش را در windows انجام دهید می‌توانید از راهنمای راه اندازی Kafka در windows استفاده کنید تا بتوانید بخشهای بعدی این سری مقالات را پیگیری و اجرا کنید).

    بروز رسانی Ubuntu:
    قبل از هرچیزی باید مطمئن شوید که Ubuntu بصورت کامل بروز رسانی شده است. برای این کار یک ترمینال جدید را باز و دستورهای زیر را در آن وارد کنید:
    sudo apt-get update -y
    sudo apt-get upgrade -y
    نصب java:
    نکته:درصورتی که قبلا java را نصب کرده‌اید نیازی به انجام این مرحله نیست و برای اطمینان از نصب java می‌توانید دستور زیر را در خط فرمان terminal ایجاد شده وارد کنید:
    sudo java -version
    قبل از دانلود و نصب Apache Kafka، باید ابتدا java را نصب کنید. برای این کار دستور زیر را اجرا کنید:
    sudo add-apt-repository -y ppa:webupd8team/java
    باید خروجی زیر به شما نمایش داده شود:
    gpg: keyring `/tmp/tmpkjrm4mnm/secring.gpg' created
    gpg: keyring `/tmp/tmpkjrm4mnm/pubring.gpg' created
    gpg: requesting key EEA14886 from hkp server keyserver.ubuntu.com
    gpg: /tmp/tmpkjrm4mnm/trustdb.gpg: trustdb created
    gpg: key EEA14886: public key "Launchpad VLC" imported
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 1
    gpg:               imported: 1  (RSA: 1)
    OK
    برای بروز رسانی metadata‌های repository جدید باید دستور زیر را وارد کنید:
    sudo apt-get update
    و در پایان دستور زیر را برای نصب java اجرا کنید:
    sudo apt-get install oracle-java8-installer -y
    برای اطمینان از نصب java دستور زیر را وارد کنید:
    sudo java -version
    در صورتیکه خروجی زیر به شما نمایش داده شود به این معنا است که عملیات نصب java با موفقیت انجام شده‌است:
    java version "1.8.0_66"
    Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
    Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)

                                                
    دانلود Apache Kafka :
    آخرین نگارش پایدار از Apache Kafka، نگارش 1.0.0 می‌باشد که می‌توانید آن را از طریق صفحه دریافت Apache Kafka ، دریافت کنید.

    دانلود Apache Kafka


    پس از دریافت Apache Kafka، از طریق یک terminal جدید وارد پوشه Downloads شوید. سپس فایل مورد نظر را از حالت فشرده خارج کنید و وارد پوشه اصلی آن شوید. برای این کار از دستورات زیر استفاده کنید:

    tar -xzf kafka_2.11-1.0.0.tgz
    cd kafka_2.11-1.0.0

     سپس با استفاده از دستور "ls " لیست تمامی فایلها و فولدر‌های موجود در فولدر kafka_2.11-1.0.0  و   را نمایش دهید:

    در لیست نمایش داده شده دو فولد اصلی bin و config وجود دارند که به ترتیب فایلهای اجرایی و کانفیگهای پیشفرض و مورد نیاز، در آنها قرار دارند.


    اجرای Apache ZooKeeper:

    همانطور که در بخش قبل توضیح داده شد، Apache Kafka هیچ Stateی را در خود ذخیره و مدیریت نمی‌کند و اصطلاحا Stateless می‌باشد و مدیریت تمامی این Stateها را بر عهده  Apache ZooKeeper قرار می‌دهد. بنابراین قبل از اینکه بخواهیم Kafka را اجرا کنیم، ابتدا باید Apache ZooKeeper را اجرا کنیم. برای اجرای Apache ZooKeeper در terminalی که قبلا باز کرده‌اید، دستور زیر را اجرا کنید:

    bin/zookeeper-server-start.sh config/zookeeper.properties

    با اجرای فایل zookeeper-server-start.sh و ارسال کانفیگ پیشفرضش در فولدر config با نام  zookeeper.properties، قسمت مدیریت کننده Stateهای Kafka  اجرا می‌شود.


    اجرای Apache Kafka:

    پس از اجرای Apache ZooKeeper، باید یک terminal جدید را باز کنید و با استفاده از دستور زیر kafka-server را با استفاده از کانفیگ پیشفرضش اجرا کنید:

     bin/kafka-server-start.sh config/server.properties


    به همین راحتی Kafka Server اجرا شده و آماده‌ی استفاده است. برای ادامه و نمایش دادن سایر قابلیت‌های Kafka باید یک Topic جدید را ایجاد کنیم.


    ایجاد Topic:

    همانطور که می‌دانید تمامی پیامهای شما در Partition‌های Topic ذخیره می‌شوند؛ پس قبل از اینکه بخواهیم توسط یک Producer پیامی را ارسال کنیم یا اینکه بخواهیم توسط Consumer پیامی را دریافت کنیم، ابتدا باید Topic مربوطه را ایجاد کنیم. بهترین و عمومی‌ترین مثال برای نمایش قابلیت‌های Publish-Subscribe در Kafka، مثال چت بین کاربران است که در آن یک کاربر به عنوان Producer عمل می‌کند و پیامهایی را برای سایر کاربران که نقش Consumer را دارند ارسال می‌کند. kafka-topics.sh در Kafka ابزاریست برای مدیریت Topic ها  که با استفاده از آن می‌توانید Topic‌های مورد نیاز را تعریف، ویرایش و یا حذف کنید.

    یک terminal جدید را آغاز و با استفاده از دستور زیر یک Topic را با نام userChat ایجاد کنید:

    bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic userChat

    با این دستور یک Topic در Kafka با نام userChat ایجاد می‌شود و مشخصات آن (منظور stateهای مرتبط با آن است)، در zookeeper نیز ثبت می‌شود.


    توضیحات Optionها و  آرگومانهایی که در دستور ایجاد Topic استفاده شدند به شرح زیر است:

    create-- :

    مشخص کننده این است که شما می‌خواهید یک Topic جدید را ایجاد کنید.

    zookeeper localhost:2181--:

    مشخص کننده آدرس سرور zookeeper است (سرور zookeeper بصورت پیشفرض از پورت 2181 استفاده می‌کند).

    replication-factor 1--:

    مشخص کننده این است که تنها یک کپی از این Topic در سرور ایجاد شود. البته در این مثال به دلیل اینکه تنها یک سرور از Kafka را اجرا کرده‌ایم در صورتیکه این مقدار را بیش از عدد 1 در نظر بگیریم، با خطا مواجه می‌شویم. 

    partitions 1--

    تعداد Partition‌های این Topic را مشخص می‌کند. مقدار Partition در حالتیکه حتی یک سرور را نیز اجرا کرده‌ایم، می‌تواند بیش از 1 باشد؛ اما در این حالت Primary Broker برای تمام Partition‌های همین سرور در نظر گرفته می‌شود. 

    topic userChat--

    نام Topic را مشخص می‌کند.


    پس از اینکه Topic مورد نظر ایجاد شد، با استفاده از دستور زیر می‌توانیم لیست Topic‌های ایجاد شده را مشاهده کنیم:

     bin/kafka-topics.sh --list --zookeeper localhost:2181


    توضیحات Optionها و آرگومانهایی که در دستور نمایش لیست  Topicها استفاده شدند به شرح زیر است: 

    list--:

    شما می‌خواهید لیست topic‌ها را مشاهده کنید.

    zookeeper localhost:2181--:

    همانند دستور ایجاد، مشخص کننده سرور zookeeper می‌باشد.


    تا اینجا برای ارسال و دریافت پیام در بین Application‌های مختلف همه چیز آماده‌است. البته همانطور که در بخش‌های بعدی این سری مقالات می‌بینیم، در عمل Producer‌ها و Consumer‌ها زیرسیستمهایی هستند که خود ما با استفاده از هر زبان برنامه نویسی پیاده سازی می‌کنیم. اما در این قسمت برای نمایش و تکمیل مثالمان، از ابزارهایی که خود Kafka در اختیار ما قرار داده استفاده می‌کنیم.


    اجرای یک Producer و ارسال پیام به Kafka:

    kafka-console-producer.shابزاریست که با استفاده از آن می‌توانید به راحتی یک Producer را ایجاد کنید. در terminalی که قبلا برای مدیریت Topicها باز کرده‌اید با استفاده از دستور زیر، Producer را اجرا می‌کنیم:

    bin/kafka-console-producer.sh --broker-list localhost:9092 --topic userChat


    توضیحات Optionها و آرگومانهایی که در دستور ایجاد Producer استفاده شدند به شرح زیر است:  

    broker-list localhost:9092--:

    نشان دهنده لیست Broker‌ها می‌باشد و در صورتیکه تعداد آنها بیش از یک باشد، می‌توان آنها را با "," از هم جدا کرد (پورت پیشفرض Kafka server برای دریافت دستورات، 9092 می‌باشد).

    topic userChat--:

    Topicی از Kafka server را مشخص می‌کند که این Producer می‌خواهد پیامهای خود را برایش ارسال کند.


    پس از اجرای دستور فوق، با تایپ کردن و زدن کلید Enter، پیام مورد نظر به Broker موردنظر یعنی localhost:9092 ارسال و در تنها Partition تاپیک userChat ذخیره می‌شود.


    اجرای یک Consumer و دریافت پیامهای موجود در Topic مورد نظر:

    kafka-console-consumer.sh ابزاریست که خود Kafka در اختیار ما قرار داده است و با استفاده از آن می‌توانیم به راحتی یک Consumer برای  userChat ،Topic ایجاد کنیم.

    در یک terminal جدید با استفاده از دستور زیر یک Consumer را ایجاد کنید که userChat  ،Topic را Subscribe می‌کند:

     bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic userChat --from-beginning


    توضیحات Optionها و آرگومانهایی که در دستور ایجاد یک Consumer استفاده شدند به شرح زیر است:  

    bootstrap-server localhost:9092-- :

    مشخص کننده Kafka serverی است که می‌خواهیم از طریق آن به تمامی اعضای Cluster دسترسی داشته باشیم. در صورتیکه بیش از یک سرور را بخواهیم وارد کنیم، باید آنها را با  "," از هم جدا کنیم.

    topic userChat --:

    مشخص کننده Topicی است که این Consumer میخواهد روی آن Subscribe کند.

    from-beginning--:

     مشخص کننده این است که Consumer ایجاد شده می‌خواهد تمامی پیامهای موجود در userChat ، Topic را از اولین offset تا آخرین offset دریافت کند.

    پس از اجرای کد فوق مشاهده می‌کنید که پیامهایی که قبلا Producer در تاپیک userChat ثبت کرده‌است، برای این Consumer ارسال می‌شوند.


    از اینجا به بعد هر لحظه که در terminal ارسال کننده یا Producer پیامی تایپ کنید و کلید Enter را بزنید، بلافاصله پیام مورد نظر برای Consumer ارسال می‌شود و در terminal آن نمایش داده می‌شود. حتی می‌توانیم چندین Consumer را در terminal ‌های مختلفی اجرا کنیم. در این صورت با ارسال هر پیام از طرف Producer، تمامی Consumer‌ها آن را نمایش می‌دهند.


    با استفاده از سادگی راه اندازی و قابلیتهای بسیار زیادی که Apache Kafka در مدیریت  جریان داده‌ای بین سیستم‌هایمان به ما می‌دهد، می‌توانیم به سادگی در سیستم‌هایمان   قابلیتهای مقیاس پذیری افقی، تحمل در برابر خطا، در دسترس بودن، کارآیی بالا و سادگی مدیریت ارتباطات بخشهای مختلف را اضافه کنیم. در بخشهای بعدی به نحوه ایجاد یک Cluster و اینکه چگونه می‌توان از این بستر در Net. استفاده کرد، می‌پردازیم.

    ‫چقدر سی‌شارپ را می‌شناسیم؟!

    $
    0
    0
    هر چند که #C به عنوان یک زبان ساده برای درک و یادگیری شناخته میشود، گاهی رفتاری غیرمنتظره را حتی برای توسعه دهنده‌های با تجربه خواهد داشت. در این نوشته مروری بر بعضی از این رفتارها و توضیح دلایل پشت آن خواهیم کرد.

    Value 

    اگر مقدار null مدیریت نشود، میتواند باعث ایجاد نتایج نامطلوب، یا باعث از کار افتادن برنامه شود. شئ null به خودی خود مخرب نیست؛ اما اگر بخواهیم به یکی از متدها یا خاصیت‌های آن دسترسی داشته باشیم، با استثنای معروف NullReferenceException روبرو می‌شویم. برای در امان ماندن، باید همیشه اطمینان داشته باشیم که پیش از استفاده از امکانات شئ، ارجاع آن null نباشد. در قطعه کد زیر برخی از رفتارهای null value آورده شده:
    // Behavior 1 
    object obj = null;
    bool objValueEqual = obj.Equals(null);
    
    // Behavior 2 
    object obj = null;
    Type objType = obj.GetType();
    
    // Behavior 3
    string str = (string)null;
    bool strType = str is string;
    
    // Behavior 4
    int num = 5;
    Nullable<int> nullableNum = 5;
    bool typeEqual = num.GetType() == nullableNum.GetType();
    
    // Behavior 5
    Type inType = typeof(int);
    Type nullableIntType = typeof(Nullable<int>);
    bool typeEqual = inType == nullableIntType;
    • در رفتار اول هرچند که متد Equals از شی null در دسترس است و با مقدار null مقایسه شده اما در زمان اجرا پیغام خطای NullReferenceException را خواهیم داشت. 
    • در رفتار دوم هم پیغام خطا را خواهیم داشت. شئ با مقدار null، در زمان اجرا هیچ نوعی را برنمیگرداند. 
    • در رفتار سوم هر چند که مقدار null صریحا به رشته تبدیل شده و برای چاپ متغیر str پیام خطایی را نخواهیم داشت، اما متغیر strType در خروجی، false خواهد بود. همانطور که در رفتار دوم گفته شد، شیء با مقدار null هیچ نوعی را برنمیگرداند. 
    • خروجی رفتار چهارم true خواهد بود. به این صورت که هر دو از نوع System.int32 خواهند بود.
    • در رفتار پنجم اگر از نوع‌ها، خروجی جداگانه بگیریم، خواهیم دیدکه نوع int از System.int32 و <Nullable<int از نوع System.Nullable`1[System.Int32] میباشند، در نتیجه خروجی false است. اشیای nullable بعد از اینکه مقداری مشخص را دریافت کردند، به صورت یک شیء غیر nullable رفتار خواهند کرد.

      مدیریت مقادیر null در سربارگذاری متدها   

              static void Main(string[] args)        {            Console.WriteLine(Method(null));            Console.ReadLine();        }        private static string Method(object obj)        {            return "Object parameter";        }        private static string Method(string str)        {            return "String parameter";        }
      در قطعه کد بالا، فراخوانی متد سربارگذاری شده با مقدار ورودی null، باعث اجرای متدی میشود که پارامتر ورودی آن از نوع رشته است. تا زمانیکه یکی از پارامترها بتواند به دیگری تبدیل شود، برنامه بدون خطا کامپایل خواهد شد. اما اگر هیچ تبدیل نوعی بین پارامترها وجود نداشته باشد، کد کامپایل نخواهد شد. بین متدهای سربارگذاری شده، متدی که نوع پارامتر آن مشخص‌تر است، فراخوانی میشود. برای اینکه متد خاصی را مجبور به اجرا کنیم، باید مقدار null را پیش از ارسال، به نوع پارامتر آن متد تبدیل کنید.(object)null

      رفتارهای ()Math.Round

      var rounded = Math.Round(1.5); // 2
      var rounded = Math.Round(2.5); // 2
      
      var rounded = Math.Round(2.5, MidpointRounding.ToEven); // 2
      var rounded = Math.Round(2.5, MidpointRounding.AwayFromZero); // 3
      
      var value = 1.4f;
      var rounded = Math.Round(value + 0.1f); // 1
      متد Round از کلاس Math، ورودی را که عددی اعشاری است، گرد میکند. اگر مقدار اعشار کمتر از ۰.۵ باشد، به سمت پایین و اگر بیشتر از ۰.۵ باشد، به سمت بالا گرد میشود. اما اگر ورودی دقیقا مقدار اعشاری ۰.۵ را داشته باشد چطور؟ متد Round به صورت پیش‌فرض ورودی  را به نزدیکترین عدد زوج گرد میکند، به این دلیل خط‌های ۱ و ۲ از قطعه کد بالا، خروجی یکسان ۲ را خواهند داشت. این متد آرگومان دومی هم دارد که دو حالت MidpointRounding.ToEven و MidpointRounding.AwayFromZero را می‌توان برای آن مشخص کرد. ToEven همان رفتار پیش‌فرض متد است که ورودی را به نزدیکترین عدد زوج گرد میکند و از حالت AwayFromZero میشود برای گرد کردن ورودی به عدد بزرگتر استفاده کرد (خط ۵). 
      در خط ۸ یک حالت خاص دیگر نیز داریم. انتظار میرود که خروجی، به نزدیکترین عدد زوج گرد شود و نتیجه ۲ باشد؛ مثل خط ۱، اما خروجی ۱ خواهد بود. وقتی ورودی‌ها را از نوع float در نظر بگیریم، مقدار 0.1f کمی کمتر از ۰.۱ خواهد بود و نتیجه محاسبه کمی کمتر از ۱.۵. برای پرهیز از این مسئله بهتر است ورودی متد Round را از نوع decimal در نظر بگیریم.
       

      مقدار دهی اولیه کلاسها 

      پیشنهاد میشود برای جلوگیری از وقوع استثناءها از مقدار دهی اولیه کلاسها در سازنده کلاس، بخصوص اگر سازنده استاتیک داشته باشیم، پرهیز کنیم. ترتیب مقدار دهی اولیه زمانیکه از یک کلاس یه وهله ساخته میشود، به قرار زیر است:
      • فیلدهای استاتیک (زمانیکه کلاس برای اولین بار در دسترس قرار میگیرد)
      • سازنده استاتیک (زمانیکه کلاس برای اولین بار در دسترس قرار میگیرد)
      • فیلدهایی از کلاس که در نمونه ساخته شده در دسترس قرار میگیرند.
      • سازنده کلاس که در زمان ایجاد یک نمونه از کلاس در دسترس قرار میگیرد.
      در قطعه کد زیر اگر نمونه‌ای از کلاس FailingClass ساخته شود، انتظار میرود که خطای InvalidOperationException صادر شود؛ اما برنامه با خطای TypeInitializationException متوقف میشود. در واقع در زمان اجرا به صورت خودکار خطای TypeInitializationException، خطای InvalidOperationException را پوشش میدهد. اگر بجای  InvalidOperationException یک دستور ساده WriteLine داشته باشیم، سازنده کلاس FailingClass مجال کامل شدن را خواهد داشت. اما با خطایی که داخل سازنده صادر کرده‌ایم، سازنده کلاس بدون اینکه به طور کامل به پایان برسد، متوقف خواهد شد. 
          public static class Config
          {
              public static bool ThrowException { get; set; } = true;
          }
      
          public class FailingClass
          {
              static FailingClass()
              {
                  if (Config.ThrowException)
                  {
                      throw new InvalidOperationException();
                  }
              }
          }
      حال که میدانیم خطای اصلی که در این مواقع صادر میشود چیست، شاید بخواهیم به روش زیر آن را مدیریت کنیم.
      try
      {
         var failedInstance = new FailingClass();
      }
      catch (TypeInitializationException) { }
      
      Config.ThrowException = false;
      var instance = new FailingClass();
      اگر قطعه کد بالا را بدون بخش try  اجرا کنیم، برنامه ابتدا صدور خطا را false میکند و بدون مشکل از کلاس نمونه‌ای ساخته میشود. اما اگر بخش try را داشته باشیم، هر چند که خطا در بخش try گرفته میشود و تنظیم صدور خطا false است، باز هم در خط آخر و در زمان ایجاد یک نمونه از کلاس، پیام خطای TypeInitializationException خواهیم داشت. علت آن است که سازنده استاتیک کلاس فقط یک بار فراخوانی میشود و اگر در این فراخوانی خطایی رخ دهد، این خطا در اثر ایجاد سایر نمونه‌ها و یا استفاده مستقیم از کلاس، مجددا صادر خواهد شد. در نتیجه این کلاس تا زمانیکه پردازش آن در جریان است، غیرقابل استفاده خواهد بود. یک مثال دیگر از ترتیب فراخوانی‌ها را بررسی میکنیم.
      public class BaseClass
      {
          {
              public BaseClass()
              {
                  VirtualMethod(1);
              }
              public virtual int VirtualMethod(int dividend)
              {
                  return dividend / 1;
              }
          }
      
          public class DerivedClass : BaseClass
          {
              int divisor;
              public DerivedClass()
              {
                  divisor = 1;
              }
              public override int VirtualMethod(int dividend)
              {
                  return base.VirtualMethod(dividend / divisor);
              }
          }
      در قطعه کد بالا هر چند که همه چیز درست به نظر میرسد، اما اگر از کلاس DerivedClass نمونه‌ای ساخته شود، با پیام خطای DivideByZeroException مواجه میشویم. علت این مشکل ترتیب مقدار دهی اولیه در کلاسهای فرزند است. ابتدا فیلدهای کلاس فرزند مقدار دهی میشوند و بعد فیلدهای کلاس پایه، بعد سازنده کلاس پایه فراخوانی میشود و پس از آن سازنده کلاس فرزند. ترتیب فراخوانی‌ها به همین جا محدود نمیشود. 
      در مثال بالا متد VirtualMethod که در سازنده کلاس پایه فراخوانی شده، پیش از این که کد داخل خود را اجرا کند، متد VirtualMethod را در کلاس فرزند، فراخوانی میکند و کلاس فرزند مجالی را برای مقدار دهی متغیر divisor، در سازنده خود نخواهد داشت. در نتیجه مقدار این متغیر در متد VirtualMethod صفر خواهد ماند و باعث صدور استثناء میشود. برای پرهیز از چنین مشکلاتی بهتر است فیلدهای یک کلاس به صورت مستقیم مقدار دهی اولیه بشوند. مقدار دهی اولیه و یا فراخوانی متدهای virtual در سازنده کلاس‌ها میتواند باعث بروز رفتارهای پیش بینی نشده‌ای شوند.

      چند ریختی 

       چند ریختی قابلیتی است برای کلاسهای متفاوت تا بتوانند یک اینترفیس مشابه را به صورت‌های مختلفی پیاده‌سازی کنند. اما قطعه کد زیر قاعده چند ریختی را نقض میکند. 
       class Program
          {
              static void Main(string[] args)
              {
                  var instance = new DerivedClass();
                  var result = instance.Method();
                  result = ((BaseClass)instance).Method();
                  Console.WriteLine(instance + " -> " + result); // Derived Class ...  -> Method in BaseClass
                  Console.ReadLine();
      
              }
          }
      
          public class BaseClass
          {
              public virtual string Method()
              {
                  return "Method in BaseClass";
              }
          }
      
          public class DerivedClass : BaseClass
          {
              public override string ToString()
              {
                  return "Derived Class ... ";
              }
      
              public new string Method()
              {
                  return "Method in DerivedClass";
              }
          }
      در خروجی کنسول هرچند که Instance همچنان وهله‌ای از DerivedClass است اما به دلیل تبدیل در خط ۷، Method کلاس DerivedClass به وسیله کلاس پایه پنهان شده و Method کلاس پایه فراخوانی میشود. در قطعه کد زیر حالت مشابه‌ای را که در بالا داشتیم، برای interface‌ها دیده میشود.
      class Program
          {
              static void Main(string[] args)
              {
                  var instance = new DerivedClass();
                  var result = instance.Method(); // -> Method in DerivedClass
                  result = ((IInterface)instance).Method(); // -> Method belonging to IInterface
                  Console.WriteLine(result);
                  Console.ReadLine();
              }
          }
      
          public interface IInterface
          {
              string Method();
          }
      
          public class DerivedClass : IInterface
          {
              public string Method()
              {
                  return "Method in DerivedClass";
              }
              string IInterface.Method()
              {
                  return "Method belonging to IInterface";
              }
      }
      هرچند که به نظر میرسد دلیلی برای استفاده از روشهای گفته شده وجود ندارد، اما اگر بخواهیم بیش از یک پیاده‌سازی را برای یک متد در یک کلاس داشته باشیم، میتواند مورد توجه قرار گیرد. بخصوص اگر نیاز باشد که پیاده‌سازی دوم خودش به طور مستقلی در کلاسی دیگر استفاده شود.

      Iterators 

      Iterator‌ها (تکرار شونده‌ها) ساختارهایی هستند که برای حرکت در عناصر یک collection استفاده میشوند. عموما از دستور foreach استفاده و نوع جنریک <IEnumerable<T را نمایندگی میکنند. هر چند که استفاده از آنها ساده است، اما اگر کارکرد داخلی iteratorها را درک نکنیم ممکن است به دام استفاده نادرست از آنها گرفتار شویم. در قطعه کد زیر کلاس Test صدا زده میشود و مقادیر یک تا پنج به صورت یک IEnumerable از داخل بلوک using بازگشت داده میشود. 
      private IEnumerable<int> GetEnumerable(StringBuilder log)
      {
           using (var test = new Test(log))
            {
                return Enumerable.Range(1, 5);
            }
      }

      فرض کنیم کلاس Test اینترفیس IDisposable را پیاده‌سازی کرده و در سازنده و متد Dispose خود پیامهایی را به log اضافه کند. در مثالهای واقعی، کلاس Testمیتواند اتصالی به پایگاه داده باشد و رکوردهای خوانده شده، بازگشت داده شوند. توسط حلقه زیر مقدار خروجی تابع را چاپ میکنیم.
      var log = new StringBuilder();
      foreach (var number in GetEnumerable(log))
      {
           log.AppendLine($"{number}");
      }
      انتظار میرود که خروجی به این صورت باشد که ابتدا رشته Created (از سازنده کلاس Test) چاپ شود بعد اعداد یک تا پنج و در نهایت رشته Disposed (از متد Dispose کلاس Test). به عبارتی در ابتدای کار، بلوک using، سازنده کلاس را فراخوانی کند و بعد از اینکه بلوک به پایان کارش رسید متد Dispose کلاس فراخوانی شود. اما در واقع خروجی به صورت زیر خواهد بود. 
      Created
      Disposed
      1
      2
      3
      4
      5
      این تفاوت در دنیای واقعی مهم است؛ به اینصورت که مثلا اتصال به پایگاه داده قبل از اینکه داده‌ها خوانده شوند، بسته میشود و قطعه کد به درستی عمل نخواهد کرد. تنها راه حل، پیمایش در collection داخل using و بازگشت هر مقدار به صورت مجزا است، که در زیر آمده است.
       using (var test = new Test(log))
       {
           foreach (var i in Enumerable.Range(1,5))
           {
               yield return i;
           }
       }
      فقط در این صورت است که کلاس Test بعد از اتمام کار حلقه و در زمان درست به پایان میرسد. توسط کلمه کلیدی yield و برای متدی که خروجی قابل پیمایش داشته باشد میتوان چندین مقدار را بازگشت داد. ترتیب اجرای دستورات در قطعه کد بالا به این صورت است که ابتدا نمونه‌ای از کلاس Test ایجاد میشود و سازنده کلاس فراخوانی میشود، سپس حلقه foreach به تعداد مشخص شده در Range مقادیر بازگشتی را در خروجی تابع قرار میدهد. وقتی که کار حلقه تمام شد، بلوک using دستورات را ادامه خواهد داد که برابر با خاتمه دادن به تمام نمونه‌ها و منابع استفاده شده در بلوک است؛ یعنی فراخوانی متد Dispose. با استفاده از این روش خروجی به شکل زیر خواهد بود. 
      Created
      1
      2
      3
      4
      5
      Disposed

      ‫امکان یافتن پیش از موعد مشکلات قالب‌های Angular در نگارش 5 آن

      $
      0
      0
      مشکلات کامپوننت‌های Angular را چون با زبان TypeScript تهیه می‌شوند، می‌توان بلافاصله در ادیتور مورد استفاده و یا در حین کامپایل برنامه مشاهده کرد؛ اما یک چنین بررسی در مورد قالب‌های HTML ایی آن در زمان کامپایل انجام نمی‌شود و اگر مشکلی وجود داشته باشد، این مشکلات را صرفا در زمان اجرای برنامه در مرورگر می‌توان مشاهده کرد. برای رفع این مشکل و بهبود این وضعیت، در نگارش 5.2.0 فریم ورک Angular (و همچنین Angular CLI 1.7 به بعد)، پرچم جدیدی به تنظیمات کامپایلر آن اضافه شده‌است که با فعالسازی آن، مشکلات binding احتمالی در قالب‌های کامپوننت‌ها را می‌توان یافت. زمانیکه توسط Angular CLI یک برنامه‌ی Angular را در حالت AoT کامپایل می‌کنیم، کامپایلر مراحلی را طی می‌کند که توسط آن کدهای یک قالب کامپوننت، تبدیل به دستور العمل‌هایی قابل اجرای در مرورگر می‌شوند. در طی یکی از این مراحل، کامپایلر قالب‌های Angular، از کامپایلر TypeScript برای اعتبارسنجی عبارت‌های binding استفاده می‌کند. اکنون می‌توان خروجی این مرحله را نیز در حین کار با Angular CLI، مشاهده و مشکلات گزارش شده‌ی توسط آن‌را برطرف کرد.


      فعالسازی بررسی مشکلات قالب‌های کامپوننت‌ها

      برای فعالسازی بررسی مشکلات قالب‌های کامپوننت‌ها، نیاز است به فایل تنظیمات کامپایلر TypeScript و یا همان tsconfig.json مراجعه کرد و سپس قسمت جدیدی را به آن به نام angularCompilerOptions، افزود:
      {
        "compilerOptions": {
          "experimentalDecorators": true,
          ...
         },
         "angularCompilerOptions": {
           "fullTemplateTypeCheck": true,
           "preserveWhiteSpace": false,
           ...
         }
       }
      - در اینجا با معرفی خاصیت fullTemplateTypeCheck و تنظیم آن به true، مشکلات موجود در قالب‌ها را در زمان کامپایل برنامه می‌توانید مشاهده کنید.
      - البته این خاصیت در حین استفاده‌ی از یکی از دستورات ng serve --aot  و یا  ng build --prod انتخاب می‌شود.
      - مقدار این پرچم در نگارش‌های 5x به صورت پیش‌فرض به false تنظیم شده‌است؛ اما در نگارش 6 آن به true تنظیم خواهد شد. بنابراین بهتر است از هم اکنون کار با آن‌را شروع کنید.


      یک مثال: بررسی خاصیت fullTemplateTypeCheck

      فرض کنید اینترفیس یک مدل را به صورت زیر تعریف کرده‌اید که فقط دارای خاصیت name است:
      export interface PonyModel {
         name: string;
      }
      سپس یک خاصیت عمومی را بر همین مبنا در کامپوننتی، تعریف و مقدار دهی اولیه کرده‌اید:
      import { PonyModel } from "./pony";
      
      @Component({
        selector: "app-detect-common-errors-test",
        templateUrl: "./detect-common-errors-test.component.html",
        styleUrls: ["./detect-common-errors-test.component.css"]
      })
      export class DetectCommonErrorsTestComponent implements OnInit {
      
        ponyModel: PonyModel = { name: "Pony1" };
      اکنون در قالب این کامپوننت، به شکل زیر از این وهله استفاده شده‌است:
      <p>Hello {{ponyModel.age}}

      در این حالت اگر fullTemplateTypeCheck فعال شده باشد و دستور ng build --prod را صادر کنیم، به خروجی ذیل خواهیم رسید:
       \detect-common-errors-test.component.html(5,4): : Property 'age' does not exist on type 'PonyModel'.
      همانطور که ملاحظه می‌کنید اینبار خطاهای کامپایل فایل html نیز در خروجی کامپایلر ظاهر شده‌است و عنوان می‌کند خاصیت age در اینترفیس PonyModel وجود خارجی ندارد.

      برای اینکه بتوانید به حداکثر کارآیی این قابلیت برسید، بهتر است گزینه‌ی strict را در تنظیمات کامپایلر TypeScript روشن کنید و خودتان را به کار با نوع‌های نال نپذیرعادت دهید. به این ترتیب می‌توانید تعداد خطاهای احتمالی بیشتری را پیش از موعد و پیش از وقوع آن‌ها در زمان اجرا، در زمان کامپایل، پیدا و رفع کنید.


      یک نکته‌ی تکمیلی
      افزونه‌ی Angular Language serviceنیز یک چنین قابلیتی را به همراه دارد (و حتی در نگارش‌های پیش از 5 نیز قابل استفاده است).

      ‫طراحی یک گرید با jQuery Ajax و ASP.NET MVC به همراه پیاده سازی عملیات CRUD

      $
      0
      0

      هدف، ارائه راه‌حلی برای نمایش جدولی اطلاعات، جستجو، مرتب سازی و صفحه بندی و همچنین انجام عملیات ثبت، ویرایش و حذف بر روی آنها به صورت Ajaxای در بخش back office نرم افزار می‌باشد.

      پیش نیازها:

      ایده کار به این شکل می‌باشد که برای نمایش اطلاعات به صورت جدولی با قابلیت‌های مذکور، لازم است یک اکشن Index برای نمایش اولیه و صفحه اول اطلاعات صفحه بندی شده و اکشن متدی به نام List برای پاسخ به درخواست‌های صفحه بندی، مرتب سازی، تغییر تعداد آیتم‌ها در هر صفحه و همچنین جستجو، داشته باشیم که این اکشن متد List، بعد از واکشی اطلاعات مورد نظر از منبع داده، آنها را به همراه اطلاعاتی که در کوئری استرینگ درخواست جاری وجود دارد در قالب یک PartialView به کلاینت ارسال کند.


      ایجاد مدل‌های پایه

      همانطور که در مقاله «طراحی و پیاده سازی ServiceLayer به همراه خودکارسازی Business Validationها» مطرح شد، برای پیاده سازی متدهای GetPagedList در ApplicationService‌ها از الگوی Request/Response استفاده می‌کنیم. برای این منظور واسط و کلاس‌های زیر را خواهیم داشت:

      واسط IPagedQueryModel

          public interface IPagedQueryModel
          {
              int Page { get; set; }
              int PageSize { get; set; }
      
              /// <summary>
              ///     Expression of Sorting.
              /// </summary>
              /// <example>
              ///     Examples:
              ///     "Name_ASC"
              /// </example>
              string SortExpression { get; set; }
          }

      این واسط قراردادی می‌باشد برای نوع و نام پارامترهایی که توسط کلاینت به سرور ارسال می‌شود. پراپرتی SortExpression آن، نام و ترتیب مرتب سازی را مشخص می‌کند؛ برای این منظور FieldName_ASC و FieldName_DESC به ترتیب برای حالات مرتب سازی صعودی و نزولی براساس FieldName مقدار دهی خواهد شد.

      برای جلوگیری از تکرار این خصوصیات در مدل‌های کوئری مربوط به موجودیت‌ها، میتوان کلاس پایه‌ای به شکل زیر در نظر گرفت که پیاده ساز واسط بالا می‌باشد:

        public class PagedQueryModel : IPagedQueryModel, IShouldNormalize
          {
              public int Page { get; set; }
              public int PageSize { get; set; }
      
              /// <summary>
              ///     Expression of Sorting.
              /// </summary>
              /// <example>
              ///     Examples:
              ///     "Name_ASC"
              /// </example>
              public string SortExpression { get; set; }
      
              public virtual void Normalize()
              {
                  if (Page < 1)
                      Page = 1;
      
                  if (PageSize < 1)
                      PageSize = 10;
      
                  if (SortExpression.IsEmpty())
                      SortExpression = "Id_DESC";
              }
          }

      مدل بالا علاوه بر پیاده سازی واسط IPagedQueryModel، پیاده ساز واسط IShouldNormalize نیز می‌باشد؛ دلیل وجود چنین واسطی در مقاله «طراحی و پیاده سازی ServiceLayer به همراه خودکارسازی Business Validationها» توضیح داده شده است:

      پیاده سازی واسط IShouldNormalize باعث خواهد شد که قبل از اجرای خود متد، این نوع پارامترها با استفاده از یک Interceptor شناسایی شده و متد Normalize آنها اجرا شود.

      کلاس PagedQueryResult

          public class PagedQueryResult<TModel>
          {
              public PagedQueryResult()
              {
                  Items = new List<TModel>();
              }
              public IEnumerable<TModel> Items { get; set; }
              public long TotalCount { get; set; }
          }

      دلیل وجود کلاس بالا در مقاله «طراحی یک گرید با Angular و ASP.NET Core - قسمت اول - پیاده سازی سمت سرور» توضیح داده شده است:

      عموما ساختار اطلاعات صفحه بندی شده، شامل تعداد کل آیتم‌های تمام صفحات (خاصیت TotalItems) و تنها اطلاعات ردیف‌های صفحه‌ی جاری درخواستی (خاصیت Items) است و چون در اینجا این Items از هر نوعی می‌تواند باشد، بهتر است آن‌را جنریک تعریف کنیم.

      کلاس PagedListModel

      همانطور که در اول بحث توضیح داده شد، لازم است اطلاعاتی را که کلاینت از طریق کوئری استرینگ برای صفحه بندی و ... ارسال کرده بود نیز به PartialView ارسال کنیم. این قسمت کار ایده اصلی این روش را در بر می‌گیرد؛ اگر نخواهیم اطلاعات کوئری استرینگ دریافتی از کلاینت را دوباره به PartialView ارسال کنیم، مجبور خواهیم بود تمام کارهای مربوط به تشخیص آیکن مرتب سازی ستون‌های جدول، ریست کردن المنت‌های مربوط به صفحه بندی و مرتب سازی را در در زمان انجام جستجو  و یکسری کارهای از این قبل را در سمت کلاینت مدیریت کنیم که هدف مقاله جاری پیاده سازی این روش نمی‌باشد.

          public class PagedListModel<TModel>
          {
              public IPagedQueryModel Query { get; set; }
      
              public PagedQueryResult<TModel> Result { get; set; }
          }

      پراپرتی Query در برگیرنده پارامتر ورودی اکشن متد List می‌باشد که پراپرتی‌های آن با مقادیر موجود در کوئری استرینگ درخواست جاری مقدار دهی شده‌اند؛ البته بدون وجود کلاس بالا نیز به کمک ViewBag می‌شود این اطلاعات ترکیبی را به ویو ارسال کرد که پیشنهاد نمی‌شود.


      متد GetPagedListAsync موجود در CrudApplicationService

          public abstract class CrudApplicationService<TEntity, TModel, TCreateModel, TEditModel, TDeleteModel,
              TPagedQueryModel, TDynamicQueryModel> : ApplicationService,
              ICrudApplicationService<TModel, TCreateModel, TEditModel, TDeleteModel, TPagedQueryModel, TDynamicQueryModel>
              where TEntity : Entity, new()
              where TCreateModel : class
              where TEditModel : class, IModel
              where TModel : class, IModel
              where TDeleteModel : class, IModel
              where TPagedQueryModel : PagedQueryModel, new()
              where TDynamicQueryModel : DynamicQueryModel
      
          {
      
              #region Properties
      
              protected IQueryable<TEntity> UnTrackedEntitySet => EntitySet.AsNoTracking();
              public IUnitOfWork UnitOfWork { get; set; }
              public IMapper Mapper { get; set; }
              protected IDbSet<TEntity> EntitySet => UnitOfWork.Set<TEntity>();
      
              #endregion
      
              #region ICrudApplicationService Members
      
              #region Methods
      
              public virtual async Task<PagedQueryResult<TModel>> GetPagedListAsync(TPagedQueryModel model)
              {
                  Guard.ArgumentNotNull(model, nameof(model));
      
                  var query = ApplyFiltering(model);
      
                  var totalCount = await query.LongCountAsync().ConfigureAwait(false);
      
                  var result = query.ProjectTo<TModel>(Mapper.ConfigurationProvider);
      
                  result = result.ApplySorting(model);
                  result = result.ApplyPaging(model);
      
                  return new PagedQueryResult<TModel>
                  {
                      Items = await result.ToListAsync().ConfigureAwait(false),
                      TotalCount = totalCount
                  };
              }
              #endregion
      
              #endregion
      
              #region Protected Methods
      
              /// <summary>
              ///     Apply Filtering To GetPagedList and GetPagedListAsync
              /// </summary>
              /// <param name="model"></param>
              /// <returns></returns>
              protected virtual IQueryable<TEntity> ApplyFiltering(TPagedQueryModel model)
              {
                  Guard.ArgumentNotNull(model, nameof(model));
      
                  return UnTrackedEntitySet;
              }
              #endregion
          }

      در بدنه این متد، ابتدا عملیات جستجو توسط متد ApplyFiltering انجام می‌شود. این متد به صورت پیش فرض هیچ شرطی را بر روی کوئری ارسالی به منبع داده اعمال نمی‌کند؛ مگر اینکه توسط زیر کلاس‌ها بازنویسی شود و فیلترهای مورد نیاز اعمال شوند. سپس تعداد کل آیتم‌های فیلتر شده محاسبه شده و بعد از عملیات Projection، مرتب سازی و صفحه بندی انجام می‌گیرد. برای مباحث مرتب سازی و صفحه بندی از دو متد زیر کمک گرفته شده‌است:

          public static class QueryableExtensions
          {
              public static IQueryable<TModel> ApplySorting<TModel>(this IQueryable<TModel> query, IPagedQueryModel request)
              {
                  Guard.ArgumentNotNull(request, nameof(request));
                  Guard.ArgumentNotNull(query, nameof(query));
      
                  return query.OrderBy(request.SortExpression.Replace('_', ' '));
              }
      
              public static IQueryable<TModel> ApplyPaging<TModel>(this IQueryable<TModel> query, IPagedQueryModel request)
              {
                  Guard.ArgumentNotNull(request, nameof(request));
                  Guard.ArgumentNotNull(query, nameof(query));
      
                  return request != null
                      ? query.Page((request.Page - 1) * request.PageSize, request.PageSize)
                      : query;
              }
          }

      به منظور مرتب سازی از کتابخانه System.Liq.Dynamic کمک گرفته شده‌است.

      نکته: مشخص است که این روش، وابستگی به وجود متد GetPagedListAsync ندارد و صرفا برای تشریح ارتباط مطالبی که قبلا منتشر شده بود، مطرح شد.


      پیاده سازی اکشن متدهای Index و List

      public partial class RolesController : BaseController
      {
          #region Fields
              private readonly IRoleService _service;
              private readonly ILookupService _lookupService;
      
              #endregion
      
          #region Constractor
              public RolesController(IRoleService service,  ILookupService lookupService)
              {
                  Guard.ArgumentNotNull(service, nameof(service));
                  Guard.ArgumentNotNull(lookupService, nameof(lookupService));
      
                  _service = service;
                  _lookupService = lookupService;
              }
              #endregion
      
          #region Index / List
          [HttpGet]
          public virtual async Task<ActionResult> Index()
          {
              var query = new RolePagedQueryModel();
              var result = await _service.GetPagedListAsync(query).ConfigureAwait(false);
      
              var pagedList = new PagedListModel<RoleModel>
              {
                  Query = query,
                  Result = result
              };
      
              var model = new RoleIndexViewModel
              {
                  PagedListModel = pagedList,
                  Permissions = _lookupService.GetPermissions()
              };
              return View(model);
          }
          [HttpGet, AjaxOnly, NoOutputCache]
          public virtual async Task<ActionResult> List(RolePagedQueryModel query)
          {
              var result = await _service.GetPagedListAsync(query).ConfigureAwait(false);
      
              var model = new PagedListModel<RoleModel>
              {
                  Query = query,
                  Result = result
              };
      
              return PartialView(MVC.Administration.Roles.Views._List, model);
          }
          #endregion
      }

      به عنوان مثال در بالا کنترلر مربوط به گروه‌های کاربری را مشاهده می‌کنید. به دلیل اینکه علاوه بر مباحث صفحه بندی و مرتب سازی، امکان جستجو بر اساس نام و دسترسی‌های گروه کاربری را نیز نیاز داریم، لازم است مدل زیر را ایجاد کنیم:

          public class RolePagedQueryModel : PagedQueryModel
          {
              public string Name { get; set; }
              public string Permission { get; set; }
          }

      در این مورد خاص لازم است لیست دسترسی‌های موجود درسیستم به صورت لیستی برای انتخاب در فرم جستجو مهیا باشد. فرم جستجو در ویو مربوط به اکشن Index قرار می‌گیرد و قرار نیست به همراه پارشال ویو List_ در هر درخواستی از سرور دریافت شود. لذا لازم است مدلی برای ویو Index در نظر بگیریم که به شکل زیر می‌باشد:

          public class RoleIndexViewModel
          {   
              public RoleIndexViewModel()
              {
                  Permissions = new List<LookupItem>();
              }
              public IReadOnlyList<LookupItem> Permissions { get; set; }
              public PagedListModel<RoleModel> PagedListModel { get; set; }
          }

      پراپرتی PagedListModel در برگیرنده اطلاعات مربوط به نمایش اولیه جدول اطلاعات می‌باشد و پراپرتی Permissions لیست دسترسی‌های موجود درسیستم را به ویو منتقل خواهد کرد. اگر ویو ایندکس شما به داده اضافه ای نیاز ندارد، از ایجاد مدل بالا صرف نظر کنید.


      ویو Index.cshtml

      @model RoleIndexViewModel
      
      @{
          ViewBag.Title = L("Administration.Views.Role.Index.Title");
          ViewBag.ActiveMenu = AdministrationMenuNames.RoleManagement;
      }
      
      <div class="row"><div class="col-md-12"><div id="filterPanel" class="panel-collapse collapse" role="tabpanel" aria-labelledby="filterPanel"><div class="panel panel-default margin-bottom-5"><div class="panel-body">
                          @using (Ajax.BeginForm(MVC.Administration.Roles.List(),
      new AjaxOptions { UpdateTargetId = "RolesList", HttpMethod = "GET" }, new { id = "filterForm", data_submit_on_reset = "true" }))
                          {<div class="row"><div class="col-md-3"><input type="text" name="Name" class="form-control" value="" placeholder="@L("Administration.Role.Fields.Name")" /></div><div class="col-md-3">
                                      @Html.DropDownList("Permission", Model.Permissions.ToSelectListItems(), L("Administration.Views.Role.FilterBy.Permission"),new {@class="form-control"})</div><div class="col-md-3"><button type="submit"
                                              role="button"
                                              class="btn btn-info">
                                          @L("Commands.Filter")</button><button type="reset"
                                              role="button"
                                              class="btn btn-default"><i class="fa fa-close"></i>
                                          @L("Commands.Reset")</button></div></div>
                          }</div></div></div></div></div><div class="row"><div class="col-md-12" id="RolesList">
              @{Html.RenderPartial(MVC.Administration.Roles.Views._List, Model.PagedListModel);}</div></div>

      فرم جستجو باید دارای ویژگی data_submit_on_reset با مقدار "true" باشد. به منظور پاکسازی فرم جستجو و ارسال درخواست جستجو با فرمی خالی از داده، برای بازگشت به حالت اولیه از تکه کد زیر استفاده خواهد شد:

        $(document).on("reset", "form[data-submit-on-reset]",
                  function () {
                      var form = this;
                      setTimeout(function () {
                          $(form).submit();
                      });
                  });

      در ادامه پارشال ویو List_ با داده ارسالی به ویو Index، رندر شده و کار نمایش اولیه اطلاعات به صورت جدولی به اتمام می‌رسد.


      پارشال ویو List.cshtml_

      @model PagedListModel<RoleModel>
      @{
          Layout = null;
          var rowNumber = (Model.Query.Page - 1) * Model.Query.PageSize + 1;
          var refreshUrl = Url.Action(MVC.Administration.Roles.List().AddRouteValues(new RouteValueDictionary(Model.Query.ToDictionary())));
      }<div class="panel panel-default margin-bottom-5"><table class="table table-bordered table-hover" id="RolesListTable" data-ajax-refresh-url="@refreshUrl" data-ajax-refresh-update="#RolesList"><thead><tr><th style="width: 5%;">
                          #</th><th class="col-md-3 sortable">
                          @Html.SortableColumn("Name", L("Administration.Role.Fields.Name"), Model.Query, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))</th><th class="col-md-3 sortable">
                          @Html.SortableColumn("DisplayName", L("Administration.Role.Fields.DisplayName"), Model.Query, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))</th><th class="col-md-3 sortable">
                          @Html.SortableColumn("IsDefault", L("Administration.Role.Fields.IsDefault"), Model.Query, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))</th><th style="width: 5%;"></th></tr></thead><tbody>
                 @foreach (var role in Model.Result.Items)
                  {<tr><td>@(rowNumber++.ToPersianNumbers())</td><td>@role.Name</td><td>@role.DisplayName</td><td class="text-center">@Html.DisplayFor(a => role.IsDefault)</td><td class="text-center operations"><div class="btn-group"><span class="fa fa-ellipsis-h dropdown-toggle" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"></span><ul class="dropdown-menu dropdown-menu-left"><li><a href="#"
                                             role="button"
                                             data-ajax="true"
                                             data-ajax-method="GET"
                                             data-ajax-update="#main-modal div.modal-content"
                                             data-ajax-url="@Url.Action(MVC.Administration.Roles.Edit(role.Id))"
                                             data-toggle="modal"
                                             data-target="#main-modal"><i class="fa fa-pencil"></i>
                                              @L("Commands.Edit")</a></li><li><a href="#"
                                             role="button"
                                             id="delete-@role.Id"
                                             data-delete-url="@Url.Action(MVC.Administration.Roles.Delete())"
                                             data-delete-model='{"Id":"@role.Id","RowVersion":"@Convert.ToBase64String(role.RowVersion)"}'><i class="fa fa-trash"></i>
                                              @L("Commands.Delete")</a></li></ul></div></td></tr>
                  }</tbody></table></div><div class="row"><div class="col-md-8">
              @Html.Pager(Model, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))
              @Html.PageSize("RolesList", Model.Query, routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)), new { @class = "margin-right-5" }, "filterForm")
              @Html.Refresh("RolesList", Model.Query, routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)), L("Commands.Refresh"))</div></div>

      به ترتیب  فایل بالا را بررسی می‌کنیم:

          var refreshUrl = Url.Action(MVC.Administration.Roles.List().AddRouteValues(new RouteValueDictionary(Model.Query.ToDictionary())));

      refreshUrl برای ارسال درخواست به اکشن متد List در نظر گرفته شده‌است که در کوئری استرینگ مربوط به خود، اطلاعاتی (مرتب سازی، شماره صفحه، اطلاعات جستجو و همچنین تعداد آیتم‌های موجود در هر صفحه) را دارد که حالت فعلی گرید را می‌توانیم دوباره از سرور درخواست کنیم.

      <table class="table table-bordered table-hover" id="RolesListTable" data-ajax-refresh-url="@refreshUrl" data-ajax-refresh-update="#RolesList">

      دو ویژگی data-ajax-refresh-url و data-ajax-refresh-update برای جدولی که لازم است عملیات CRUD را پشتیبانی کند، لازم می‌باشد. در قسمت دوم به استفاده از این دو ویژگی در هنگام عملیات ثبت، ویرایش و حذف خواهیم پرداخت.

      <th class="col-md-3 sortable">
          @Html.SortableColumn("Name", L("Administration.Role.Fields.Name"), Model.Query, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))</th>

      ستونی که امکان مرتب سازی را دارد باید th آن، کلاس sortable را داشته باشد. همچنین باید از هلپری که پیاده سازی آن را در ادامه خواهیم دید، استفاده کنیم. این هلپر، نام فیلد، عنوان ستون، مدل Query و همچین یک urlFactory را در قالب یک ‎Func<RouteValueDictionary,string>‎ دریافت می‌کند.


      پیاده سازی هلپر SortableColumn

              public static MvcHtmlString SortableColumn(this HtmlHelper html, string columnName,
                  string columnDisplayName, IPagedQueryModel queryModel, string updateTargetId, Func<RouteValueDictionary, string> urlFactory)
              {
                  var dictionary = queryModel.ToDictionary();
      
                  var routeValueDictionary = new RouteValueDictionary(dictionary)
                  {
                      ["SortExpression"] = !queryModel.SortExpression.StartsWith(columnName)
                          ? $"{columnName}_DESC" : queryModel.SortExpression.EndsWith("DESC")
                              ? $"{columnName}_ASC" : queryModel.SortExpression.EndsWith("ASC")
                                  ? string.Empty : $"{columnName}_DESC"
                  };
      
                  var url = urlFactory(routeValueDictionary);
      
                  var aTag = new TagBuilder("a");
                  aTag.Attributes.Add("href", "#");
                  aTag.Attributes.Add("data-ajax", "true");
                  aTag.Attributes.Add("data-ajax-method", "GET");
                  aTag.Attributes.Add("data-ajax-update", updateTargetId.StartsWith("#") ? updateTargetId : $"#{updateTargetId}");
                  aTag.Attributes.Add("data-ajax-url", url);
                  aTag.InnerHtml = columnDisplayName;
      
                  var iconCssClass = !queryModel.SortExpression.StartsWith(columnName)
                      ? "fa-sort"
                      : queryModel.SortExpression.EndsWith("DESC")
                          ? "fa-sort-down"
                          : "fa-sort-up";
      
                  var iTag = new TagBuilder("i");
                  iTag.AddCssClass($"fa {iconCssClass}");
      
                  return new MvcHtmlString($"{aTag}\n{iTag}");
              }

      ابتدا مدل Query با متد الحاقی زیر تبدیل به دیکشنری می‌شود. این کار از این جهت مهم است که پراپرتی‌های لیست موجود در مدل Query، لازم است به فرم خاصی به سرور ارسال شوند که در تکه کد زیر مشخص می‌باشد.

      public static IDictionary<string, object> ToDictionary(this object source)
      {
          return source.ToDictionary<object>();
      }
      
      public static IDictionary<string, T> ToDictionary<T>(this object source)
      {
          if (source == null)
              throw new ArgumentNullException(nameof(source));
      
          var dictionary = new Dictionary<string, T>();
      
          foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(source))
          {
              AddPropertyToDictionary(property, source, dictionary);
          }
          return dictionary;
      }
      
      private static void AddPropertyToDictionary<T>(PropertyDescriptor property, object source,
          IDictionary<string, T> dictionary)
      {
          var value = property.GetValue(source);
      
          var items = value as IEnumerable;
      
          if (items != null && !(items is string))
          {
              var i = 0;
              foreach (var item in items)
              {
                  dictionary.Add($"{property.Name}[{i++}]", (T)item);
              }
          }
          else if (value is T)
          {
              dictionary.Add(property.Name, (T)value);
          }
      
      }

      در متد بالا، از TypeDescriptor که یکی دیگر از ابزار‌های دسترسی به متا دیتای انوع داده‌ای است، استفاده شده و خروجی نهایی آن یک دیکشنری با کلیدهایی با اسامی پراپرتی‌های وهله ورودی می‌باشد.

      در ادامه پیاده سازی هلپر SortableColumn، از دیکشنری حاصل، یک وهله از RouteValueDictionary ساخته می‌شود. در زمان رندر شدن PartialView لازم است مشخص شود که برای دفعه بعدی که بر روی این ستون کلیک می‌شود، باید چه مقداری با پارامتر SortExpression موجود در کوئری استرینگ ارسال شود. از این جهت برای پشتیبانی ستون، از حالت‌های مرتب سازی صعودی، نزولی و برگشت به حالت اولیه بدون مرتب سازی، کد زیر را خواهیم داشت:

      var routeValueDictionary = new RouteValueDictionary(dictionary)
      {
          ["SortExpression"] = !queryModel.SortExpression.StartsWith(columnName)
              ? $"{columnName}_DESC" : queryModel.SortExpression.EndsWith("DESC")
                  ? $"{columnName}_ASC" : queryModel.SortExpression.EndsWith("ASC")
                      ? string.Empty : $"{columnName}_DESC"
      };

      در ادامه urlFactory با routeValueDictionary حاصل، Invoke می‌شود تا url نهایی برای مرتب سازی‌های بعدی را  از طریق یک لینک تزئین شده با data اتریبیوت‌های Unobtrusive Ajax در th مربوطه قرار دهیم.

      برای مباحث صفحه بندی، بارگزاری مجدد و تغییر تعداد آیتم‌ها در هر صفحه، از سه هلپر زیر کمک خواهیم گرفت:

      <div class="row"><div class="col-md-8">
              @Html.Pager(Model, "RolesList", routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)))
              @Html.PageSize("RolesList", Model.Query, routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)), new { @class = "margin-right-5" }, "filterForm")
              @Html.Refresh("RolesList", Model.Query, routeValueDictionary => Url.Action(MVC.Administration.Roles.List().AddRouteValues(routeValueDictionary)), L("Commands.Refresh"))</div></div>


      پیاده سازی هلپر Pager

      public static MvcHtmlString Pager<TModel>(this HtmlHelper html, PagedListModel<TModel> model,
              string updateTargetId, Func<RouteValueDictionary, string> urlFactory)
      {
          return html.PagedListPager(
              new StaticPagedList<TModel>(model.Result.Items, model.Query.Page, model.Query.PageSize,
                  (int)model.Result.TotalCount), page =>
             {
                 var dictionary = model.Query.ToDictionary();
                 var routeValueDictionary = new RouteValueDictionary(dictionary) { ["Page"] = page };
                 return urlFactory(routeValueDictionary);
             }, PagedListRenderOptions.EnableUnobtrusiveAjaxReplacing(
                  new PagedListRenderOptions
                  {
                      DisplayLinkToFirstPage = PagedListDisplayMode.Always,
                      DisplayLinkToLastPage = PagedListDisplayMode.Always,
                      DisplayLinkToPreviousPage = PagedListDisplayMode.Always,
                      DisplayLinkToNextPage = PagedListDisplayMode.Always,
                      MaximumPageNumbersToDisplay = 6,
                      DisplayItemSliceAndTotal = true,
                      DisplayEllipsesWhenNotShowingAllPageNumbers = true,
                      ItemSliceAndTotalFormat = $"تعداد کل: {model.Result.TotalCount.ToPersianNumbers()}",
                      FunctionToDisplayEachPageNumber = page => page.ToPersianNumbers(),
                  },
                  new AjaxOptions
                  {
                      AllowCache = false,
                      HttpMethod = "GET",
                      InsertionMode = InsertionMode.Replace,
                      UpdateTargetId = updateTargetId
                  }));
      }

      در متد بالا از کتابخانه PagedList.Mvc استفاده شده‌است. یکی از overload‌های متد PagedListPager آن، یک پارامتر از نوع Func<int, string>‎ به نام generatePageUrl را دریافت می‌کند که امکان شخصی سازی فرآیند تولید لینک به صفحات بعدی و قبلی را به ما می‌دهد. ما نیز از این امکان برای افزودن اطلاعات موجود در مدل Query، به کوئری استرینگ لینک‌های تولیدی استفاده کردیم و صرفا برای لینک‌های ایجادی لازم بود مقادیر پارامتر Page موجود در کوئری استرینگ تغییر کند که در کد بالا مشخص می‌باشد.


      پیاده سازی هلپر PageSize

      public static MvcHtmlString PageSize(this HtmlHelper html, string updateTargetId, IPagedQueryModel queryModel, Func<RouteValueDictionary, string> urlFactory, object htmlAttributes = null, string filterFormId = null, params int[] numbers)
      {
          if (numbers.Length == 0)
              numbers = new[] { 10, 20, 30, 50, 100 };
      
          var dictionary = queryModel.ToDictionary();
      
          var routeValueDictionary = new RouteValueDictionary(dictionary)
          {
              [nameof(IPagedQueryModel.Page)] = 1
          };
          routeValueDictionary.Remove(nameof(IPagedQueryModel.PageSize));
      
          var url = urlFactory(routeValueDictionary);
      
          var formTag = new TagBuilder("form");
          formTag.Attributes.Add("action", url);
          formTag.Attributes.Add("method", "GET");
          formTag.Attributes.Add("data-ajax", "true");
          formTag.Attributes.Add("data-ajax-method", "GET");
          formTag.Attributes.Add("data-ajax-update", updateTargetId.StartsWith("#") ? updateTargetId : $"#{updateTargetId}");
          formTag.Attributes.Add("data-ajax-url", url);
      
          if (htmlAttributes != null)
              formTag.MergeAttributes(HtmlHelper.AnonymousObjectToHtmlAttributes(htmlAttributes));
      
          formTag.AddCssClass("form-inline inline");
      
          var items = numbers.Select(number =>
              new SelectListItem
              {
                  Value = number.ToString(),
                  Text = number.ToString().ToPersianNumbers(),
                  Selected = queryModel.PageSize == number
              });
      
          formTag.InnerHtml = html.DropDownList(nameof(IPagedQueryModel.PageSize), items, new { @class = "form-control page-size", onchange = "$(this.form).submit();" }).ToString();
      
          if (filterFormId.IsEmpty()) return new MvcHtmlString($"{formTag}");
      
          // ReSharper disable once MustUseReturnValue
          var scriptBlock = $"<script type=\"text/javascript\"> if(window.jQuery){{$('form#{filterFormId}').find('input[name=\"{nameof(IPagedQueryModel.PageSize)}\"]').remove();\n $('form#{filterFormId}').append(\"<input type='hidden' name='{nameof(IPagedQueryModel.PageSize)}' value='{queryModel.PageSize}'/>\")}}</script>";
      
          return new MvcHtmlString($"{formTag}\n{scriptBlock}");
      }

      ایده کار به این صورت است که یک المنت select، درون یک المنت form قرار می‌گیرد و در زمان change آن، فرم مربوطه submit می‌شود.

          formTag.InnerHtml = html.DropDownList(nameof(IPagedQueryModel.PageSize), items, new { @class = "form-control page-size", onchange = "$(this.form).submit();" }).ToString();

      در زمان تغییر تعداد نمایشی آیتم‌ها در هر صفحه، لازم است حالت فعلی گرید حفظ شود و صرفا پارامتر Page ریست شود.


      نکته مهم:در این طراحی اگر فرم جستجویی دارید، در زمان جستجو هیچیک از پارامتر‌های مربوط به صفحه بندی و مرتب سازی به سرور ارسال نخواهند شد (در واقع ریست می‌شوند) و کافیست یک درخواست GET معمولی با ارسال محتویات فرم به سرور صورت گیرد؛ ولی لازم است PageSize تنظیم شده، در زمان اعمال فیلتر نیز به سرور ارسال شود. از این جهت اسکریپتی برای ایجاد یک input مخفی در فرم جستجو نیز هنگام رندر شدن PartialView در صفحه تزریق می‌شود.

        var scriptBlock = $"<script type=\"text/javascript\"> if(window.jQuery){{$('form#{filterFormId}').find('input[name=\"{nameof(IPagedQueryModel.PageSize)}\"]').remove();\n $('form#{filterFormId}').append(\"<input type='hidden' name='{nameof(IPagedQueryModel.PageSize)}' value='{queryModel.PageSize}'/>\")}}</script>";


      پیاده سازی هلپر Refresh

      public static MvcHtmlString Refresh(this HtmlHelper html, string updateTargetId, IPagedQueryModel queryModel,
          Func<RouteValueDictionary, string> urlFactory, string label = null)
      {
          var dictionary = queryModel.ToDictionary();
      
          var routeValueDictionary = new RouteValueDictionary(dictionary);
      
          var url = urlFactory(routeValueDictionary);
      
          var aTag = new TagBuilder("a");
          aTag.Attributes.Add("href", "#");
          aTag.Attributes.Add("role", "button");
          aTag.Attributes.Add("data-ajax", "true");
          aTag.Attributes.Add("data-ajax-method", "GET");
          aTag.Attributes.Add("data-ajax-update", updateTargetId.StartsWith("#") ? updateTargetId : $"#{updateTargetId}");
          aTag.Attributes.Add("data-ajax-url", url);
          aTag.AddCssClass("btn btn-default");
      
          var iTag = new TagBuilder("i");
          iTag.AddCssClass("fa fa-refresh");
      
          aTag.InnerHtml = $"{iTag} {label}";
      
          return new MvcHtmlString(aTag.ToString());
      }

      متد بالا نیز به مانند refreshUrl که پیشتر مطرح شد، برای بارگزاری مجدد حالت فعلی گرید استفاده می‌شود و از این جهت است که مقادیر مربوط به کلیدهای routeValueDictionary  را تغییر نداده‌ایم.


      روش دیگر برای مدیریت این چنین کارهایی، استفاده از یک المنت form و قرادادن کل گرید به همراه یک سری input مخفی معادل با پارامترهای دریافتی اکشن متد List و مقدار دهی آنها در زمان کلیک بر روی دکمه‌های صفحه بندی، بارگزاری مجدد، دکمه اعمال فیلتر و لیست آبشاری تنظیم تعداد آیتم‌ها، درون آن نیز میتواند کار ساز باشد؛ اما در زمان پیاده سازی خواهید دید که پیاده سازی آن خیلی سرراست، به مانند پیاده سازی موجود در مطلب جاری نخواهد بود. 

      در قسمت دوم، به پیاده سازی عملیات ثبت، ویرایش و حذف برپایه مودال‌های بوت استرپ و افزونه Unobtrusive Ajax خواهیم پرداخت.
      کدهای کامل قسمت جاری، بعد از انتشار قسمت دوم، در مخزن گیت هاب شخصی قرار خواهد گرفت.

      ‫کنترل نرخ ورود اطلاعات در برنامه‌های Angular

      $
      0
      0
      فرض کنید قصد دارید همزمان با تایپ کاربر، نتایج جستجو را به او نمایش دهید. این جستجو نیز عموما به همراه ارسال یک درخواست HTTP به سمت سرور و نمایش اطلاعات بازگشتی به کاربر است. جهت کاهش تعداد رفت و برگشت‌های به سرور، کاهش بار سرور و همچنین کاهش تعداد بار به روز رسانی رابط کاربری، کتابخانه‌ی RxJS به همراه متدهایی است که امکان کاهش نرخ ورودی کاربر را میسر می‌کنند.


      کنترلر جستجوی سمت سرور و سرویس سمت کلاینت استفاده کننده‌ی از آن

      در اینجا کنترلر و اکشن متدی را جهت جستجوی قسمتی از نام کشورها، مشاهده می‌کنید:
          [Route("api/[controller]")]
          public class TypeaheadController : Controller
          {
              [HttpGet("[action]")]
              public async Task<IActionResult> SearchCountries(string term)
              {
                  await Task.Delay(1000); // simulating a slow operation
      
                  var items = new[]
                      {
                           "Afghanistan",
                           "Albania",
                           "Algeria",
                           "American Samoa",
                           "Andorra",
                           "Angola",
                           "Anguilla",
                           "Antarctica",
                           "Antigua and/or Barbuda"
                      };
                  var results = string.IsNullOrWhiteSpace(term) ? items :
                                 items.Where(item => item.StartsWith(term, StringComparison.OrdinalIgnoreCase));
                  return Json(results.ToArray());
              }
          }
      از این کنترلر به نحو ذیل در برنامه‌ی Angular برای ارسال اطلاعات و انجام جستجو استفاده می‌شود:
      import { HttpClient, HttpErrorResponse } from "@angular/common/http";
      import { Injectable } from "@angular/core";
      import { Observable } from "rxjs/Observable";
      import { ErrorObservable } from "rxjs/observable/ErrorObservable";
      import { catchError, map } from "rxjs/operators";
      
      @Injectable()
      export class SearchService {
      
        constructor(private http: HttpClient) { }
      
        searchCountries(term: string): Observable<string[]> {
          return this.http
            .get(`/api/Typeahead/SearchCountries?term=${encodeURIComponent(term)}`)
            .pipe(
              map(response => response || {}),
              catchError((error: HttpErrorResponse) => ErrorObservable.create(error))
            );
        }
      }
      در اینجا از اپراتور pipe مخصوص RxJS 5.5استفاده شده‌است.


      جستجوی ورودی کاربر به ازای هربار ورود اطلاعات توسط او

      صرفنظر از نوع فرمی که استفاده می‌کنید (مبتنی بر قالب‌ها و یا واکنشی)، جهت انتقال هربار فشرده شدن کلیدی به کدهای کامپوننت، می‌توان از رخ‌داد input استفاده کرد:
      <label>Country: </label><input type="text" (input)="onSearch1Change($event.target.value)" /><ul class="list-group"><li class="list-group-item" *ngFor="let country of countries1">
              {{country}}</li></ul>
      و سپس متد مدیریت کننده‌ی آن در کامپوننت نیز به صورت زیر تعریف می‌شود:
      onSearch1Change(value: string) {
      }
      در این حالت روش ابتدایی واکنش نشان دادن به هر ورودی، تزریق SearchService فوق به سازنده‌ی این کامپوننت
       constructor(private searchService: SearchService) { }
      و سپس مشترک متد جستجوی سمت سرور آن، شدن است.
      این روش ابتدایی سه مشکل را به همراه دارد:
      الف) به ازای هر بار فشرده شدن کلیدی در Input box، یک درخواست به سمت سرور ارسال می‌شود. برای مثال اگر هدف اصلی کاربر، جستجوی کشورهای شروع شده‌ی با alg باشد، سه درخواست به سمت سرور ارسال می‌شوند و سه بار هم رابط کاربری به روز می‌شود.
      ب) اگر در این بین، کاربر حرفی را کم و زیاد کند، درخواست‌های قبلی لغو نمی‌شوند.
      ج) درخواست‌ها به صورت موازی به سرور ارسال می‌شوند. ممکن است نتیجه‌ی یکی زودتر و دیگری دیرتر دریافت شود. در این حالت آخرین نتیجه‌ی رسیده، نتایج قبلی را بازنویسی می‌کند که ممکن است الزاما نتیجه‌ای نباشد که کاربر درخواست کرده‌است.


      کنترل نرخ ورود اطلاعات توسط متد debounceTime

      با اعمال اپراتور debounceTime به رخ‌داد تغییرات ورودی، می‌توان نرخ ورودی کاربر و واکنش نشان دادن به آن‌را کاهش داد. برای مثال اگر این عدد به 300 میلی ثانیه تنظیم شده باشد، صرفا به اولین ورودی رسیده‌ی پس از 300 میلی ثانیه واکنش نشان داده می‌شود و از مابقی صرفنظر خواهد شد. به این ترتیب دیگر به ازای هربار فشرده شدن کلیدی توسط کاربر جستجو صورت نمی‌گیرد. همچنین با ترکیب آن با اپراتور distinctUntilChanged می‌توان تنها به تغییرات غیرتکراری واکنش نشان داد:
      export class AutocompleteSampleComponent implements OnInit {
      
        countries1: string[] = [];
        private model1Changed: Subject<string> = new Subject<string>();
        private dueTime = 300;
      
        constructor(private searchService: SearchService) { }
      
        ngOnInit() {
          this.model1Changed
            .pipe(
              debounceTime(this.dueTime),
              distinctUntilChanged(),
              flatMap(inputValue => {
                console.log("debounced input value1", inputValue);
                return this.searchService.searchCountries(inputValue);
              })
            )
            .subscribe(countries => {
              this.countries1 = countries;
            });
        }
      
        onSearch1Change(value: string) {
          this.model1Changed.next(value);
        }
      }
      بنابراین بجای اینکه متد this.searchService.searchCountries دقیقا داخل onSearch1Change فراخوانی شود، باید بتوان تغییرات صورت گرفته‌ی نهایی را پس از اعمال debounceTime و distinctUntilChanged به آن ارسال کرد و سپس نتیجه را به کاربر نمایش داد.
      برای این منظور یک Subject تعریف شده‌است تا کار مدیریت تغییرات رسیده (کلیدهای فشرده شده‌ی توسط کاربر) را انجام دهد. در این‌حالت فرصت خواهیم داشت تا انواع و اقسام اپراتورهای RxJS را با هم ترکیب و صرفا نتیجه‌ی نهایی (آخرین ورودی یکتای با تاخیر او) را به searchService ارسال کنیم.
      متد onSearch1Change نیز تنها کافی است با فراخوانی متد next این Subject‌، جریان تغییرات رسیده را به آن انتقال دهد.
      در اینجا برای انتقال آخرین ورودی یکتای با تاخیر به متد this.searchService.searchCountries از اپراتور flatMap استفاده شده‌است. این اپراتور، آخرین ورودی فیلتر شده را دریافت کرده و به متد searchCountries ارسال می‌کند. همچنین خروجی آن نیز یک Observable است. به همین جهت در ادامه می‌توان توسط متد subscribe، مشترک آن شد و آرایه‌ی countries دریافتی از سرور را به کاربر نمایش داد.



      بهبود کارآیی جستجو با لغو درخواست‌های پیشین

      تا اینجا توانستیم نرخ ورود اطلاعات کاربر را به صورت کنترل شده‌ای به متد this.searchService.searchCountries ارسال کنیم و نه اینکه به ازای هر بار ورود اطلاعات توسط آن، یکبار این متد فراخوانی شود. اما همانطور که در تصویر فوق مشاهده می‌کنید، در اینجا هدف نهایی کاربر، جستجوی نام کشورهای شروع شده‌ی با alg بوده است و در این بین چندین بار سعی و خطا انجام داده‌است تا به alg رسیده‌است. مشکل اینجا است که هیچکدام از درخواست‌های قبلی او که مدنظر نبوده‌اند، لغو نشده‌اند و تمام آن‌ها صورت گرفته و همچنین سبب به روز رسانی‌های مکرر رابط کاربری شده‌اند.
      برای رفع یک چنین مشکلی و لغو خودکار درخواست‌های قبلی، اپراتور دیگری به نام switchMap وجود دارد که دقیقا یک چنین کاری را انجام می‌دهد. در اینجا برخلاف اپراتور flatMap، تمام درخواست‌های تمام نشده‌ی قبلی، لغو شده و صرفا آخرین مورد پردازش می‌شود.


      برای اعمال آن نیز در کدهای فوق تنها کافی است flatMap را با switchMap جایگزین کنید. پس از آن نتیجه را در تصویر فوق ملاحظه می‌کنید. اینبار اگر هدف نهایی کاربر جستجوی alg باشد، تمام ورودی‌های قبلی او به صورت خودکار لغو می‌شوند و دیگر پردازش نخواهند شد که در نهایت سبب بالا رفتن کارآیی برنامه با کاهش تعداد بار به روز رسانی رابط کاربری خواهد شد.

      همچنین در حالت استفاده‌ی از flatMap، ممکن است کاربر نتیجه‌ی اشتباهی را نیز دریافت کند. از این جهت که درخواست‌های ارسالی به سمت سرور، به صورت موازی اجرا می‌شوند. در این حالت ممکن است یکی زودتر و دیگری دیرتر به پایان برسد و کاربر نتیجه‌ای را که مشاهده می‌کند، دقیقا آن چیزی نباشد که جستجو کرده‌است (رابط کاربری آخرین درخواست پایان یافته را نمایش می‌دهد که نتیجه‌ی آن الزاما به ترتیب ورود اطلاعات کاربر نیست).
      // A1: Request for `ABC`
      // A2: Response for `ABC`
      // B1: Request for `ABCX`
      // B2: Response for `ABCX`
      --A1----------A2-->
      ------B1--B2------>
      برای نمونه فرض کنید دو درخواست A1 و B1 به همراه پاسخ‌های A2 و B2 را داریم. درخواست A1 پیش از B1 ارسال شده‌است؛ اما پاسخ B1 زودتر از پاسخ A2 از سرور دریافت شده‌است. در این حالت کاربر عبارت ABCX را وارد کرده‌است اما پاسخ عبارت ABC پیشین را در رابط کاربری مشاهده می‌کند (آخرین پاسخ رسیده در رابط کاربری (یا همان A2)، پاسخ‌های قبلی (یا همان B2) را بازنویسی می‌کند).

      در حالت استفاده‌ی از flatMap‌، مشترک هر رخ‌داد رسیده خواهیم شد؛ بدون قطع اشتراک خودکار از سایر observableهای ایجاد شده‌ی پیشین. اما در حالت استفاده‌ی از switchMap‌، ابتدا کار لغو اشتراک خودکار از تمام observableهای قبلی صورت می‌گیرد و سپس یک observable جدید را ایجاد می‌کند. به همین جهت است که استفاده‌ی از switchMap‌  به همراه درخواست‌های http، سبب لغو خودکار درخواست‌های پیشین می‌شود. در این حالت نه تنها تعداد بار به روز رسانی رابط کاربری کاهش پیدا می‌کند، بلکه تضمین خواهد شد دیگر کاربر نتیجه‌ی اشتباهی را نیز مشاهده نکند.



      کدهای کامل این مطلب را از اینجامی‌توانید دریافت کنید.

      ‫اجرای سرویسهای NodeJS در ASP.NET Core

      $
      0
      0
       این نوشتار در مورد نحوه اجرای سرویس‌های NodeJS در ASP.NET Core می‌باشد؛ زیرا تعداد زیادی از Package‌های سورس باز و با کیفیت بالا به فرم Node package manager یا به اصطلاح NPM موجود و قابل دریافت می‌باشند. NPM بزرگترین مخزن دنیا از لحاظ وجود بسته‌های نرم افزاری سورس باز است. به همین جهت بسته Microsoft.AspNetCore.NodeServices، جهت استفاده از این بسته‌ها در برنامه‌های ASP.NET Core ارائه شده‌است. برای استفاده از سرویسهای Node ابتدا باید ارجاعی را به بسته Microsoft.AspNetCore.NodeServices داشته باشید. برای این منظور میتوانید از دستور dotnet add package Microsoft.AspNetCore.NodeServices استفاده نمایید. البته اگر از آخرین نسخه NET Core. استفاده میکنید، لزومی به ارجاع به بسته فوق نمی‌باشد و به صورت پیشفرض در بسته Microsoft.AspNetCore.All موجود است.
      سپس متد ()ConfigurationServices را جهت اضافه کردن میان افزار Node Services به خط لوله درخواستها (request pipeline) ویرایش میکنیم:
      public void ConfigureServices(IServiceCollection services)
      {
          services.AddMvc();
          services.AddNodeServices();
      }

      حال میتوانید به وهله‌ای از اینترفیس INodeServices، از طریق تزریق وابستگی‌ها دسترسی داشته باشید. اینترفیس INodeServices یک Api می‌باشد و مشخص می‌کند که کدام قطعه از کد NET. میتواند کد جاوااسکریپتی را که در محیط Node اجرا می‌شود، فراخوانی کند. همچنین میتوانید از خاصیت FromServices برای دریافت وهله‌ای از اینترفیس INodeServices در اکشن خود استفاده نمایید.
      public async Task<IActionResult> Add([FromServices] INodeServices nodeServices)
      {
          var num1 = 10;
          var num2 = 20;
          var result = await nodeServices.InvokeAsync<int>("AddModule.js", num1, num2);
          ViewData["ResultFromNode"] = $"Result of {num1} + {num2} is {result}";
          return View();
      }

      سپس کد جاوااسکریپتی متناظر با تابعی را که توسط متد InvokeAsync فراخوانی میشود، به صورت زیر می‌نویسیم:
      module.exports = function(callback, num1, num2) { 
        var result = num1 + num2;
        callback(null, result); 
      };
      دقت کنید که نام فایل جاوااسکریپت باید همنام با پارامتر اول متد InvokeAsync و تعداد پارامترهای تابع باید مساوی با پارامترهایی باشد که به تابع فراخوانی شده جاوااسکریپت ارسال می‌شود.

      حال بیاییم مثالی دیگر را مرور کنیم. میخواهیم از صفحه وب درخواستی، عکسی را تهیه کنیم. بدین منظور از کتابخانه url-to-image استفاده میکنیم. برای نصب آن دستور npm install --save url-to-image را در خط فرمان تایپ میکنیم.

      بعد از اتمام نصب این بسته، متدی را برای دریافت اطلاعات ارسالی این کتابخانه تدارک میبینیم.

       [HttpPost]
              public async Task<IActionResult> GenerateUrlPreview([FromServices] INodeServices nodeServices)
              {
                  var url = Request.Form["Url"].ToString();
                  var fileName = System.IO.Path.ChangeExtension(DateTime.UtcNow.Ticks.ToString(), "jpeg");
                  var file = await nodeServices.InvokeAsync<string>("UrlPreviewModule.js", url, System.IO.Path.Combine("PreviewImages", fileName));
                  return Content($"/Home/Download?img={fileName}");
              }
      
              public IActionResult Download()
              {
                  var image = Request.Query["img"].ToString();
                  var fileName = System.IO.Path.Combine("PreviewImages", image);
                  var isExists = System.IO.File.Exists(fileName);
      
                  if (isExists)
                  {
                      Response.Headers.Add($"Content-Disposition", "attachment; filename=\"" + image + "\"");
                      var bytes = System.IO.File.ReadAllBytes(fileName);
                      return File(bytes, "image/jpeg");
                  }
                  else
                  {
                      return NotFound();
                  }
              }

      سپس متد UrlPreviewModule.js را به صورت زیر مینویسیم:

      var urlToImage = require('url-to-image');
      module.exports = function (callback, url, imageName) {
          urlToImage(url, imageName).then(function () {
              callback(null, imageName);
          }).catch(function (err) {
              callback(err, imageName);
          });
      };


      سرویس‌های Node به توسعه دهندگان ASP.NET Core امکان استفاده از اکوسیستم NPM را که دارای قابلیتهای فراوانی می‌باشد، میدهد. 


      ‫بررسی خطاهای ممکن در حین راه اندازی اولیه برنامه‌های ASP.NET Core در IIS

      $
      0
      0
      نحوه‌ی نصب و راه اندازی برنامه‌های ASP.NET Core را در IIS، پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 22 - توزیع برنامه توسط IIS» بررسی کردیم. در این مطلب می‌خواهیم به تعدادی از خطاهای ممکن در حین راه اندازی اولیه‌ی این نوع برنامه‌ها بپردازیم.


      خطای 500.19


      این خطا زمانی رخ می‌دهد که ماژول هاستینگ ASP.NET Core، توسط IIS شناسایی نشده باشد. نصب مجدد آن این مشکل را برطرف می‌کند.
      لیست تمام ماژول‌های هاستینگ را همواره در اینجامی‌توانید پیدا کنید.


      خطای 502.5 و یا گاهی از اوقات 502


      باید دقت داشته باشید که اگر تنظیم disableStartUpErrorPage در IIS فعال باشد (قابل افزودن به تگ aspNetCore تنظیمات وب کانفیگ ذیل)، صرفا خطای 502 را دریافت می‌کنید.

      این خطا به معنای شکست در اجرای ماژول هاستینگ ASP.NET Core است و ممکن است به یکی از دلایل ذیل ایجاد شده باشد:
      الف) در حین اجرای برنامه‌ی شما، استثنایی در کدهای فایل آغازین startup.cs برنامه، رخ داده‌است.
      ب) پورت مورد استفاده‌ی برنامه، توسط پروسه‌ی دیگری در حال استفاده است.
      ج) برنامه‌ی شما برای SDK با نگارش 1.1.2 تنظیم و کامپایل شده‌است؛ اما بر روی سرور حداکثر، SDK نگارش 1.1.1 نصب شده‌است.
      د) ممکن است پروسه‌ی IIS قادر به یافتن و حتی اجرای dotnet.exe نباشد.

      برای لاگ کردن مورد «الف»، باید لاگ کردن خطاهای برنامه را در web.config آن فعالسازی کنید:
      <system.webServer><handlers><add name="aspNetCore" path="*" verb="*"
      modules="AspNetCoreModule" resourceType="Unspecified" /></handlers><aspNetCore processPath="dotnet" arguments=".\MyApp.dll" stdoutLogEnabled="true"
      stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" /></system.webServer>
      چند نکته:
      - اگر این مورد به مسیر logs\stdout\. تنظیم شده‌است، باید پوشه‌ی logs را در ریشه‌ی پروژه به صورت دستی ایجاد کنید؛ و گرنه IIS آن‌را به صورت خودکار ایجاد نخواهد کرد.
      - کاربر App Pool برنامه (با نام پیش‌فرض « IIS AppPool\DefaultAppPool») باید دسترسی نوشتن در این پوشه را داشته باشد؛ وگرنه فایل لاگی در آن ایجاد نخواهد شد.
      - همچنین اگر با رعایت تمام این موارد، محتوای این فایل تولید شده باز هم خالی بود، یکبار IIS را ری‌استارت کنید. ممکن است IIS کار نوشتن در فایل لاگ را تمام نکرده باشد و با این کار مجبور به تکمیل و بستن فایل می‌شود.  

      - برای حالت «ب» قبل از هر تغییری، یکبار کل سرور را ری‌استارت کنید.

      - برای مورد «ج» نیز باید آخرین SDK هاستینگ را بر روی سرور نصب کنید.
      لیست تمام SDKهای نصب شده‌ی بر روی سیستم را در مسیر «C:\Program Files\dotnet\sdk» می‌توانید مشاهده کنید. همچنین دستور «dotnet --list-sdks» نیز لیست SDKهای نصب شده را نمایش می‌دهد.

      - برای رفع حالت «د»، نیاز است این موارد را بررسی کنید:
      1- «Load User Profile» را به true تنظیم کنید.


      برای اینکار به قسمت Application pools مراجعه کرده و تنظیمات پیشرفته‌ی App pool مورد استفاده را ویرایش کنید (تصویر فوق).
      این تنظیم برای دائمی کردن کلیدهای رمزنگاری برنامه‌های ASP.NET Core نیز ضروری استو باید جزو چک لیست نصب برنامه‌های ASP.NET Core قرار گیرد.
      2- مورد «د» حتی می‌تواند به علت عدم تعریف مسیر «C:\Program Files\dotnet\» در path ویندوز باشد. برای این منظور دستور env:path$ را در power shell اجرا کنید و بررسی کنید که آیا این مسیر در خروجی آن موجود است یا خیر؟ اگر نبود، پس از اضافه کردن آن به path ویندوز، باید یکبار IIS را هم ریست کنید تا این تنظیمات جدید را بخواند.
      3- مورد «د» ممکن است به علت اشتباه تنظیم پوشه‌ی اصلی برنامه در IIS نیز باشد. یعنی dotnet.exe قادر به یافتن اسمبلی‌های برنامه نیست.
      4- برای رفع مورد «د» دو دسترسی دیگر را نیز باید بررسی کنید:
      الف) آیا کاربر Application pool برنامه به پوشه‌ی برنامه دسترسی read & execute را دارد یا خیر؟
      ب) آیا کاربر Application pool برنامه به پوشه‌ی C:\Program Files\dotnet دسترسی read & execute را دارد یا خیر؟
      اگر خیر، نحوه‌ی دسترسی دادن به آن‌ها به صورت زیر است:
      Right click on the folder -> Properties -> Security tab -> Click at Edit button ->
      Enter `IIS AppPool\DefaultAppPool` user (IIS AppPool\<app_pool_name>) -> Click at Check names -> OK ->
      Then give it `read & execute` or other permissions.


      خطای 502.3 و یا گاهی از اوقات 500


      این خطا به صورت خلاصه به معنای «Bad Gateway: Forwarder Connection Error» است و زمانی رخ می‌دهد که پروسه‌ی dotnet.exe به درخواست رسیده شده یا پاسخی نداده‌است (مشاهده خطای 0x80072EE2  یا  ERROR_WINHTTP_TIMEOUT) و یا بیش از اندازه این پاسخ دهی طول کشیده‌است (این تنظیمات را در configuration editor می‌توانید مشاهده کنید که در حقیقت همان تگ aspNetCore در تنظیمات وب کانفیگ فوق است).


      برای دیباگ بهتر این مورد نیاز است علاوه بر تنظیم web.config فوق، به فایل appsettings.json مراجعه کرده و سطح پیش فرض لاگ کردن اطلاعات را که warning است به information تغییر دهید:
      "Console": {
           "LogLevel": {
              "Default": "Information"
           }
      }
      در این حالت درخواستی که پردازش نشده‌است نیز در لاگ‌ها حضور خواهد داشت و ممکن است این درخواست به علت عدم تنظیم CORS بدون پاسخ باقی مانده باشد.
      و یا اگر پردازشی دارید که بیش از 2 دقیقه طول می‌کشد (مطابق تنظیمات تصویر فوق)، می‌توانید مقدار request time out را بیشتر کنید.


      خطای 0x80004005 : 80008083

      Application ‘<IIS path>’ with physical root ‘<Application path>’ failed to start 
      process with commandline ‘”dotnet” .\MyApp.dll’, ErrorCode = ‘0x80004005 : 80008083.
      خطای 0x80008083 به معنای تداخل نگارش‌ها است و خطای 0x80004005 به معنای مفقود بودن یک فایل یا عدم دسترسی به آن است.
      این خطا زمانی رخ می‌دهد که برنامه‌ی خود را ارتقاء داده باشید، اما ماژول هاستینگ ASP.NET Core را بر روی سرور به روز رسانی نکرده باشید.


      خطای 500.19

      HTTP Error 500.19 - Internal Server Error
      The requested page cannot be accessed because the related configuration data for the page is invalid.
      اگر برنامه‌ی شما از امکانات URL Rewrite خود IIS استفاده می‌کند، عدم نصب بودن آن بر روی سرور، این خطا را سبب خواهد شد.
      برای اینکار ابتدا IIS را متوقف کنید. سپس SDK جدید را نصب و پس از آن IIS را مجددا راه اندازی نمائید.


      خطای 503

      برنامه اجرا نشده و سطر ذیل در Event Viewer ویندوز قابل مشاهده است:
       The Module DLL C:\WINDOWS\system32\inetsrv\aspnetcore.dll failed to load.  The data is the error.
      اگر اخیرا سیستم عامل را ارتقاء داده‌اید، ممکن است این خطا را دریافت کنید. راه حل آن نصب مجدد ماژول هاستینگ ASP.NET Core است تا نصب قبلی تعمیر شود.

      ‫تست کردن متدهای یک Controller به کمک PowerShell

      $
      0
      0

      ابزارهای زیادی جهت تست کردن API‌های برنامه‌های وب موجود است. یکی از معروفترین آنها  Fiddlerاست که ابزاری مستقل جهت دیباگ تحت پروتکل HTTPمی‌باشد. یکی دیگر از این نرم افزارهاSwashbuckleاست که از Nugetقابل دریافت است و صفحه‌ای را به برنامه اضافه می‌کند که به اختصار API‌های برنامه را نمایش داده و امکان اجرای آنها را فراهم میکند.

      اما ساده‌ترین راه جهت کردن تست کردن API‌های یک برنامه، استفاده از PowerShell است که عمل ایجاد درخواست‌های HTTPرا به راحتی از طریقCommand lineفراهم میکند و به شما اجازه میدهد بدون وارد شدن به جزئیات، بر روی نتیجه APIمورد نظر تمرکز کنید. PowerShellابتدا فقط برای محیط ویندوز طراحی شده بود ولی در حال حاضر قابلیت اجرای تحت Linuxو Macرا نیز دارد.

      در این بخش به شما نشان خواهم داد که چگونه متدهای یک Controllerرا با استفاده از PowerShellتست نمایید.

      بدین منظور ابتدا کلاسی را به نام Reservationبا مشخصات زیر، در یک پروژه ASP.NET Core Web Application  ایجاد نمایید.
      public class Reservation
      {
              public int ReservationId { get; set; }
              public string ClientName { get; set; }
              public string Location { get; set; }
      }
      و سپس Interface زیر را جهت انجام عملیات CRUD اضافه نمائید:
      public interface IRepository
      {
              IEnumerable<Reservation> Reservations { get; }
              Reservation this[int id] { get; }
              Reservation AddReservation(Reservation reservation);
              Reservation UpdateReservation(Reservation reservation);
              void DeleteReservation(int id);
      }
      و کلاسی که Interface فوق را پیاده سازی خواهد کرد:
      public class MemoryRepository : IRepository
       {
              private Dictionary<int, Reservation> items;
              public MemoryRepository()
              {
                  items = new Dictionary<int, Reservation>();
                  new List<Reservation> {
                      new Reservation { ClientName = "Alice", Location = "Board Room" },
                      new Reservation { ClientName = "Bob", Location = "Lecture Hall" },
                      new Reservation { ClientName = "Joe", Location = "Meeting Room 1" }
                  }.ForEach(r => AddReservation(r));
              }
      
              public Reservation this[int id] => items.ContainsKey(id) ? items[id] : null;
              public IEnumerable<Reservation> Reservations => items.Values;
      
              public Reservation AddReservation(Reservation reservation)
              {
                  if (reservation.ReservationId == 0)
                  {
                      int key = items.Count;
                      while (items.ContainsKey(key)) { key++; };
                      reservation.ReservationId = key;
                  }
                  items[reservation.ReservationId] = reservation;
                  return reservation;
              }
      
              public void DeleteReservation(int id) => items.Remove(id);
              public Reservation UpdateReservation(Reservation reservation) => AddReservation(reservation);
      }
      در کلاس فوق به جهت سهولت در کار، از یک لیست، برای نگهداری تعدادی رکورد اطلاعاتی جهت نمایش استفاده شده است.

      سپس کنترلری را به نام ReservationController به پروژه اضافه کنید که شامل متدهای زیر باشد:
      [Route("api/[controller]")]
      public class ReservationController : Controller
          {
              private IRepository repository;
              public ReservationController(IRepository repo) => repository = repo;
      
              [HttpGet]
              public IEnumerable<Reservation> Get() => repository.Reservations;
      
              [HttpGet("{id}")]
              public Reservation Get(int id) => repository[id];
      
              [HttpPost]
              public Reservation Post([FromBody] Reservation res) =>
                          repository.AddReservation(new Reservation
                          {
                              ClientName = res.ClientName,
                              Location = res.Location
                          });
              [HttpPut]
              public Reservation Put([FromBody] Reservation res) => repository.UpdateReservation(res);
      
              [HttpPatch("{id}")]
              public StatusCodeResult Patch(int id, [FromBody] JsonPatchDocument<Reservation> patch)
              {
                  Reservation res = Get(id);
                  if (res != null)
                  {
                      patch.ApplyTo(res);
                      return Ok();
                  }
                  return NotFound();
              }
      
              [HttpDelete("{id}")]
              public void Delete(int id) => repository.DeleteReservation(id);
      }
      حالا جهت تست صحت این API‌ها توسط PowerShell لازم است ابتدا برنامه را اجرا کرده و منتظر بمانید تا صفحه Home ظاهر شود. پس از آن لازم است یک پنجره PowerShell را از طریق کلیک راست در یکی از فولدرهای نمایش داده شده در FileExplorer باز کنید.

      تست کردن درخواست از نوع GET

      حالا دستور زیر را در پنجره PowerShell وارد کنید:
       Invoke-RestMethod http://localhost:7000/api/reservation -Method GET
      لازم است شماره پورت را مطابق با پورتی که برنامه شما بر روی آن اجرا شده تغییر دهید. این فرمان به کمک دستور Invoke-RestMethod درخواستی از نوع GET را به api/reservation ارسال می‌کند و نتیجه را پس از تجزیه و تحلیل و فرمت بندی، جهت سهولت در خوانده شدن، به شکل زیر نمایش میدهد:

      location clientName reservationId 
      Board Room 
      Alice 
      0                  
      Lecture Hall 
      Bob
      1
      Meeting Room 1 
      Joe
      2
      فرمت اطلاعات دریافت شده از درخواست GET، اشیایی از نوع کلاس Reservation است و به فرمت Json می‌باشد؛ ولی Invoke-RestMethod آنرا به صورت جدول نمایش میدهد.
      حال جهت نمایش فقط یک رکورد از اطلاعات فوق، دستور زیر را وارد نمایید:
      Invoke-RestMethod http://localhost:7000/api/reservation/1 -Method GET
      این فرمان درخواستی جهت دریافت اطلاعات شیء Reservation است که کد داخلی آن برابر 1 است. پاسخ این درخواست به شکل زیر نمایش داده خواهد شد:

      location clientName  reservationId   
      Lecture Hall  
              Bob
      1                  


      تست درخواست از نوع Post

      تمامی متدهای ارائه شده توسط یک API را می‌توان به کمک PowerShell تست کرد. اگرچه در این حالت فرمت بعضی از درخواستهای ارسالی ممکن است کمی به هم ریخته به نظر برسد. در اینجا درخواستی جهت اضافه کردن یک رکورد را به لیست Reservation ارسال می‌کنیم و نتیجه را در پاسخ ارسال شده از سمت سرور خواهیم دید:

      Invoke-RestMethod http://localhost:7000/api/reservation -Method POST -Body
      (@{clientName="Anne"; location="Meeting Room 4"} | ConvertTo-Json) -ContentType "application/json"
      این دستور با استفاده از آرگومان Body- محتویات درخواست را که با فرمت Json است تعیین می‌کند. آرگومان Content-Type- هم نوع محتویات درخواستی را در هدر مشخص میکند. دستور فوق در صورت موفقیت نتیجه زیر را نمایش خواهد داد:

      location clientName  reservationId   
       Meeting Room 4
      Anne      
      1                
                 
      دستور Post ارسالی، با استفاده از دو فیلد clientName و location، یک رکورد جدید از نوع Reservation را به لیست موجود اضافه کرده و نتیجه را در قالب Json به سمت کلاینت برگشت خواهد داد که شامل ReservationId می‌باشد که به رکورد جدید اختصاص داده شده‌است. ممکن است چنین به نظر برسد که نتیجه برگشت داده شده، همان درخواست ارسالی است که به شکل جدول فوق نمایش داده می‌شود؛ ولی چنین نیست. جهت مشاهده تاثیر درخواست POST ارسالی بر روی منبع داده، کافی است یک بار دیگر دستور زیر را در command line وارد کنید:
      Invoke-RestMethod http://localhost:7000/api/reservation -Method GET

      location clientName  reservationId   
       Board Room          Alice
      0              
       Lecture Hall Bob1
       Meeting Room 1 Joe2
       Meeting Room 4 Anne3
      داده‌هایی که به سمت کلاینت ارسال شده، نشان دهنده اضافه شدن رکورد جدیدی به منبع داده ماست.

      تست درخواست از نوع PUT

      درخواست از نوع PUT جهت جایگزینی داده‌ای موجود در لیست، با داده‌ی جدید است. بدین منظور کد داخلی شیء مورد نظر (در اینجا ReservationId) باید در URL گنجانده شود و مقادیر فیلدهای کلاس، در متن درخواست. مثالی جهت درخواست اصلاح داده موجود از طریق فرمان PowerShell :

      Invoke-RestMethod http://localhost:7000/api/reservation -Method PUT -Body
      (@{reservationId="1"; clientName="Bob"; location="Media Room"} | ConvertTo-Json)
      -ContentType "application/json"
      درخواست فوق، فیلد Location رکوردی با کد داخلی 1 را به مقدار جدیدی تغییر خواهد داد و نتیجه تغییر انجام شده را در پاسخ ارسال خواهد کرد:

      location clientName  reservationId   
      Media Room
      Bob        
      1                

      و باز با ارسال درخواست زیر می‌توان نتیجه کلی را مشاهده کرد:
      Invoke-RestMethod http://localhost:7000/api/reservation -Method GET

      location clientName  reservationId   
      Board Room
      Alice  
      0  
       Media Room
       Bob 1
       Meeting Room 1
      Joe2
       Meeting Room 4
      Anne
      3


      استفاده از دستور PATCH

      این دستور جهت تغییر اطلاعات یک رکورد به کار میرود، ولی استفاده از آن در غالب برنامه‌های پیاده سازی شده نادیده گرفته می‌شود که البته چنانچه کاربران برنامه‌های مذکور به تمامی فیلدهای یک رکورد دسترسی داشته باشند، معقولانه به نظر می‌رسد. اما در یک برنامه بزرگ و پیچیده ممکن است به دلایلی از جمله مسایل امنیتی، کاربران اجازه دسترسی به تمامی فیلدهای یک رکورد را نداشته باشند و در این حالت نمی‌توان از دستور PUT جهت ارسال درخواست استفاده کرد. دستورهای مبتنی بر PATCH گزینشی بوده و می‌توان فقط فیلدهای خاصی را که مورد نظر می‌باشند، با آن تغییر داد.

      ASP.NET Core MVC از استاندارد Json PATCH پشتیبانی می‌کند و این کار اجازه میدهد تا بتوان تغییرات را بطور یکنواختی انجام داد. جهت مشاهده جزئیات این دستور می‌توانید به این لینکمراجعه کنید. اما برای مثال فرض کنید می‌خواهید چنین درخواستی را که به فرمت Json است از طریق HTTP PATCH به سمت سرور ارسال کنید:

      [
        { "op": "replace", "path": "clientName", "value": "Bob"},
        { "op": "replace", "path": "location", "value": "Lecture Hall"}
      ]

      دربسیاری از مواقع فقط از دستور replace درخواست PATCH استفاده می‌شود و کد داخلی رکورد مورد نظر، جهت تغییر در Url درخواست ارسالی، فرستاده خواهد شد. ASP.NET Core MVC به طور اتوماتیک این دستور را پردازش کرده و آنرا به صورت آبجکتی از نوع <JsonPatchDocument<T به اکشن کنترلر قید شده، پاس خواهد داد که در اینجا نوع T، از نوع کلاس مورد نظر ما می‌باشد. فرمت دستور ارسالی از طریق Powershell به شکل زیر خواهد بود:

      Invoke-RestMethod http://localhost:7000/api/reservation/2 -Method PATCH -Body (@
      { op="replace"; path="clientName"; value="Bob"},@{ op="replace"; path="location";
      value="Lecture Hall"} | ConvertTo-Json) -ContentType "application/json"
      دستور فوق درخواست تغییر دو فیلد clientname و location، با کد داخلی 2 می‌باشد.
      جهت مشاهده تغییر ایجاد شده، دستور زیر را مجددا اجرا نمایید:
      Invoke-RestMethod http://localhost:7000/api/reservation -Method GET

      location clientName  reservationId  
      Board Room
      Alice  
      0            
      Media Room
      Bob
       1
      Lecture Hall
       Bob2
      Meeting Room 4
       Anne3


      استفاده از دستور Delete

      استفاده از دستور Delete هم به شکل زیر خواهد بود:

      Invoke-RestMethod http://localhost:7000/api/reservation/2 -Method DELETE
      توضیح اینکه در این حالت پاسخی از سمت سرور ارسال نخواهد شد. اما جهت مشاهده تاثیر این دستور بر روی اطلاعات موجود می‌توان مجددا دستور زیر را جهت نمایش داده‌ها بکار برد:
      Invoke-RestMethod http://localhost:7000/api/reservation -Method GET

      کدهای این مقاله به پیوست موجود است: ApiControllers.zip

      ‫اجبار به استفاده‌ی از HTTPS در حین توسعه‌ی برنامه‌های ASP.NET Core 2.1

      $
      0
      0
      پس از نصب SDK جدید NET Core 2.1. و ایجاد یک برنامه‌ی جدید بر اساس آن توسط دستور«dotnet new mvc» و سپس اجرای آن به کمک دستور «dotnet run»، تصویر جدیدی مشاهده می‌شود:


      در نگارش‌های قبلی، پس از اجرای برنامه، صرفا یک سطر زیر نمایش داده می‌شد:
      Now listening on: http://localhost:5000
      اما اکنون تبدیل شده‌است به دو سطر که اولی HTTPS است و دومی HTTP معمولی:
      Now listening on: https://localhost:5001
      Now listening on: http://localhost:5000
      یعنی برنامه بر روی دو پورت 5000 و یا 5001 قابل دسترسی است. در این حال اگر سعی کنیم برنامه را بر روی پورت 5000 که HTTP معمولی است اجرا کنیم، بلافاصله به خطای امن نبودن دسترسی به سایت و اجرای خودکار برنامه بر روی پورت 5001 خواهیم رسید:


      علت هدایت خودکار به آدرس HTTPS، به تغییرات فایل آغازین برنامه بر می‌گردد:
      public void Configure(IApplicationBuilder app, IHostingEnvironment env)
      {
          if (env.IsDevelopment())
          {
              app.UseDeveloperExceptionPage();
          }
          else
          {
              app.UseExceptionHandler("/Home/Error");
              app.UseHsts();
          }
      
          app.UseHttpsRedirection();
      در اینجا علاوه بر UseHsts ، تنظیم UseHttpsRedirection نیز به صورت پیش‌فرض قرار داده شده‌اند که سبب ارتقاء و همچنین هدایت خودکار به آدرس HTTPS برنامه می‌شوند. توضیحات بیشتری در مورد Hsts: «فعال‌سازی HSTS در ASP.NET Core» که با میان افزار جدید و توکار Hsts جایگزین می‌شود.
      اگر خواستید این شماره‌ی پورت را تغییر دهید، می‌توانید به صورت زیر عمل کنید:
       services.AddHttpsRedirection(options => options.HttpsPort = 5002);
      میان افزار جدید UseHsts به مرورگرها فرمان می‌دهد که این سایت را در حالت HTTPS مرور کنند. البته همانطور که مشاهده می‌کنید این مورد فقط برای حالت ارائه‌ی نهایی تنظیم شده‌است و نه حالت استفاده‌ی از برنامه در حالت localhost. جزئیات این میان‌افزار را به صورت زیر نیز می‌توان تنظیم کرد و یا تغییر داد:
      services.AddHsts(options =>
      {
          options.MaxAge = TimeSpan.FromDays(100);
          options.IncludeSubDomains = true;
          options.Preload = true;
      });


      اما چرا برنامه در حالت HTTPS قابل مشاهده نیست؟

      پس از نصب SDK نگارش جدید NET Core.، یک مجوز SSL توسعه نیز به سیستم عامل اضافه می‌شود:
      ASP.NET Core
      ------------
      Successfully installed the ASP.NET Core HTTPS Development Certificate.

      برای مشاهده‌ی این مجوز، دستور certmgr.msc را در قسمت run ویندوز وارد کرده و enter کنید:


      این مجوز پیش فرض در قسمت «Personal/Certificates» با نام «ASP.NET Core HTTPS development certificate» قابل مشاهده‌است که در حقیقت یک Self Signed Certificate است و به صورت پیش فرض توسط سیستم معتبر و قابل اطمینان شناخته نمی‌شود.
      برای اعلام قابل اطمینان بودن این مجوز به سیستم، در همین کنسول مدیریت مجوزها، بر روی این مجوز کلیک راست کرده و آن‌را کپی کنید. سپس آن‌را در مسیر «Trusted Root Certification Authorities/Certificates» قرار دهید (paste کنید).


      در این حالت صفحه دیالوگ فوق ظاهر می‌شود. آن‌را تائید کنید تا این مجوز توسعه، به قسمت مجوزهای امن و معتبر سیستم اضافه شود.

      روش دوم انجام اینکار، استفاده از دستور زیر است:
      dotnet install tool dotnet-dev-certs -g --version 2.1.0-preview1-final
      dotnet dev-certs https --trust
      دستور اول برنامه‌ی dotnet-dev-certs را نصب می‌کند و دستور دوم آن‌را اجرا کرده و توسط پرچم trust، همان کار کپی و paste ذکر شده‌ی در قسمت قبلی را به صورت خودکار انجام خواهد داد. هرچند صفحه‌ی تائید این نقل و انتقال در اینجا نیز ظاهر می‌شود.


      پس از اینکار اگر مرورگر را ریفرش کنید، باز هم همان خطای قبلی نمایش داده می‌شود. برای رفع این مشکل باید یکبار مرورگر را کاملا بسته و مجددا اجرا کنید تا مجوز جدید را دریافت کند:



      تنظیمات مخصوص IIS Express برای اجرای برنامه‌های ASP.NET Core 2.1

      دستور «dotnet run» از IIS برای اجرا استفاده نمی‌کند و مبتنی بر وب سرور Kestrel است. تنظیمات IIS و IIS Express از فایل Properties\launchSettings.json خوانده می‌شوند که اینبار به صورت زیر تغییر کرده‌است:
      {
        "iisSettings": {
          "windowsAuthentication": false,
          "anonymousAuthentication": true,
          "iisExpress": {
            "applicationUrl": "http://localhost:4929",
            "sslPort": 44313
          }
        },
        "profiles": {
          "IIS Express": {
            "commandName": "IISExpress",
            "launchBrowser": true,
            "environmentVariables": {
              "ASPNETCORE_ENVIRONMENT": "Development",
              "ASPNETCORE_HTTPS_PORT": "44313"
            }
          },
          "TestWebApp": {
            "commandName": "Project",
            "launchBrowser": true,
            "environmentVariables": {
              "ASPNETCORE_ENVIRONMENT": "Development",
              "ASPNETCORE_URLS": "https://localhost:5001;http://localhost:5000"
            }
          }
        }
      }
      در اینجا تنظیمات مربوط به sslPort و همچنین ASPNETCORE_HTTPS_PORT نیز اضافه شده‌اند که IIS Express از آن‌ها استفاده می‌کند.

      ‫انتخاب layoutهای متفاوت در برنامه‌های Angular

      $
      0
      0
      شاید برای شما هم پیش آمده باشد که در یک برنامه‌ی Angular بخواهید layoutهای مختلفی داشته باشید؛ مثلا هنگام لاگین، طبق عرف کار باید هدر و فوتر صفحه از بین بروند و فقط فرم لاگین نمایش داده شود و یا بخواهید هنگام لاگین، یک layout مخصوص پنل مدیریتی داشته باشید و یا …

      قبل از شروع، فرض را بر آن می‌گیریم که حداقل نیاز‌های یک پروژه‌ی Angular را آماده کرده اید. سپس یک پوشه‌ی جدید را به نام layout می‌سازیم و layout‌های مربوطه را در آن ایجاد میکنیم. با دستور زیر یک کامپوننت جدید را که layout ما خواهد شد، با نام دلخواهی ایجاد می‌کنیم:
      ng g c Loginlayout
       و همچنین یک کامپوننت دیگر را برای صفحه‌ی اصلی به نام homelayout می‌سازیم:
      ng g c homelayout

      در ادامه Loginlayout را باز کرده و تنظیمات زیر را لحاظ کنید:
      <div style="width: 100%;height: 250px;background-color: aquamarine"><h1>Header</h1></div><router-outlet></router-outlet><div style="width: 100%;height: 250px;background-color: brown"><h1>Foother</h1></div>
      در اینجا یک هدر و یک فوتر را ساخته و <router-outlet></router-outlet> را در آن قرار می‌دهیم که قسمت پویای ما خواهد شد.

      اکنون وارد کامپوننت home layout شوید و دقیقا مانند قبل، تنظیمات دلخواه خود را انجام داده و همچنین <router-outlet></router-outlet> راهم درون جائیکه می‌خواهید به صورت پویا باشد بگذارید.
      تا اینجا ما فقط layoutها را طراحی کردیم. در ادامه در ریشه‌ی پروژه، سه کامپوننت را به نام‌های Home , Login, About میسازیم. Home و About دارای یک قالب و Login هم داری قالب مخصوص به خود میباشد.

      سپس وارد کامپوننت آغازین برنامه (app.component.html) شوید و در آن <router-outlet></router-outlet> را وارد کنید. در اینجا دیگر نیازی به نوشتن تگ‌های خاص دیگری نیست.

      در ادامه به اصلی‌ترین قسمت، یعنی مسیریابی می‌رسیم. وارد app.module.ts شوید و آن را به صورت زیر تنظیم کنید:
      export const routes: Routes = [    
                 { 
                      path: 'Loginlayout', 
                      component: LoginlayoutComponent ,
                      children: [
                        { path: 'Login', component: LoginComponent, pathMatch: 'full'}                 
                      ]
                  },
                  { 
                      path: 'Homelayout', 
                      component: HomelayoutComponent,
                      children: [
                        { path: 'About', component: AbouComponent, pathMatch: 'full'},
                        { path: 'Home', component: HomeComponent, pathMatch: 'full'}
                      ]
                  }          
      ];
      همانطورکه ملاحظه می‌کنید، مسیریابی بالا شامل مسیریابی‌های تو در تویی است. در اینجا کامپوننت‌های Home و About درون HomelayoutComponent بارگذاری می‌شوند و خود HomelayoutComponent  نیز درون app.component.
      همچنین برای اینکه مشخص شود کدام کامپوننت به عنوان کامپوننت پیشفرض نمایش داده شود، به صورت زیر عمل میکنیم:
      path: '', 
      component: HomelayoutComponent,
      children: [
        { path: '', component:HomeComponent, pathMatch: 'full'}         
      ]
      به  این روش میتوانید هر تعداد layout ایی را که میخواهید، ایجاد کنید.

      کدهای کامل این مطلب را می‌توانید از اینجادریافت و یا به صورت آنی آزمایش کنید.

      ‫انتشار عمومی localhost به صورت HTTPS توسط ngrok

      $
      0
      0
      شاید برای شما هم پیش آمده باشد که با Webhookها کار کنید و یا در حین اجرای پروژه‌ی وب خودتان بخواهید خروجی آن را به اطرافیان خود نشان دهید. یکی از راه‌ها این است  که پروژه را بر روی یک مخزن Git ارسال کنید و سپس دوستان خودتان را اضافه کنید تا بتوانند پروژه را دریافت و اجرا کنند. البته در این حالت شاید نخواهید کسی سورس شما را ببیند! روش دیگر این است که هاست و دامین بخرید و پروژه را بر روی آن آپلود کنید و در مرحله‌ی آخر، آدرس وبسایت را برای اطرافیان خود بفرستید که این راه، هم  پرهزینه هست و هم ممکن است پروژه کامل نشده باشد که بخواهید آن‌را آپلود کنید. اینجاست که Ngrok وارد شده و پروژه‌ی لوکال شما را بر روی Https ارائه میکند.


      شروع به کار با ngrok 

      - قبل از ادامه‌ی این آموزش، وارد سایت https://ngrok.comشده و بعد از ثبت نام، مطابق سیستم عاملی که دارید، فایل مخصوص آن را دریافت کنید.
      - بعد از دریافت، فایل زیپ را از حالت فشرده خارج کنید. به محل فایل استخراج شده رفته و در یک مکان خالی در پوشه‌ی جاری، دکمه‌ی Shift را فشرده و سپس کلیک راست کنید و در آخر گزینه‌ی Open Command Window Here را انتخاب نمائید و یا کلا از طریق cmd وارد پوشه‌ی مربوطه شوید.
      - سپس پروژه‌ی خود را توسط ویژوال استودیو (IIS Express) و یا بر روی IIS لوکال خود، اجرا کنید.

      - همانطور که در تصویر مشاهده می‌کنید؛ آدرس پروژه‌ی لوکال ما به شکل زیر می‌باشد: 
       http://localhost:51095/Home/Index
      توجه!این پروژه‌ی آزمایشی صرفا یک صفحه‌ی HTML خیلی ساده بوده که فقط عبارت ngrok را نشان می‌دهد.

      - حال به cmd برمی‌گردیم و سپس با دستور زیر میتوانیم لوکال‌هاست خود را بر روی https به اشتراک بگذاریم:
       ngrok http [port] -host-header="localhost:[port]"
      اگر کار را به درستی انجام داده باشید، خروجی شبیه به تصویر زیر را خواهید داشت:


      همانطور که ملاحظه می‌فرمائید، هم http و هم https را در اختیار ما قرار می‌دهد. برای مثال اگر نیاز است با webhookهای تلگرام کار کنید، باید از آدرس https آن استفاده کنید.
      در اینجا در قسمت  HTTP Requests  می‌توانید درخواست‌هایی را که فرستاده می‌شوند، ببینید و یا میتوانید با رفتن به آدرس زیر، دستورات بالا را در نمایی گرافیکی و بصورت کامل نظاره‌گر باشید:
       http://127.0.0.1:4040

      برای نمونه،  خروجی آن در گوشی و مرورگر آن، به شکل زیر است:



       
      Viewing all 1980 articles
      Browse latest View live


      <script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>