دسترسی به حدود 40 گیگابایت سورسهای برنامههای Adobe Acrobat, ColdFusion, ColdFusion Builder از شبکه شرکت Adobe
نظرات مطالب
نحوه کار Expression و ایجاد یک DynamicFilter
این لینک هم میتونه مفید باشه
برای تهیه یک RadioButtonList نیز میتوان از همان نکتهی CheckBoxList استفاده کرد: نام عناصر radio button اضافه شده به صفحه را یکسان وارد میکنیم. به این ترتیب یک گروه تشکیل خواهد شد و زمانیکه اطلاعات این عناصر به سرور ارسال میشود، اینبار بجای یک آرایه، تنها مقدار کنترل انتخاب شده، ارسال میگردد. یک مثال:
یک پروژه جدید و خالی ASP.NET MVC را آغاز کنید. سپس کنترلر Home و View خالی Index را نیز ایجاد نمائید. محتویات این دو را به نحو زیر تغییر دهید:
@{
ViewBag.Title = "Index";
}
<h2>
Index</h2>
<fieldset>
<legend>HandleForm1 (Normal)</legend>
@using (Html.BeginForm(actionName: "HandleForm1", controllerName: "Home"))
{
@:your favorite tech: <br />
@Html.RadioButton(name: "tech", value: ".NET", isChecked: true) @:DOTNET <br />
@Html.RadioButton(name: "tech", value: "JAVA", isChecked: false) @:JAVA <br />
@Html.RadioButton(name: "tech", value: "PHP", isChecked: false) @:PHP <br />
<input type="submit" value="Submit" />
}
</fieldset>
using System.Collections.Generic;
using System.Web.Mvc;
namespace MvcApplication23.Controllers
{
public class HomeController : Controller
{
[HttpGet]
public ActionResult Index()
{
return View();
}
[HttpPost]
public ActionResult HandleForm1(string tech)
{
return RedirectToAction("Index");
}
}
}
در اینجا سه RadioButton با نامی یکسان در صفحه اضافه شدهاند. سپس داخل متد HandleForm1 یک breakpoint قرار دهید. اکنون برنامه را اجرا کنید و فرم را به سرور ارسال نمائید. پارامتر tech با value عنصر انتخابی مقدار دهی خواهد شد.
تهیه یک RadioButtonList عمومی
اطلاعات فوق را میتوان تبدیل به یک HtmlHelper با قابلیت استفاده مجدد نیز نمود:
@helper RadioButtonList(string groupName, IEnumerable<System.Web.Mvc.SelectListItem> items)
{
<div class="RadioButtonList">
@foreach (var item in items)
{
@item.Text
<input type="radio" name="@groupName"
value="@item.Value"
@if (item.Selected) { <text>checked="checked"</text> }
/>
<br />
}
</div>
}
برای مثال یک فایل را در مسیر app_code\Helpers.cshtml ایجاد کرده و اطلاعات فوق را به آن اضافه نمائید.
اینبار برای استفاده از آن خواهیم داشت:
using System.Collections.Generic;
using System.Web.Mvc;
namespace MvcApplication23.Controllers
{
public class HomeController : Controller
{
[HttpGet]
public ActionResult Index()
{
ViewBag.Tags = new[]
{
new SelectListItem { Text = ".NET", Value = "Val1", Selected = true },
new SelectListItem { Text = "JAVA", Value = "Val2", Selected = false },
new SelectListItem { Text = "PHP", Value = "Val3", Selected = false }
};
return View();
}
[HttpPost]
public ActionResult HandleForm2(string preferredTechnology)
{
return RedirectToAction("Index");
}
}
}
@{
ViewBag.Title = "Index";
}
<h2>
Index</h2>
<fieldset>
<legend>HandleForm2 (Helper)</legend>
@using (Html.BeginForm(actionName: "HandleForm2", controllerName: "Home"))
{
@:your favorite tech: <br />
@Helpers.RadioButtonList("preferredTechnology", (SelectListItem[])ViewBag.Tags)
<input type="submit" value="Submit" />
}
</fieldset>
متد سفارشی تهیه شده، یک آرایه از SelectListItem ها را دریافت کرده و به صورت خودکار تبدیل به RadioButtonList میکند. بر اساس نام آن میتوان به مقدار انتخاب شده ارسالی به سرور در کنترلر مرتبط، دسترسی یافت.
تهیه یک Templated helper سفارشی
در عمل زمانیکه با مدلها کار میکنیم و اطلاعات برنامه قرار است Strongly typed باشند، مرسوم است لیستی از انتخابها را به صورت یک enum تعریف کنند. برای مثال مدل زیر را به برنامه اضافه کنید:
using System.ComponentModel.DataAnnotations;
namespace MvcApplication23.Models
{
public enum Gender
{
[Display(Name = "مرد")]
Male,
[Display(Name = "زن")]
Female,
}
public class User
{
[ScaffoldColumn(false)]
public int Id { set; get; }
[Display(Name = "نام")]
public string Name { set; get; }
[Display(Name = "جنسیت")]
[UIHint("EnumRadioButtonList")]
public Gender Gender { set; get; }
}
}
قصد داریم یک Templated helper سفارشی را به نام EnumRadioButtonList، ایجاد کنیم تا در زمان فراخوانی متد Html.EditorForModel، به صورت خودکار enum تعریف شده را به صورت یک RadioButtonList نمایش دهد.
برای این منظور فایل جدید Views\Shared\EditorTemplates\EnumRadioButtonList.cshtml را به برنامه اضافه کنید. محتوای آنرا به نحو زیر تغییر دهید:
@using System.ComponentModel.DataAnnotations
@using System.Globalization
@model Enum
@{
Func<Enum, string> getDescription = enumItem =>
{
var type = enumItem.GetType();
var memInfo = type.GetMember(enumItem.ToString());
if (memInfo != null && memInfo.Any())
{
var attrs = memInfo[0].GetCustomAttributes(typeof(DisplayAttribute), false);
if (attrs != null && attrs.Any())
return ((DisplayAttribute)attrs[0]).GetName();
}
return enumItem.ToString();
};
var listItems = Enum.GetValues(Model.GetType())
.OfType<Enum>()
.Select(enumItem =>
new SelectListItem()
{
Text = getDescription(enumItem),
Value = enumItem.ToString(),
Selected = enumItem.Equals(Model)
});
string prefix = ViewData.TemplateInfo.HtmlFieldPrefix;
ViewData.TemplateInfo.HtmlFieldPrefix = string.Empty;
int index = 0;
foreach (var li in listItems)
{
string fieldName = string.Format(CultureInfo.InvariantCulture, "{0}_{1}", prefix, index++);
<div class="editor-radio">
@Html.RadioButton(prefix, li.Value, li.Selected, new { @id = fieldName })
@Html.Label(fieldName, li.Text)
</div>
}
ViewData.TemplateInfo.HtmlFieldPrefix = prefix;
}
در اینجا به کمک Reflection به اطلاعات enum دریافتی دسترسی خواهیم داشت. بر این اساس میتوان نام عناصر آنرا یافت و تبدیل به یک RadioButtonList کرد. البته کار به همینجا ختم نمیشود. در این بین باید دقت داشت که ممکن است از ویژگی Display (مانند مدل نمونه فوق) بر روی تک تک عناصر یک enum نیز استفاده شود. به همین جهت این مورد نیز باید پردازش گردد.
نهایتا برای استفاده از این Templated helper سفارشی، کنترلر و View برنامه را به نحو زیر میتوان تغییر داد:
using System.Collections.Generic;
using System.Web.Mvc;
using MvcApplication23.Models;
namespace MvcApplication23.Controllers
{
public class HomeController : Controller
{
[HttpGet]
public ActionResult Index()
{
var user = new User { Id = 1, Name = "name 1", Gender = Gender.Male };
return View(user);
}
[HttpPost]
public ActionResult HandleForm3(User user)
{
return RedirectToAction("Index");
}
}
}
@model MvcApplication23.Models.User
@{
ViewBag.Title = "Index";
}
<h2>
Index</h2>
<fieldset>
<legend>HandleForm3 (EditorForModel)</legend>
@using (Html.BeginForm(actionName: "HandleForm3", controllerName: "Home"))
{
@Html.EditorForModel()
<input type="submit" value="Submit" />
}
</fieldset>
برای استفاده از یک templated helper سفارشی چندین روش وجود دارد:
الف) همانند مثال فوق از ویژگی UIHint استفاده شود.
ب) نام فایل را به enum.cshtml تغییر دهیم. به این ترتیب از این پس کلیه enumها در صورت استفاده از متد Html.EditorForModel، به صورت خودکار تبدیل به یک RadioButtonList میشوند.
ج) متد زیر نیز همین کار را انجام میدهد:
@Html.EditorFor(model => model.EnumProperty, "EnumRadioButtonList")
خیلی ممنونم که این بحث رو مطرح کردید. ولی چیزی که واقعا متوجه نمیشم اینه که چرا باید برنامه نویسی تابعی رو رقیب یا جایگزین برنامه نویسی شی گرا دونست. به نظر من مفاهیمی که این دو روش ارائه میکنن مکمل هم هستن. به عبارتی مطالب مطرح شده میتونه به عنوان رهنمون هایی در برنامه نویسی شی گرا تلقی بشه.
البته در منابع خارجی که مطالعه میکردم تفاوت اصلی رو در این دونسته بودن که در برنامه نویسی تابعی دادهها در شی نگهداری نمیشه و باید در تابع نگه داری و جا بجا بشه! البته نمیدونمن چطور این کار به صورت مطلق میسر هست!
در کل من فکر میکنم اگه قرار باشه این کار به صورت مطلق در تمام حالات انجام بشه خودش به ضد مفاهیمی که در این رهنمونها تاکید شده تبدیل خواهد شد.
فکر نمیکنم بدون استفاده از مفاهیم شی گرایی بشه یه پروژه واقعی و بزرگ رو با استفاده از صرفا مفاهیم برنامه نویسی تابعی به صورت بهتری پیاده کرد!
خیلی ممنون میشم اگه اساتید این بحث رو ادامه بدن و توضیحاتی بدن که آیا من دچار بدفهمی شدم یا خیر.
React به صورت پیشفرض از ES6 برای توسعهی برنامههای خودش استفاده میکند؛ اما استفادهی از TypeScript با پروژههای React، مزایای قابل توجهی را مانند type checking در زمان کامپایل برنامه، دسترسی به intellisense آنی، امکان refactoring بهتر را در اختیار توسعه دهنده قرار میدهد که نه فقط سرعت و سهولت توسعه را افزایش میدهند، بلکه از بروز بسیاری از خطاهای زمان اجرای برنامه نیز جلوگیری میکند.
ایجاد پروژههای React مبتنی بر TypeScript
برای ایجاد ساختار ابتدایی پروژههای React که جهت استفادهی از TypeScript تنظیم شدهاند، دستور زیر را در خط فرمان اجرا میکنیم:
مزیت کار با npx، عدم نیاز به نصب محلی برنامهی create-react-app است. به این ترتیب هربار که این دستور را به این نحو اجرا میکنیم، مطمئن خواهیم بود که از آخرین نگارش برنامهی create-react-app استفاده خواهد شد؛ و نه نگارش محلی که پیشتر نصب کردهایم که ممکن است هم اکنون تاریخ مصرف گذشته باشد.
بنابراین npx create-react-app کار اجرای آخرین نسخهی برنامهی ایجاد ساختار پروژههای React را انجام میدهد. پس از آن یک نام دلخواه ذکر شدهاست و در آخر توسط سوئیچ template typescript-- سبب خواهیم شد تا این ساختار بجای استفادهی از ES6 پیشفرض، بر اساس TypeScript ایجاد و تنظیم شود.
بررسی ساختار پروژهی TypeScript ای ایجاد شده
در تصویر فوق، نمونهای از این ساختار ابتدایی ایجاد شدهی مبتنی بر TypeScript را مشاهده میکنید. اولین تفاوت مهم این ساختار، با ساختار پیشفرض پروژههای React مبتنی بر ES6، وجود فایل جدید tsconfig.json است. کار آن تنظیم پارامترهای کامپایلر TypeScript است. همچنین اینبار بجای پسوندهای js و jsx، پسوندهای ts و tsx قابل مشاهده هستند؛ مانند فایلهای serviceWorker.ts ، index.tsx و App.tsx. البته اگر به ساختار این فایلها دقت کنید، آنچنان تفاوت مهمی را با نمونههای قبلی ES6 خود ندارند و تقریبا یکی هستند. روش اجرای آنها نیز مانند قبل است و با همان دستور npm start صورت میگیرد:
قابلیت استفادهی از کدهای جاوا اسکریپتی موجود، در پروژههای تایپ اسکریپتی جدید
داخل پوشهی src، پوشهی جدید components را ایجاد کرده و داخل آن فایل جدید Head.js را اضافه میکنیم. سپس داخل آن rfac را نوشته و دکمهی tab را فشار میدهیم تا ساختار ابتدایی یک react arrow functional component جدید ایجاد شود:
در ادامه جهت نمایش آن، آنرا به فایل src\App.tsx به شکل متداولی، ابتدا با import تابع آن و سپس درج المان متناظر با آن در تابع App، اضافه میکنیم:
اگر دقت کرده باشید، پسوند این فایل را js درنظر گرفتهایم (src\components\Head.js) و نه ts و بدون مشکل میتوان از آن در داخل یک فایل tsx استفاده کرد. علت آن به وجود تنظیم allowJs در فایل tsconfig.json برنامه بر میگردد. مزیت وجود یک چنین تنظیمی، امکان مهاجرت سادهتر کدهای ES6 موجود، به یک پروژهی تایپ اسکریپتی جدید است. به این ترتیب میتوان از تمام این کدها بدون مشکل در برنامهی جدید خود استفاده کرد و سر فرصت، یکی یکی آنها را به tsx تبدیل نمود.
به همین جهت پس از مشاهدهی این قابلیت، پسوند فایل کامپوننت جدید js ایجاد شده را به tsx تغییر میدهیم (src\components\Head.tsx). البته در یک چنین حالتی اگر هنوز دستور npm start در حال اجرا است، نیاز خواهید داشت یکبار آنرا بسته و مجددا اجرا کنید. پس از آن، باز هم برنامه بدون مشکل کامپایل میشود و نشان دهندهی این است که کدهای نوشته شدهی در کامپوننت Head، کدهای کاملا معتبر تایپ اسکریپتی نیز هستند. علت اینجا است که TypeScript، در حقیقت Superset جاوا اسکریپت بهشمار میرود و قابلیتهای جدیدی را به TypeScript استفاده میکند. بنابراین کدهای جاوااسکریپتی موجود، کدهای معتبر تایپ اسکریپتی نیز بهشمار میروند.
مشخص کردن نوع props کامپوننتها توسط TypeScript
اولین استفادهی ما از TypeScript در اینجا، مشخص کردن نوع props یک کامپوننت است:
برای این منظور، دو خاصیت جدید را از طریق شیء props به این کامپوننت ارسال کرده و از آنها جهت نمایش یک عنوان و تعیین نمایش یک برچسب استفاده میکنیم. اولین موردی را که پس از این تغییر متداول مشاهده میکنیم، خط قرمز کشیده شدن زیر متغیرهای حاصل از Object Destructuring مربوط به شیء props است:
علت اینجا است که این فایل، tsx است و نه js. به همین جهت نوع این متغیرها را، همان حالت پیشفرض جاوا اسکریپت که any است، درنظر گرفتهاست و ... این مورد بر اساس تنظیمات فایل tsconfig.json برنامه، ممنوع است. البته اگر به این فایل دقت کنید، شاید چنین گزینهای را به صورت صریح نتوانید در آن پیدا کنید. علت اینجا است که تعداد گزینههای قابل تنظیم در فایل tsconfig روز به روز بیشتر میشوند. به همین جهت برای ساده سازی فعالسازی آنها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شدهاست. کار آن فعالسازی یکجای تمام بررسیهای strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
در این حالت اگر نیاز به لغو یکی از گزینهها بود، میتوان به صورت ذیل عمل کرد:
گزینهی strict تمام بررسیهای متداول را فعال میکند؛ اما ذکر و تنظیم صریح noImplicitAny به false، تنها این یک مورد را لغو خواهد کرد.
بنابراین چون در فایل tsconfig.json برنامهی React ما گزینهی strict به true تنظیم شدهاست، گزینهی فعال noImplicitAny نیز جزئی از آن است و دیگر نمیتوان متغیر یا خاصیتی را بدون ذکر صریح نوع آن، رها کرد.
برای رفع خطای noImplicitAny موجود، به ابتدای فایل src\components\Head.tsx، نوع جدید Props را اضافه میکنیم (نام آن کاملا دلخواه است):
و سپس از آن جهت مشخص سازی نوع شیء props رسیده، به نحو زیر استفاده خواهیم کرد:
پس از این تغییر، خطای noImplicitAny پیشین، برطرف میشود و دیگر خطوط قرمز ذیل دو متغیر حاصل از Object Destructuring، مشاهده نمیشوند.
یک نکته: البته اگر از سری React 16x بخاطر داشته باشید، میتوان یک چنین قابلیتی را توسط propTypes خود React نیز پیاده سازی کرد:
اما روش کار با TypeScript، نسبت به آن بسیار پیشرفتهتر است. برای کار با TypeScript، نیازی به import یک بستهی جدید، مانند PropTypes نیست و همچنین بررسی PropTypes توسط خود React، در زمان اجرای برنامه صورت میگیرد؛ اما با TypeScript، بررسی زمان کامپایل برنامه را خواهیم داشت و همچنین نمایش آنی خطاهای مرتبط با عدم رعایت آنها، در ادیتورهایی مانند VSCode. به علاوه روش تعریف type ذکر شدهی توسط TypeScript، نسبت به نمونهی پیشنهاد شدهی توسط React با propTypes، بسیار تمیزتر و خواناتر است.
پس از این تغییر، اگر به فایل src\App.tsx مراجعه کنیم، مشاهده میکنیم که ذیل تعریف المان کامپوننت Head، مجددا خط قرمزی کشیده شدهاست:
عنوان میکند که بر اساس نوع جدید Props ای که تعریف کردهاید، نیاز است دو خاصیت اجباری title و isActive را نیز در اینجا ذکر کنید؛ وگرنه تعریف این المان، بدون آنها ناقص است.
امکان جالب دیگری که با تعریف نوع props توسط تایپاسکریپت رخ میدهد، فعال شدن intellisense متناظر با تعریف این خواص و ویژگیها است:
در ادامه با تعریف این دو ویژگی جدید، خط قرمز رنگ ذیل کامپوننت Head برطرف میشود:
و اگر در حین تعریف این ویژگیها، نوعهای مقادیر آنها را به درستی وارد نکنیم، بازهم شاهد تذکر آنی خطاهای مرتبط با آنها خواهیم بود:
همچنین در این حالت، کد برنامه نیز کامپایل نمیشود و ذکر این خطاها صرفا منحصر به ادیتور مورد استفاده نیست.
بنابراین به صورت خلاصه مزیتهای کار با TypeScript برای تعاریف نوع props به شرح زیر است:
- auto-complete و داشتن intellisense خودکار.
- اگر نام المان کامپوننتی و یا نام یکی از props را به اشتباه وارد کنیم، بلافاصله خطای یافت نشدن آنها را نمایش میدهد.
- اگر ذکر یک prop اجباری را فراموش کنیم، بلافاصله خطای متناظری را دریافت میکنیم.
- اگر نوع مقدار یکی از props را به اشتباه وارد کنیم، باز هم خطایی را جهت گوشزد کردن آن مشاهده خواهیم کرد.
- فعال بودن TypeScript، امکان refactoring بسیار قویتری را میسر میکند. برای مثال با فشردن دکمهی F2 میتوان نام یک کامپوننت را در کل برنامه به سادگی تغییر داد. همچنین یک چنین قابلیتی برای تغییر نام props نیز میسر است و به صورت خودکار تمام کاربردهای آنرا نیز به روز میکند.
- اگر نوع prop ای را در تعریف آن تغییر دادیم، اما مقدار منتسب به آنرا خیر، باز هم بلافاصله متوجه این مشکل خواهیم شد.
به این ترتیب با دسترسی به بررسیهای دقیق زمان کامپایل برنامه، میتوان مشکلات بسیار کمتری را در زمان اجرای آن شاهد بود.
ایجاد پروژههای React مبتنی بر TypeScript
برای ایجاد ساختار ابتدایی پروژههای React که جهت استفادهی از TypeScript تنظیم شدهاند، دستور زیر را در خط فرمان اجرا میکنیم:
npx create-react-app tssample --template typescript
بنابراین npx create-react-app کار اجرای آخرین نسخهی برنامهی ایجاد ساختار پروژههای React را انجام میدهد. پس از آن یک نام دلخواه ذکر شدهاست و در آخر توسط سوئیچ template typescript-- سبب خواهیم شد تا این ساختار بجای استفادهی از ES6 پیشفرض، بر اساس TypeScript ایجاد و تنظیم شود.
بررسی ساختار پروژهی TypeScript ای ایجاد شده
در تصویر فوق، نمونهای از این ساختار ابتدایی ایجاد شدهی مبتنی بر TypeScript را مشاهده میکنید. اولین تفاوت مهم این ساختار، با ساختار پیشفرض پروژههای React مبتنی بر ES6، وجود فایل جدید tsconfig.json است. کار آن تنظیم پارامترهای کامپایلر TypeScript است. همچنین اینبار بجای پسوندهای js و jsx، پسوندهای ts و tsx قابل مشاهده هستند؛ مانند فایلهای serviceWorker.ts ، index.tsx و App.tsx. البته اگر به ساختار این فایلها دقت کنید، آنچنان تفاوت مهمی را با نمونههای قبلی ES6 خود ندارند و تقریبا یکی هستند. روش اجرای آنها نیز مانند قبل است و با همان دستور npm start صورت میگیرد:
قابلیت استفادهی از کدهای جاوا اسکریپتی موجود، در پروژههای تایپ اسکریپتی جدید
داخل پوشهی src، پوشهی جدید components را ایجاد کرده و داخل آن فایل جدید Head.js را اضافه میکنیم. سپس داخل آن rfac را نوشته و دکمهی tab را فشار میدهیم تا ساختار ابتدایی یک react arrow functional component جدید ایجاد شود:
import React from "react"; export const Head = () => { return ( <div> <h1>Hello</h1> </div> ); };
import { Head } from "./components/Head"; // ... function App() { return ( <div className="App"> <Head /> // ... </div> ); } export default App;
به همین جهت پس از مشاهدهی این قابلیت، پسوند فایل کامپوننت جدید js ایجاد شده را به tsx تغییر میدهیم (src\components\Head.tsx). البته در یک چنین حالتی اگر هنوز دستور npm start در حال اجرا است، نیاز خواهید داشت یکبار آنرا بسته و مجددا اجرا کنید. پس از آن، باز هم برنامه بدون مشکل کامپایل میشود و نشان دهندهی این است که کدهای نوشته شدهی در کامپوننت Head، کدهای کاملا معتبر تایپ اسکریپتی نیز هستند. علت اینجا است که TypeScript، در حقیقت Superset جاوا اسکریپت بهشمار میرود و قابلیتهای جدیدی را به TypeScript استفاده میکند. بنابراین کدهای جاوااسکریپتی موجود، کدهای معتبر تایپ اسکریپتی نیز بهشمار میروند.
مشخص کردن نوع props کامپوننتها توسط TypeScript
اولین استفادهی ما از TypeScript در اینجا، مشخص کردن نوع props یک کامپوننت است:
import React from "react"; export const Head = ({ title, isActive }) => { return ( <div> <h1>{title}</h1> {isActive && <h3>Active</h3>} </div> ); };
علت اینجا است که این فایل، tsx است و نه js. به همین جهت نوع این متغیرها را، همان حالت پیشفرض جاوا اسکریپت که any است، درنظر گرفتهاست و ... این مورد بر اساس تنظیمات فایل tsconfig.json برنامه، ممنوع است. البته اگر به این فایل دقت کنید، شاید چنین گزینهای را به صورت صریح نتوانید در آن پیدا کنید. علت اینجا است که تعداد گزینههای قابل تنظیم در فایل tsconfig روز به روز بیشتر میشوند. به همین جهت برای ساده سازی فعالسازی آنها، از TypeScript 2.3 به بعد، پرچم strict نیز به این تنظیمات اضافه شدهاست. کار آن فعالسازی یکجای تمام بررسیهای strict است؛ مانند noImplicitAny، strictNullChecks و غیره.
{ "compilerOptions": { "strict": true /* Enable all strict type-checking options. */ } }
{ "compilerOptions": { "strict": true, "noImplicitAny": false } }
بنابراین چون در فایل tsconfig.json برنامهی React ما گزینهی strict به true تنظیم شدهاست، گزینهی فعال noImplicitAny نیز جزئی از آن است و دیگر نمیتوان متغیر یا خاصیتی را بدون ذکر صریح نوع آن، رها کرد.
برای رفع خطای noImplicitAny موجود، به ابتدای فایل src\components\Head.tsx، نوع جدید Props را اضافه میکنیم (نام آن کاملا دلخواه است):
type Props = { title: string; isActive: boolean; };
export const Head = ({ title, isActive }: Props) => {
یک نکته: البته اگر از سری React 16x بخاطر داشته باشید، میتوان یک چنین قابلیتی را توسط propTypes خود React نیز پیاده سازی کرد:
Head.propTypes = { title: PropTypes.string, isActive: PropTypes.bool }
پس از این تغییر، اگر به فایل src\App.tsx مراجعه کنیم، مشاهده میکنیم که ذیل تعریف المان کامپوننت Head، مجددا خط قرمزی کشیده شدهاست:
عنوان میکند که بر اساس نوع جدید Props ای که تعریف کردهاید، نیاز است دو خاصیت اجباری title و isActive را نیز در اینجا ذکر کنید؛ وگرنه تعریف این المان، بدون آنها ناقص است.
امکان جالب دیگری که با تعریف نوع props توسط تایپاسکریپت رخ میدهد، فعال شدن intellisense متناظر با تعریف این خواص و ویژگیها است:
در ادامه با تعریف این دو ویژگی جدید، خط قرمز رنگ ذیل کامپوننت Head برطرف میشود:
<Head title="Hello" isActive={true} />
همچنین در این حالت، کد برنامه نیز کامپایل نمیشود و ذکر این خطاها صرفا منحصر به ادیتور مورد استفاده نیست.
بنابراین به صورت خلاصه مزیتهای کار با TypeScript برای تعاریف نوع props به شرح زیر است:
- auto-complete و داشتن intellisense خودکار.
- اگر نام المان کامپوننتی و یا نام یکی از props را به اشتباه وارد کنیم، بلافاصله خطای یافت نشدن آنها را نمایش میدهد.
- اگر ذکر یک prop اجباری را فراموش کنیم، بلافاصله خطای متناظری را دریافت میکنیم.
- اگر نوع مقدار یکی از props را به اشتباه وارد کنیم، باز هم خطایی را جهت گوشزد کردن آن مشاهده خواهیم کرد.
- فعال بودن TypeScript، امکان refactoring بسیار قویتری را میسر میکند. برای مثال با فشردن دکمهی F2 میتوان نام یک کامپوننت را در کل برنامه به سادگی تغییر داد. همچنین یک چنین قابلیتی برای تغییر نام props نیز میسر است و به صورت خودکار تمام کاربردهای آنرا نیز به روز میکند.
- اگر نوع prop ای را در تعریف آن تغییر دادیم، اما مقدار منتسب به آنرا خیر، باز هم بلافاصله متوجه این مشکل خواهیم شد.
به این ترتیب با دسترسی به بررسیهای دقیق زمان کامپایل برنامه، میتوان مشکلات بسیار کمتری را در زمان اجرای آن شاهد بود.
51- :first-child
تگی را انتخاب میکند که اولین فرزند والد خود باشد.
در مثال فوق Text 1، Text 6و Text 9 به رنگ قرمز نمایش مییابند.
<style> div.container :first-child { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.1 | 9.6 | 7.0 | 3.0 | 4.0 | :first-child | 2 |
52- :last-child
تگی را انتخاب میکند که آخرین فرزند والد خود باشد.
در مثال فوق Text 15، Text 11و Text 9 به رنگ قرمز نمایش مییابند.
<style> div.container :last-child { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :last-child | 3 |
53- :only-child
تگی را انتخاب میکند که تنها فرزند والد خود باشد.
در مثال فوق Text 9 به رنگ قرمز نمایش مییابد.
<style> div.container :only-child { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :only-child | 3 |
54- :nth-child(n)
تگی را انتخاب میکند که nامین فرزند والد خود باشد. به جای n میتوان از مقادیر odd (فرزندان فرد)، even (فرزندان زوج) و an+b استفاده نمود.
در مثال فوق Text 2و Text 7 به رنگ قرمز نمایش مییابند.
<style> div.container :nth-child(2) { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :nth-child(n) | 3 |
55- :nth-last-child(n)
تگی را انتخاب میکند که nامین فرزند والد خود از آخر باشد. به جای n میتوان از مقادیر odd (فرزندان فرد)، even (فرزندان زوج) و an+b استفاده نمود.
در مثال فوق Text 14و Text 10 به رنگ قرمز نمایش مییابند.
<style> div.container :nth-last-child(2) { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :nth-last-child(n) | 3 |
56- :first-of-type
تگی را انتخاب میکند که اولین تگ در بین هم نوعان خودش و در یک والد باشد.
در مثال فوق Text 1، Text 2، Text 3، Text 4، Text 6، Text 7، Text 8، Text 9و Text 10 به رنگ قرمز نمایش مییابند.
<style> div.container :first-of-type { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :first-of-type | 3 |
57- :last-of-type
تگی را انتخاب میکند که آخرین تگ در بین هم نوعان خودش و در یک والد باشد.
در مثال فوق Text 15، Text 14، Text 12، Text 11، Text 10، Text 9، Text 7، Text 6و Text 3 به رنگ قرمز نمایش مییابند.
<style> div.container :last-of-type { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :last-of-type | 3 |
58- :only-of-type
تگی را انتخاب میکند که تنها تگ در بین هم نوعان خودش و در یک والد باشد.
در مثال فوق Text 3، Text 6، Text 7، Text 9 و Text 10 به رنگ قرمز نمایش مییابند.
<style> div.container :only-of-type { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :only-of-type | 3 |
59- :nth-of-type(n)
تگی را انتخاب میکند که nامین تگ در بین هم نوعان خودش و در یک والد باشد. به جای n میتوان از مقادیر odd (فرزندان فرد)، even (فرزندان زوج) و an+b استفاده نمود.
در مثال فوق Text 5، Text 9، Text 12 و Text 14 به رنگ قرمز نمایش مییابند.
<style> div.container :nth-of-type(2) { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :nth-of-type(n) | 3 |
60- nth-last-of-type(n)
تگی را انتخاب میکند که nامین تگ از آخر در بین هم نوعان خودش و در یک والد باشد. به جای n میتوان از مقادیر odd (فرزندان فرد)، even (فرزندان زوج) و an+b استفاده نمود.
در مثال فوق Text 1، Text 2، Text 9 و Text 13 به رنگ قرمز نمایش مییابند.
<style> div.container :nth-last-of-type(2) { color: red; } </style> <div class="container"> <h1>Text 1</h1> <span>Text 2</span> <p>Text 3</p> <div>Text 4</div> <div>Text 5</div> <div> <h1>Text 6</h1> <span>Text 7</span> <p>Text 8</p> <p> <span>Text 9</span> </p> <div>Text 10</div> <p>Text 11</p> </div> <h1>Text 12</h1> <div>Text 13</div> <span>Text 14</span> <div>Text 15</div> </div>
پشتیبانی در مرورگرها:
|
|
|
|
| Selector | نسخه CSS |
3.2 | 9.6 | 9.0 | 3.5 | 4.0 | :nth-last-of-type(n) | 3 |
اگر در کدهای خود قطعه کد ذیل را دارید:
استفادهی از using در اینجا، نهتنها غیرضروری و اشتباه است، بلکه سبب از کار افتادن زود هنگام برنامهی شما با صدور استثنای ذیل خواهد شد:
HttpClient خود را Dispose نکنید
کلاس HttpClient اینترفیس IDisposable را پیاده سازی میکند. بنابراین روش استفادهی اصولی آن باید به صورت ذیل و با پیاده سازی خودکار رهاسازی منابع مرتبط با آن باشد:
اما در این حال فرض کنید به همین روش تعدادی درخواست را ارسال کردهاید:
مشکل این روش، در ایجاد سوکتهای متعددی است که حتی پس از بسته شدن برنامه نیز باز، باقی خواهند ماند:
این یک نمونهی خروجی برنامهی فوق، توسط دستور netstat «پس از بسته شدن کامل برنامه» است.
بنابراین اگر برنامهی شما تعداد زیادی کاربر دارد و یا تعداد زیادی درخواست را به روش فوق ارسال میکند، سیستم عامل به حد اشباع ایجاد سوکتهای جدید خواهد رسید.
این مشکل نیز ارتباطی به طراحی این کلاس و یا زبان #C و حتی استفادهی از using نیز ندارد. این رفتار، رفتار معمول سیستم عامل، با سوکتهای ایجاد شدهاست. TIME_WAIT ایی را که در اینجا ملاحظه میکنید، به معنای بسته شدن اتصال از طرف برنامهی ما است؛ اما سیستم عامل هنوز منتظر نتیجهی نهایی، از طرف دیگر اتصال است که آیا قرار است بستهی TCP ایی را دریافت کند یا خیر و یا شاید در بین راه تاخیری وجود داشتهاست. برای نمونه ویندوز به مدت 240 ثانیه یک اتصال را در این حالت حفظ خواهد کرد، که مقدار آن نیز در اینجا تنظیم میشود:
بنابراین روش توصیه شدهی کار با HttpClient، داشتن یک وهلهی سراسری از آن در برنامه و عدم Dispose آن است. HttpClient نیز thread-safe طراحی شدهاست و دسترسی به یک شیء سراسری آن در برنامههای چند ریسمانی مشکلی را ایجاد نمیکند. همچنین Dispose آن نیز غیرضروری است و پس از پایان برنامه به صورت خودکار توسط سیستم عامل انجام خواهد شد.
تمام اجزای HttpClient به صورت Thread-safe طراحی نشدهاند
تا اینجا به این نتیجه رسیدیم که روش صحیح کار کردن با HttpClient، نیاز به داشتن یک وهلهی Singleton از آنرا در سراسر برنامه دارد و Dispose صریح آن، بجز اشباع سوکتهای سیستم عامل و ناپایدار کردن تمام برنامههایی که از آن سرویس میگیرند، حاصلی را به همراه نخواهد داشت. در این بین مطابق مستندات HttpClient، استفادهی از متدهای ذیل این کلاس thread-safe هستند:
اما تغییر این خواص در کلاس HttpClient به هیچ عنوان thread-safe نبوده و در برنامههای چند ریسمانی و چند کاربری، مشکل ساز میشوند:
بنابراین در طراحی کلاس مدیریت کنندهی HttpClient برنامهی خود نیاز است به ازای هر BaseAddress، یک HttpClient خاص آنرا ایجاد کرد و HttpClientهای سراسری نمیتوانند BaseAddressهای خود را نیز به اشتراک گذاشته و تغییری را در آن ایجاد کنند.
استفادهی سراسری و مجدد از HttpClient، تغییرات DNS را متوجه نمیشود
با طراحی یک کلاس مدیریت کنندهی سراسری HttpClient با طول عمر Singelton، به یک مشکل دیگر نیز برخواهیم خورد: چون در اینجا از اتصالات، استفادهی مجدد میشوند، دیگر تغییرات DNS را لحاظ نخواهند کرد.
برای حل این مشکل، در زمان ایجاد یک HttpClient سراسری، به ازای یک BaseAddress مشخص، باید از ServicePointManager کوئری گرفته و زمان اجارهی اتصال آنرا دقیقا مشخص کنیم:
با اینکار هرچند هنوز هم از اتصالات استفادهی مجدد میشود، اما این استفادهی مجدد، نامحدود نبوده و مدت معینی را پیدا میکند.
طراحی یک کلاس، برای مدیریت سراسری وهلههای HttpClient
تا اینجا به صورت خلاصه به نکات ذیل رسیدیم:
- HttpClient باید به صورت یک وهلهی سراسری Singleton مورد استفاده قرار گیرد. هر وهله سازی مجدد آن 35ms زمان میبرد.
- Dispose یک HttpClient غیرضروری است.
- HttpClient تقریبا thread safe طراحی شدهاست؛ اما تعدادی از خواص آن مانند BaseAddress اینگونه نیستند.
- برای رفع مشکل اتصالات چسبنده (اتصالاتی که هیچگاه پایان نمییابند)، نیاز است timeout آنرا تنظیم کرد.
بنابراین بهتر است این نکات را در یک کلاس به صورت ذیل کپسوله کنیم:
در اینجا به ازای هر baseAddress جدید، یک HttpClient خاص آن ایجاد میشود تا در کل برنامه مورد استفادهی مجدد قرار گیرد. برای مدیریت thread-safe ایجاد HttpClientها نیز از نکتهی مطلب «الگویی برای مدیریت دسترسی همزمان به ConcurrentDictionary» استفاده شدهاست. همچنین نکات تنظیم ConnectionLeaseTimeout و سایر خواص غیر thread-safe کلاس HttpClient نیز در اینجا لحاظ شدهاند.
پس از تدارک این کلاس، نحوهی معرفی آن به سیستم باید به صورت Singleton باشد. برای مثال اگر از ASP.NET Core استفاده میکنید، آنرا به صورت ذیل ثبت کنید:
اکنون، یک نمونه، نحوهی استفادهی از اینترفیس IHttpClientFactory تزریقی به صورت ذیل میباشد:
سرویس IHttpClientFactory یک HttpClient را به ازای host درخواستی ایجاد کرده و در طول عمر برنامه از آن استفادهی مجدد میکند. به همین جهت دیگر مشکل اشباع سوکتها در این سیستم رخ نخواهند داد.
برای مطالعهی بیشتر
You're using HttpClient wrong and it is destabilizing your software
Disposable, Finalizers, and HttpClient
Using HttpClient as it was intended (because you’re not)
Singleton HttpClient? Beware of this serious behaviour and how to fix it
Beware of the .NET HttpClient
Effectively Using HttpClient
using(var client = new HttpClient()) { // do something with http client }
Unable to connect to the remote server System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted.
HttpClient خود را Dispose نکنید
کلاس HttpClient اینترفیس IDisposable را پیاده سازی میکند. بنابراین روش استفادهی اصولی آن باید به صورت ذیل و با پیاده سازی خودکار رهاسازی منابع مرتبط با آن باشد:
using (var client = new HttpClient()) { var result = await client.GetAsync("http://example.com/"); }
for (int i = 0; i < 10; i++) { using (var client = new HttpClient()) { var result = await client.GetAsync("http://example.com/"); Console.WriteLine(result.StatusCode); } }
TCP 192.168.1.6:13996 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13997 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13998 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:13999 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14000 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14001 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14002 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14003 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14004 93.184.216.34:http TIME_WAIT TCP 192.168.1.6:14005 93.184.216.34:http TIME_WAIT
بنابراین اگر برنامهی شما تعداد زیادی کاربر دارد و یا تعداد زیادی درخواست را به روش فوق ارسال میکند، سیستم عامل به حد اشباع ایجاد سوکتهای جدید خواهد رسید.
این مشکل نیز ارتباطی به طراحی این کلاس و یا زبان #C و حتی استفادهی از using نیز ندارد. این رفتار، رفتار معمول سیستم عامل، با سوکتهای ایجاد شدهاست. TIME_WAIT ایی را که در اینجا ملاحظه میکنید، به معنای بسته شدن اتصال از طرف برنامهی ما است؛ اما سیستم عامل هنوز منتظر نتیجهی نهایی، از طرف دیگر اتصال است که آیا قرار است بستهی TCP ایی را دریافت کند یا خیر و یا شاید در بین راه تاخیری وجود داشتهاست. برای نمونه ویندوز به مدت 240 ثانیه یک اتصال را در این حالت حفظ خواهد کرد، که مقدار آن نیز در اینجا تنظیم میشود:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay]
بنابراین روش توصیه شدهی کار با HttpClient، داشتن یک وهلهی سراسری از آن در برنامه و عدم Dispose آن است. HttpClient نیز thread-safe طراحی شدهاست و دسترسی به یک شیء سراسری آن در برنامههای چند ریسمانی مشکلی را ایجاد نمیکند. همچنین Dispose آن نیز غیرضروری است و پس از پایان برنامه به صورت خودکار توسط سیستم عامل انجام خواهد شد.
تمام اجزای HttpClient به صورت Thread-safe طراحی نشدهاند
تا اینجا به این نتیجه رسیدیم که روش صحیح کار کردن با HttpClient، نیاز به داشتن یک وهلهی Singleton از آنرا در سراسر برنامه دارد و Dispose صریح آن، بجز اشباع سوکتهای سیستم عامل و ناپایدار کردن تمام برنامههایی که از آن سرویس میگیرند، حاصلی را به همراه نخواهد داشت. در این بین مطابق مستندات HttpClient، استفادهی از متدهای ذیل این کلاس thread-safe هستند:
CancelPendingRequests DeleteAsync GetAsync GetByteArrayAsync GetStreamAsync GetStringAsync PostAsync PutAsync SendAsync
BaseAddress DefaultRequestHeaders MaxResponseContentBufferSize Timeout
استفادهی سراسری و مجدد از HttpClient، تغییرات DNS را متوجه نمیشود
با طراحی یک کلاس مدیریت کنندهی سراسری HttpClient با طول عمر Singelton، به یک مشکل دیگر نیز برخواهیم خورد: چون در اینجا از اتصالات، استفادهی مجدد میشوند، دیگر تغییرات DNS را لحاظ نخواهند کرد.
برای حل این مشکل، در زمان ایجاد یک HttpClient سراسری، به ازای یک BaseAddress مشخص، باید از ServicePointManager کوئری گرفته و زمان اجارهی اتصال آنرا دقیقا مشخص کنیم:
var sp = ServicePointManager.FindServicePoint(new Uri("http://thisisasample.com")); sp.ConnectionLeaseTimeout = 60*1000; //In milliseconds
طراحی یک کلاس، برای مدیریت سراسری وهلههای HttpClient
تا اینجا به صورت خلاصه به نکات ذیل رسیدیم:
- HttpClient باید به صورت یک وهلهی سراسری Singleton مورد استفاده قرار گیرد. هر وهله سازی مجدد آن 35ms زمان میبرد.
- Dispose یک HttpClient غیرضروری است.
- HttpClient تقریبا thread safe طراحی شدهاست؛ اما تعدادی از خواص آن مانند BaseAddress اینگونه نیستند.
- برای رفع مشکل اتصالات چسبنده (اتصالاتی که هیچگاه پایان نمییابند)، نیاز است timeout آنرا تنظیم کرد.
بنابراین بهتر است این نکات را در یک کلاس به صورت ذیل کپسوله کنیم:
using System; using System.Collections.Generic; using System.Net.Http; namespace HttpClientTips { public interface IHttpClientFactory : IDisposable { HttpClient GetOrCreate( Uri baseAddress, IDictionary<string, string> defaultRequestHeaders = null, TimeSpan? timeout = null, long? maxResponseContentBufferSize = null, HttpMessageHandler handler = null); } }
using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.Net; using System.Net.Http; using System.Threading; namespace HttpClientTips { /// <summary> /// Lifetime of this class should be set to `Singleton`. /// </summary> public class HttpClientFactory : IHttpClientFactory { // 'GetOrAdd' call on the dictionary is not thread safe and we might end up creating the HttpClient more than // once. To prevent this Lazy<> is used. In the worst case multiple Lazy<> objects are created for multiple // threads but only one of the objects succeeds in creating the HttpClient. private readonly ConcurrentDictionary<Uri, Lazy<HttpClient>> _httpClients = new ConcurrentDictionary<Uri, Lazy<HttpClient>>(); private const int ConnectionLeaseTimeout = 60 * 1000; // 1 minute public HttpClientFactory() { // Default is 2 minutes: https://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.dnsrefreshtimeout(v=vs.110).aspx ServicePointManager.DnsRefreshTimeout = (int)TimeSpan.FromMinutes(1).TotalMilliseconds; // Increases the concurrent outbound connections ServicePointManager.DefaultConnectionLimit = 1024; } public HttpClient GetOrCreate( Uri baseAddress, IDictionary<string, string> defaultRequestHeaders = null, TimeSpan? timeout = null, long? maxResponseContentBufferSize = null, HttpMessageHandler handler = null) { return _httpClients.GetOrAdd(baseAddress, uri => new Lazy<HttpClient>(() => { // Reusing a single HttpClient instance across a multi-threaded application means // you can't change the values of the stateful properties (which are not thread safe), // like BaseAddress, DefaultRequestHeaders, MaxResponseContentBufferSize and Timeout. // So you can only use them if they are constant across your application and need their own instance if being varied. var client = handler == null ? new HttpClient { BaseAddress = baseAddress } : new HttpClient(handler, disposeHandler: false) { BaseAddress = baseAddress }; setRequestTimeout(timeout, client); setMaxResponseBufferSize(maxResponseContentBufferSize, client); setDefaultHeaders(defaultRequestHeaders, client); setConnectionLeaseTimeout(baseAddress, client); return client; }, LazyThreadSafetyMode.ExecutionAndPublication)).Value; } public void Dispose() { foreach (var httpClient in _httpClients.Values) { httpClient.Value.Dispose(); } } private static void setConnectionLeaseTimeout(Uri baseAddress, HttpClient client) { // This ensures connections are used efficiently but not indefinitely. client.DefaultRequestHeaders.ConnectionClose = false; // keeps the connection open -> more efficient use of the client ServicePointManager.FindServicePoint(baseAddress).ConnectionLeaseTimeout = ConnectionLeaseTimeout; // ensures connections are not used indefinitely. } private static void setDefaultHeaders(IDictionary<string, string> defaultRequestHeaders, HttpClient client) { if (defaultRequestHeaders == null) { return; } foreach (var item in defaultRequestHeaders) { client.DefaultRequestHeaders.Add(item.Key, item.Value); } } private static void setMaxResponseBufferSize(long? maxResponseContentBufferSize, HttpClient client) { if (maxResponseContentBufferSize.HasValue) { client.MaxResponseContentBufferSize = maxResponseContentBufferSize.Value; } } private static void setRequestTimeout(TimeSpan? timeout, HttpClient client) { if (timeout.HasValue) { client.Timeout = timeout.Value; } } } }
پس از تدارک این کلاس، نحوهی معرفی آن به سیستم باید به صورت Singleton باشد. برای مثال اگر از ASP.NET Core استفاده میکنید، آنرا به صورت ذیل ثبت کنید:
namespace HttpClientTips.Web { public class Startup { public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IHttpClientFactory, HttpClientFactory>(); services.AddMvc(); }
اکنون، یک نمونه، نحوهی استفادهی از اینترفیس IHttpClientFactory تزریقی به صورت ذیل میباشد:
namespace HttpClientTips.Web.Controllers { public class HomeController : Controller { private readonly IHttpClientFactory _httpClientFactory; public HomeController(IHttpClientFactory httpClientFactory) { _httpClientFactory = httpClientFactory; } public async Task<IActionResult> Index() { var host = new Uri("http://localhost:5000"); var httpClient = _httpClientFactory.GetOrCreate(host); var responseMessage = await httpClient.GetAsync("home/about").ConfigureAwait(false); var responseContent = await responseMessage.Content.ReadAsStringAsync().ConfigureAwait(false); return Content(responseContent); }
برای مطالعهی بیشتر
You're using HttpClient wrong and it is destabilizing your software
Disposable, Finalizers, and HttpClient
Using HttpClient as it was intended (because you’re not)
Singleton HttpClient? Beware of this serious behaviour and how to fix it
Beware of the .NET HttpClient
Effectively Using HttpClient
نظرات مطالب
Angular CLI - قسمت اول - نصب و راه اندازی
در حین نصب CLI مشکل زیر برای شما بوجود نیامده؟
npm ERR! Windows_NT 10.0.10586 npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install" "-g" "@angular/cli" npm ERR! node v7.10.0 npm ERR! npm v4.2.0 npm ERR! Cannot read property 'path' of null npm ERR! npm ERR! If you need help, you may report this error at: npm ERR! <https://github.com/npm/npm/issues> npm ERR! Please include the following file with any support request: npm ERR! C:\Users\payervand\AppData\Roaming\npm-cache\_logs\2017-05-13T05_43_04_935Z-debug.log
اگر نام کنترلهای ارسال فایل سمت کلاینت یکسان نباشند، هر کدام را باید به عنوان یک پارامتر جدید اکشن متد تعریف کرد و یا میتوان از طریق آرایهی Request.Files، بدون ذکر پارامتری در اکشن متد، به تمام آنها دسترسی پیدا کرد:
foreach (string file in Request.Files) { var hpf = Request.Files[file] as HttpPostedFileBase; // todo: save it }