مطالب
مستند سازی ASP.NET Core 2x API توسط OpenAPI Swagger - قسمت پنجم - تکمیل مستندات نوع و فرمت‌های مجاز خروجی و دریافتی API
زمانیکه کنترلر یک API را توسط قالب‌های پیش‌فرض آن ایجاد می‌کنیم، یک سری اکشن متد پیش‌فرض Get/Post/Put/Delete در آن قابل مشاهده هستند. می‌توان این نوع خروجی این نوع متدها را به نحو ساده‌تری نیز مستند کرد:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class ConventionTestsController : ControllerBase
    {
        // GET: api/ConventionTests/5
        [HttpGet("{id}", Name = "Get")]
        [ApiConventionMethod(typeof(DefaultApiConventions), nameof(DefaultApiConventions.Get))]
        public string Get(int id)
        {
            return "value";
        }
در اینجا با ذکر ویژگی ApiConventionMethod، از نوع DefaultApiConventions، برای تولید مستندات خروجی متدی از نوع Get استفاده شده‌است. اگر به تعریف کلاس توکار  DefaultApiConventions مراجعه کنیم، در مورد متد Get، یک چنین ویژگی‌هایی را به صورت خودکار اعمال می‌کند:
using Microsoft.AspNetCore.Mvc.ApiExplorer;

namespace Microsoft.AspNetCore.Mvc
{
    public static class DefaultApiConventions
    {
        [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
        [ProducesDefaultResponseType]
        [ProducesResponseType(200)]
        [ProducesResponseType(404)]
        public static void Get(
[ApiConventionNameMatch(ApiConventionNameMatchBehavior.Suffix)]
[ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)] 
object id);
    }
}
البته باید دقت داشت که DefaultApiConventions برای قالب پیش‌فرض کنترلرهای API طراحی شده‌است و همچنین اگر فیلترهای سراسری را مانند قسمت قبل فعال کرده باشیم، اعمال نخواهند شد و از همان فیلترهای سراسری استفاده می‌شود.
امکان اعمال DefaultApiConventions به تمام متدهای یک کنترلر API نیز به صورت زیر با استفاده از ویژگی ApiConventionType اعمال شده‌ی به کلاس کنترلر میسر است:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    [ApiConventionType(typeof(DefaultApiConventions))]
    public class ConventionTestsController : ControllerBase
یا حتی می‌توان بجای اعمال دستی ApiConventionType به تمام کنترلرهای API، آن‌را به کل پروژه و اسمبلی جاری اعمال کرد:
[assembly: ApiConventionType(typeof(DefaultApiConventions))]
namespace OpenAPISwaggerDoc.Web
{
    public class Startup
اینکار را در کلاس Startup و پیش‌از تعریف فضای نام آن به نحو فوق می‌توان انجام داد. به این ترتیب DefaultApiConventions، به تمام کنترلرهای موجود در این اسمبلی اعمال می‌شوند. بنابراین با اعمال سراسری آن می‌توان ApiConventionType اعمالی بر کلاس ConventionTestsController را حذف کرد.


ایجاد ApiConventions سفارشی

همانطور که عنوان شد، اگر متدهای API شما دقیقا همان نام‌های پیش‌فرض Get/Post/Put/Delete را داشته باشند، توسط DefaultApiConventions مدیریت خواهند شد. در سایر حالات، مثلا اگر بجای نام Post، از نام Insert استفاده شد، باید ApiConventions سفارشی را ایجاد کرد:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.ApiExplorer;

namespace OpenAPISwaggerDoc.Web.AppConventions
{
    public static class CustomConventions
    {
        [ProducesDefaultResponseType]
        [ProducesResponseType(StatusCodes.Status201Created)]
        [ProducesResponseType(StatusCodes.Status400BadRequest)]
        [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Prefix)]
        public static void Insert(
            [ApiConventionNameMatch(ApiConventionNameMatchBehavior.Any)]
            [ApiConventionTypeMatch(ApiConventionTypeMatchBehavior.Any)]
            object model)
        { }
    }
}
همانطور که ملاحظه می‌کنید، نحوه‌ی تشکیل این کلاس، با public static class DefaultApiConventions توکاری که پیشتر در مورد آن بحث شد، یکی است. نوع کلاس آن static است و با نام متدی که قصد اعمال به آن‌را داریم، سازگاری دارد. سپس تعدادی ویژگی خاص، به این متد اعمال شده‌اند.
پس از آن برای اعمال این ApiConventions جدید می‌توان به صورت زیر عمل کرد:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class ConventionTestsController : ControllerBase
    {
        [HttpPost]
        [ApiConventionMethod(typeof(CustomConventions), nameof(CustomConventions.Insert))]
        public void Insert([FromBody] string value)
        {
        }
در اینجا حالت نوع ApiConventionMethod به کلاس جدید CustomConventions اشاره می‌کند و نام متد آن نیز Insert درنظر گرفته شده‌است. در این حالت حتی اگر نام این اکشن متد را به InsertTest تغییر دهیم، باز هم کار می‌کند؛ چون بر اساس پارامتر دوم ویژگی ApiConventionMethod عمل کرده و متد متناظر را پیدا می‌کند. اما اگر آن‌را توسط ApiConventionType به خود کنترلر اعمال کنیم، فقط بر اساس ApiConventionNameMatch است که باز هم به متد InsertTest اعمال خواهد شد؛ چون در اینجا Prefix همان معنای StartsWith را می‌دهد. به علاوه در اینجا object model به عنوان پارامتر تعریف شده‌است و در سمت اکشن متد کنترلر، string value را داریم. در این مورد نیز ویژگی‌های اعمال شده به معنای صرفنظر از نوع و نام پارامتر تعریف شده‌ی در ApiConvention ما هستند (Any در اینجا به معنای صرفنظر از تطابق دقیق است).


سؤال: آیا استفاده‌ی از این ApiConventions ایده‌ی خوبی است؟

همانطور که در ابتدای بحث نیز عنوان شد، اگر فیلترهای سراسری را مانند قسمت قبل فعال کرده باشیم، از اعمال ApiConventions صرفنظر می‌شود. همچنین حالت پیش‌فرض آن‌ها برای حالت‌های متداول و ساده مفید هستند و برای سایر حالات باید کدهای زیادی را نوشت. به همین جهت خود مایکروسافت هم استفاده‌ی از ApiConventions را صرفا برای کنترلرهای API ای که دقیقا مطابق با قالب پیش‌فرض آن‌ها تهیه شده‌اند، توصیه می‌کند. بنابراین استفاده‌ی از Attributes که در قسمت قبل آن‌ها را بررسی کردیم، مقدم هستند بر استفاده‌ی از ApiConventions و تعدادی از بهترین تجربه‌های کاربری در این زمینه به شرح زیر می‌باشند:
- از API Analyzers که در قسمت قبل معرفی شد، برای یافتن کمبودهای نقایص مستندات استفاده کنید.
- از ویژگی ProducesDefaultResponseType استفاده کنید؛ اما تا جائیکه می‌توانید، جزئیات ممکن را به صورت صریحی مستند نمائید.
- Attributes را به صورت سراسری معرفی کنید.


بهبود مستندات Content negotiation

فرض کنید می‌خواهید لیست کتاب‌های یک نویسنده را دریافت کنید. در اینجا خروجی ارائه شده، با فرمت JSON تولید می‌شود؛ اما ممکن است XML ای نیز باشد و یا حالت‌های دیگر، بسته به تنظیمات برنامه. کار Content negotiation این است که مصرف کننده‌ی یک API، دقیقا مشخص کند، چه نوع فرمت خروجی را مدنظر دارد. هدری که برای این منظور استفاده می‌شود، accept header نام‌دارد و ذکر آن اجباری است؛ هر چند تعدادی از APIها بدون وجود آن نیز سعی می‌کنند حالت پیش‌فرضی را ارائه دهند.


Swagger-UI به نحوی که در تصویر فوق ملاحظه می‌کنید، امکان انتخاب Accept header را مسیر می‌کند. در این حالت اگر application/json را انتخاب کنیم، خروجی JSON ای را دریافت می‌کنیم. اما اگر text/plain را انتخاب کنیم، چون توسط API ما پشتیبانی نمی‌شود، خروجی از نوع 406 یا همان Status406NotAcceptable را دریافت خواهیم کرد. بنابراین وجود گزینه‌ی text/plain در اینجا غیرضروری و گمراه کننده‌است و نیاز است این مشکل را برطرف کرد:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Produces("application/json")]
    [Route("api/authors/{authorId}/books")]
    [ApiController]
    public class BooksController : ControllerBase
در اینجا ویژگی جدیدی را به نام Produces مشاهده می‌کنید که به کل اکشن متدهای یک کنترلر API اضافه شده‌است. کار آن محدود کردن فرمت خروجی اکشن متدها با ذکر media-types مورد نظر است.
پس از اعمال این ویژگی، تاثیر آن‌را بر روی Swagger-UI در شکل زیر مشاهده می‌کنید که اینبار تنها به یک مورد مشخص، محدود شده‌است:


در اینجا اگر قصد داشته باشیم خروجی XML را نیز پشتیبانی کنیم، می‌توان به صورت زیر عمل کرد:
- ابتدا در کلاس Startup، نیاز است OutputFormatter متناظری را به سیستم معرفی نمود:
namespace OpenAPISwaggerDoc.Web
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc(setupAction =>
            {
                setupAction.OutputFormatters.Add(new XmlSerializerOutputFormatter());
- سپس ویژگی Produces را نیز تکمیل می‌کنیم تا این نوع خروجی را پشتیبانی کند:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Produces("application/json", "application/xml")]
    [Route("api/authors/{authorId}/books")]
    [ApiController]
    public class BooksController : ControllerBase
با این خروجی:

نکته‌ی مهم: اگر Produces را اصلاح نکنیم، تعریف XmlSerializerOutputFormatter و ارسال یک درخواست با هدر Accept از نوع application/xml، هیچ تاثیری نداشته و باز هم JSON بازگشت داده می‌شود.


در این حالت اگر Controls Accept header را در UI از نوع xml انتخاب کنیم و سپس با کلیک بر روی دکمه‌ی try it out و ذکر id یک نویسنده، لیست کتاب‌های او را درخواست کنیم، خروجی نهایی XML ای آن قابل مشاهده خواهد بود:


البته تا اینجا فقط Swagger-UI را جهت محدود کردن به دو نوع خروجی با فرمت JSON و XML، اصلاح کرده‌ایم؛ اما این مورد به معنای محدود کردن سایر ابزارهای آزمایش یک API مانند postman نیست. در این نوع موارد، تمام مدیاتایپ‌های ارسالی پشتیبانی نشده، سبب تولید خروجی با فرمت JSON می‌شوند. برای محدود کردن آن‌ها به خروجی از نوع 406 می‌توان تنظیم ReturnHttpNotAcceptable را به true انجام داد تا اگر برای مثال درخواست application/xyz ارسال شد، صرفا یک استثناء بازگشت داده شود و نه خروجی JSON:

namespace OpenAPISwaggerDoc.Web
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc(setupAction =>
            {
                setupAction.ReturnHttpNotAcceptable = true; // Status406NotAcceptable


بهبود مستندات نوع بدنه‌ی درخواست


تا اینجا فرمت accept header را دقیقا مشخص و مستند کردیم؛ اما اگر به تصویر فوق دقت کنید، در حین ارسال اطلاعاتی از نوع POST به سرور، چندین نوع Request body را می‌توان انتخاب کرد که الزاما تمام آن‌ها توسط API ما پشتیبانی نمی‌شود. برای رفع این مشکل می‌توان از ویژگی Consumes استفاده کرد که نوع مدیتاتایپ‌های مجاز ورودی را مشخص می‌کند:
namespace OpenAPISwaggerDoc.Web.Controllers
{
    [Produces("application/json", "application/xml")]
    [Route("api/authors/{authorId}/books")]
    [ApiController]
    public class BooksController : ControllerBase
    {
        /// <summary>
        /// Create a book for a specific author
        /// </summary>
        /// <param name="authorId">The id of the book author</param>
        /// <param name="bookForCreation">The book to create</param>
        /// <returns>An ActionResult of type Book</returns>
        [HttpPost()]
        [Consumes("application/json")]
        [ProducesResponseType(StatusCodes.Status201Created)]
        [ProducesResponseType(StatusCodes.Status404NotFound)]
        public async Task<ActionResult<Book>> CreateBook(
            Guid authorId,
            [FromBody] BookForCreation bookForCreation)
        {
بعد از این تغییر، نوع بدنه‌ی درخواست نیز محدود می‌شود:



کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید: OpenAPISwaggerDoc-05.zip
مطالب
پیاده سازی Unobtrusive Ajax در ASP.NET Core 1.0
پیاده سازی Unobtrusive Ajax را در ASP.NET MVC 5.x، می‌توانید در مطلب «ASP.NET MVC #21» مطالعه کنید. HTML Helpers مرتبط با Ajax، به طور کامل از ASP.NET Core 1.0 حذف شده‌اند. اما این مورد به این معنا نیست که نمی‌توان Unobtrusive Ajax را در ASP.NET Core که تمرکزش بیشتر بر روی Tag Helpers جدید هست تا HTML Helpers قدیمی، پیاده سازی کرد.


Unobtrusive Ajax چیست؟

در حالت معمولی، با استفاده از متد ajax جی‌کوئری، کار ارسال غیرهمزمان اطلاعات، به سمت سرور صورت می‌گیرد. چون در این روش کدهای جی‌کوئری داخل صفحات برنامه‌های ما قرار می‌گیرند، به این روش، «روش چسبنده» می‌گویند. اما با استفاده از افزونه‌ی «jquery.unobtrusive-ajax.min.js» مایکروسافت، می‌توان این کدهای چسبنده را تبدیل به کدهای غیرچسنبده یا Unobtrusive کرد. در این حالت، پارامترهای متد ajax، به صورت ویژگی‌ها (attributes) به شکل data-ajax به المان‌های مختلف صفحه اضافه می‌شوند و به این ترتیب، افزونه‌ی یاد شده به صورت خودکار با یافتن مقادیر ویژگی‌های data-ajax، این المان‌ها را تبدیل به المان‌های ای‌جکسی می‌کند. در این حالت به کدهایی تمیزتر و عاری از متدهای چسبنده‌ی ajax قرار گرفته‌ی در داخل صفحات وب خواهیم رسید.
روش طراحی Unobtrusive را در کتابخانه‌های معروفی مانند بوت استرپ هم می‌توان مشاهده کرد.


پیشنیازهای فعال سازی Unobtrusive Ajax در ASP.NET Core 1.0

توزیع افزونه‌ی «jquery.unobtrusive-ajax.min.js» مایکروسافت، از طریق bower صورت می‌گیرد که پیشتر در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 14 - فعال سازی اعتبارسنجی ورودی‌های کاربران» با آن آشنا شدیم. در اینجا نیز برای دریافت آن، تنها کافی است فایل bower.json را به نحو ذیل تکمیل کرد:
{
  "name": "asp.net",
  "private": true,
  "dependencies": {
   "bootstrap": "3.3.6",
   "jquery": "2.2.0",
   "jquery-validation": "1.14.0",
   "jquery-validation-unobtrusive": "3.2.6",
   "jquery-ajax-unobtrusive": "3.2.4"
  }
}
و پس از آن فایل bundleconfig.json مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 21 - بررسی تغییرات Bundling و Minification» یک چنین شکلی را پیدا می‌کند:
[
  {
   "outputFileName": "wwwroot/css/site.min.css",
   "inputFiles": [
    "bower_components/bootstrap/dist/css/bootstrap.min.css",
    "content/site.css"
   ]
  },
  {
   "outputFileName": "wwwroot/js/site.min.js",
   "inputFiles": [
    "bower_components/jquery/dist/jquery.min.js",
    "bower_components/jquery-validation/dist/jquery.validate.min.js",
    "bower_components/jquery-validation-unobtrusive/jquery.validate.unobtrusive.min.js",
    "bower_components/jquery-ajax-unobtrusive/jquery.unobtrusive-ajax.min.js",
    "bower_components/bootstrap/dist/js/bootstrap.min.js"
   ],
   "minify": {
    "enabled": true,
    "renameLocals": true
   },
   "sourceMap": false
  }
]
در اینجا فایل‌های css و اسکریپت مورد نیاز برنامه، به ترتیب اضافه شده و یکی خواهند شد. خروجی نهایی آن‌ها به شکل زیر در صفحات وب مورد استفاده قرار می‌گیرند:
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>@ViewBag.Title - My ASP.NET Application</title>
    <link href="~/css/site.min.css" rel="stylesheet" />
</head>
<body>
    <div>
        <div>
                @RenderBody()
        </div>
    </div>

    <script src="~/js/site.min.js" type="text/javascript" asp-append-version="true"></script>
    @RenderSection("Scripts", required: false)
</body>
</html>
در اینجا تنها دو فایل نهایی این عملیات، یعنی css/site.min.css و js/site.min.js به صفحه الحاق شده‌اند که حاوی تمام پیشنیازهای اسکریپتی و شیوه‌نامه‌های برنامه هستند و در این حالت دیگر نیاز به افزودن آن‌ها به دیگر صفحات سایت نیست.


استفاده از معادل‌های واقعی Unobtrusive Ajax در ASP.NET Core 1.0

واقعیت این است که HTML Helper ای‌جکسی حذف شده‌ی از ASP.NET Core 1.0، کاری بجز افزودن ویژگی‌های data-ajax را که توسط افزونه‌ی jquery.unobtrusive-ajax.min.js پردازش می‌شوند، انجام نمی‌دهد و این افزونه مستقل است از مباحث سمت سرور و به نگارش خاصی از ASP.NET گره نخورده است. بنابراین در اینجا تنها کاری را که باید انجام داد، استفاده از همان ویژگی‌های اصلی است که این افزونه قادر به شناسایی آن‌ها است.
خلاصه‌ی آن‌ها را جهت انتقال کدهای قدیمی و یا تهیه‌ی کدهای جدید، در جدول ذیل می‌توانید مشاهده کنید:

 HTML attribute   AjaxOptions 
 data-ajax-confirm   Confirm 
 data-ajax-method   HttpMethod 
 data-ajax-mode   InsertionMode 
 data-ajax-loading-duration   LoadingElementDuration 
 data-ajax-loading   LoadingElementId 
 data-ajax-begin   OnBegin 
 data-ajax-complete   OnComplete 
 data-ajax-failure   OnFailure 
 data-ajax-success   OnSuccess 
 data-ajax-update   UpdateTargetId 
 data-ajax-url   Url 
   
در ASP.NET Core 1.0، به علت حذف متدهای کمکی Ajax دیگر خبری از AjaxOptions نیست. اما اگر علاقمند به انتقال کدهای قدیمی به ASP.NET Core 1.0 هستید، معادل‌های اصلی این پارامترها را می‌توانید در ستون HTML attribute مشاهده کنید.

چند نکته:
- اگر قصد استفاده‌ی از این ویژگی‌ها را دارید، باید ویژگی "data-ajax="true را نیز حتما قید کنید تا سیستم Unobtrusive Ajax فعال شود.
- ویژگی data-ajax-mode تنها با ذکر data-ajax-update (و یا همان UpdateTargetId پیشین) معنا پیدا می‌کند.
- ویژگی data-ajax-loading-duration نیاز به ذکر data-ajax-loading (و یا همان LoadingElementId پیشین) را دارد.
- ویژگی data-ajax-mode مقادیر before، after و replace-with را می‌پذیرد. اگر قید نشود، کل المان با data دریافتی جایگزین می‌شود.
- سه callback قابل تعریف data-ajax-complete، data-ajax-failure و data-ajax-success، یک چنین پارامترهایی را از سمت سرور در اختیار کلاینت قرار می‌دهند:

parameters  
 Callback  
 xhr, status   data-ajax-complete 
 data, status, xhr   data-ajax-success 
 xhr, status, error   data-ajax-failure 

برای مثال می‌توان ویژگی data-ajax-success را به نحو ذیل در سمت کلاینت مقدار دهی کرد:
 data-ajax-success = "myJsMethod"
این متد جاوا اسکریپتی یک چنین امضایی را دارد:
  function myJsMethod(data, status, xhr) {
}
در این حالت در سمت سرور، پارامتر data در یک اکشن متد، به صورت ذیل مقدار دهی می‌شود:
 return Json(new { param1 = 1, param2 = 2, ... });
و در سمت کلاینت در متد myJsMethod این پارامترها را به صورت data.param1 می‌توان دریافت کرد.


مثال‌هایی از افزودن ویژگی‌های data-ajax به المان‌های مختلف

 در حالت استفاده از Form Tag Helpers که در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 12 - معرفی Tag Helpers» بررسی شدند، یک فرم ای‌جکسی، چنین تعاریفی را پیدا خواهد کرد:
با این ViewModel فرضی
using System.ComponentModel.DataAnnotations;
 
namespace Core1RtmEmptyTest.ViewModels.Account
{
    public class RegisterViewModel
    {
        [Required]
        [EmailAddress]
        [Display(Name = "Email")]
        public string Email { get; set; }
    }
}
که در View متناظر Ajax ایی ذیل استفاده شده‌است:
@using Core1RtmEmptyTest.ViewModels.Account
@model RegisterViewModel
@{
}
 
<form method="post"
      asp-controller="TestAjax"
      asp-action="Index"
      asp-route-returnurl="@ViewBag.ReturnUrl"
      class="form-horizontal"
      role="form"
      data-ajax="true"
      data-ajax-loading="#Progress"
      data-ajax-success="myJsMethod">
 
    <input asp-for="Email" class="form-control" />
    <span asp-validation-for="Email" class="text-danger"></span>
 
    <button type="submit">ارسال</button>
 
    <div id="Progress" style="display: none">
        <img src="images/loading.gif" alt="loading..." />
    </div>
</form>
 
@section scripts{
    <script type="text/javascript">
        function myJsMethod(data, status, xhr) {
            alert(data.param1);
        }
    </script>
}
در اینجا تمام تعاریف مانند قبل است؛ تنها سه ویژگی data-ajax جهت فعال سازی jquery-ajax-unobtrusive به فرم اضافه شده‌اند. همچنین یک callback دریافت پیام موفقیت آمیز بودن عملیات Ajax ایی نیز تعریف شده‌است.

این View از کنترلر ذیل استفاده می‌کند:
using Core1RtmEmptyTest.ViewModels.Account;
using Microsoft.AspNetCore.Mvc;
 
namespace Core1RtmEmptyTest.Controllers
{
    public class TestAjaxController : Controller
    {
 
        public IActionResult Index()
        {
            return View();
        }
 
        [HttpPost]
        public IActionResult Index([FromForm]RegisterViewModel vm)
        {
            var ajax = isAjax();
            if (ajax)
            {
                // it's an ajax post
            }
 
 
            if (ModelState.IsValid)
            {
                //todo: save data
 
                return Json(new { param1 = 1, param2 = 2 });
            }
            return View();
        }
 
        private bool isAjax()
        {
            return Request?.Headers != null && Request.Headers["X-Requested-With"] == "XMLHttpRequest";
        }
    }
}
به ASP.NET Core 1.0، متد کمکی IsAjax اضافه نشده‌است؛ اما تعریف آن‌را در این کنترلر مشاهده می‌کنید. در مورد قید FromForm در ادامه توضیح داده خواهد شد (هرچند در این مورد خاص، حالت پیش فرض است و الزامی به قید آن نیست).

و یا Action Link ای‌جکسی نیز به صورت خلاصه به این نحو قابل تعریف است:
<div id="EmployeeInfo">
<a 
 asp-controller="MyController" asp-action="MyAction"
 data-ajax="true" 
 data-ajax-loading="#Progress" 
 data-ajax-method="POST" 
 data-ajax-mode="replace" 
 data-ajax-update="#EmployeeInfo">
 Get Employee-1 info
</a>

  <div id="Progress" style="display: none">
    <img src="images/loading.gif" alt="loading..."  />
  </div>
</div>


نکته‌ای در مورد اکشن متدهای ای‌جکسی در ASP.NET Core 1.0

همانطور که در مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 18 - کار با ASP.NET Web API»، قسمت «تغییرات Model binding پیش فرض، برای پشتیبانی از ASP.NET MVC و ASP.NET Web API» نیز ذکر شد:
public IActionResult Index([FromBody] MyViewModel vm)
{
   return View();
}
ذکر ویژگی FromBody در اینجا الزامی است. از این جهت که اطلاعات با فرمت JSON، از قسمت body درخواست استخراج و به MyViewModel بایند خواهند شد (در حالت dataType: json). و اگر dataType : application/x-www-form-urlencoded; charset=utf-8 بود (مانند حالت پیش فرض Unobtrusive Ajax)، باید از ویژگی FromForm استفاده شود. در غیر اینصورت در سمت سرور نال دریافت خواهیم کرد.
مطالب
تنظیمات امنیتی Glimpse
در مورد glimpse پیشتر مطالبی در سایت منتشر شده است :
 آشنایی و بررسی ابزار Glimpse 
بعد از آپلود سایت ما می‌توانیم دسترسی به تنظیمات خاص glimpse را تنها به کاربران عضو محدود کنیم:
<location path="Glimpse.axd" >
    <system.web>
        <authorization>
            <allow users="Administrator" />
            <deny users="*" />
        </authorization>
    </system.web>
</location>

یا می‌توانیم آنرا غیرفعال کنیم :
<glimpse defaultRuntimePolicy="Off" xdt:Transform="SetAttributes">
</glimpse>

همچنین می‌توانیم با پیاده سازی اینترفیس IRuntimePolicy سیاست‌های مختلف نمایش تب‌های glimpse را تعیین کنیم :
using Glimpse.AspNet.Extensions;
using Glimpse.Core.Extensibility;

namespace Test
{
    public class GlimpseSecurityPolicy:IRuntimePolicy
    {
        public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
        {
            // You can perform a check like the one below to control Glimpse's permissions within your application.
// More information about RuntimePolicies can be found at http://getglimpse.com/Help/Custom-Runtime-Policy
var httpContext = policyContext.GetHttpContext();
            if (!httpContext.User.IsInRole("Administrator "))
            {
                return RuntimePolicy.Off;
            }

            return RuntimePolicy.On;
        }

        public RuntimeEvent ExecuteOn
        {
            get { return RuntimeEvent.EndRequest; }
        }
    }
}

زمانیکه glimpse را از طریق Nuget نصب می‌کنید کلاس فوق به صورت اتوماتیک به پروژه اضافه می‌شود با این تفاوت که به صورت کامنت شده است تنها کاری شما باید انجام بدید کدهای فوق را از حالت کامنت خارج کنید و Role مربوطه را جایگزین کنید. 

نکته : کلاس فوق نیاز به رجیستر شدن ندارد و تشخیص آن توسط Glimpse به صورت خودکار انجام می‌شود.  
نظرات مطالب
شروع به کار با EF Core 1.0 - قسمت 11 - بررسی رابطه‌ی Self Referencing
کلاس مدل
    public class Category
    {
        public int Id { get; set; }

        [StringLength(450)]
        public string Name { get; set; }

        public int? ParentId { get; set; }

        public virtual Category Parent { get; set; }

        public virtual ICollection<Category> Children { get; set; }
    }

    public class CategoryConfiguration : IEntityTypeConfiguration<Category>
    {
        public void Configure(EntityTypeBuilder<Category> builder)
        {
            builder.HasIndex(c => c.ParentId);

            builder.HasOne(c => c.Parent)
                   .WithMany(c => c.Children)
                   .HasForeignKey(c => c.ParentId);
        }
    }
ودر نهایت برای افزودن مایگریشن جدید خطای ذیل
Introducing FOREIGN KEY constraint 'FK_Categories_Categories_ParentId' on table 'Categories' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint or index. See previous errors.
اشتراک‌ها
حذف کارآمدتر یک موجودیت از EntityFrameWork

بهتر است به جای اینکه برای حذف یک entity دو بار دیتابیس را فراخوانی کنیم (یکبار برای بازیابی آن براساس id و یکبار برای اجرای فرمان حذف آن از دیتابیس) توسط کد زیر فقط یکبار به بانک کوئری بزنیم. البته این موضوع برای قبل از EF7 کاربرد دارد. خود EF7 دارای متد ExecuteDeleteAsync می باشد که این مشکل را مرتفع کرده است.

{ 
    try
    {
        var person = db.Persons.Attach(new Person { Id = id });
        person.State = EntityState.Deleted;
        await db.SaveChangesAsync(); // 1 database call
    }
    catch (DbUpdateConcurrencyException e) 
    { 
        Console.WriteLine(e); 
        // will happen if record no longer exists 
    } 
}
حذف کارآمدتر یک موجودیت از EntityFrameWork
اشتراک‌ها
بررسی روش‌های صحیح استفاده‌ی از Async/Await

[09:65] - Refactoring async operations with commands
[12:52] - Don't use .Wait()
[15:41] - Avoiding context switches with ConfigureAwait(false)
[19:45] - Sometimes you don't need to use async / await
[21:22] - Using async / await inside of try/catch and using statement blocks 

بررسی روش‌های صحیح استفاده‌ی از Async/Await
نظرات مطالب
آشنایی با Refactoring - قسمت 10
سلام آقای نصیری
با تشکر از مطالب بسیار ارزنده شما. من در مورد Code Contract تحقیق کردم و سعی کردم یکم باهاش کار کنم. اول اینکه واقعا دلیل این رو نمیدونم که چرا باید ما یک برنامه خارجی را نصب کنیم تا این کدها واکنش نشان بدن.دوم اینکه نمیشه از این کدها داخل بلاک Try-Catch استفاده کرد. و میخواستم نظر شما را راجع به http://fluentvalidation.codeplex.com/ بدونم. این فریم ورک تقریبا همون کار رو انجام میده ولی استفاده ازش راحتتره. در کل به نظرم در بحث Refactoring به یک نقطه حساس رسیدیم و اون Validation هست. به نظر حقیر مسئله Validation و حلش میتونه سهم به سزایی در خوانایی کد داشته باشه. ممنون میشم اگر مثل همیشه ما رو از نظرات ارزشمند خودتون مستفیض کنید
اشتراک‌ها
پروژه LINQKit
پروژه LINQKit جمع آوری متدهای الحاقی مفیدی را جهت کار با EF انجام داده‌است. برای مثال متد AsExpandable آن امکان فراخوانی Expressionها را در متدهای الحاقی LINQ مخصوص EF فراهم می‌کند:
static string[] QueryCustomers (Expression<Func<Purchase, bool>> purchaseCriteria)
{
  var data = new MyDataContext();

  var query =
    from c in data.Customers.AsExpandable()
    where c.Purchases.Any (purchaseCriteria.Compile())
    select c.Name;

  return query.ToArray();
}
در حالت عادی، چون Customer.Purchases از نوع EntitySet است و IQueryable را پیاده سازی نمی‌کند، نمی‌توان Expression پویای دریافتی را در متد Any آن بکار برد. این نکته از مقاله‌ی بکارگیری متدها در کوئری‌های LINQ جمع آوری و به این پروژه اضافه شده‌است.
پروژه LINQKit
مطالب
آشنایی با Refactoring - قسمت 4


قسمت چهار آشنایی با Refactoring به معرفی روش «انتقال متدها» اختصاص دارد؛ انتقال متدها به مکانی بهتر. برای نمونه به کلاس‌های زیر پیش از انجام عمل Refactoring دقت کنید:

namespace Refactoring.Day3.MoveMethod.Before
{
public class BankAccount
{
public int AccountAge { get; private set; }
public int CreditScore { get; private set; }

public BankAccount(int accountAge, int creditScore)
{
AccountAge = accountAge;
CreditScore = creditScore;
}
}
}


namespace Refactoring.Day3.MoveMethod.Before
{
public class AccountInterest
{
public BankAccount Account { get; private set; }

public AccountInterest(BankAccount account)
{
Account = account;
}

public double InterestRate
{
get { return CalculateInterestRate(); }
}

public bool IntroductoryRate
{
get { return CalculateInterestRate() < 0.05; }
}

public double CalculateInterestRate()
{
if (Account.CreditScore > 800)
return 0.02;

if (Account.AccountAge > 10)
return 0.03;

return 0.05;
}
}
}


قسمت مورد نظر ما در اینجا، متد AccountInterest.CalculateInterest است. کلاس AccountInterest مرتبا نیاز دارد که از اطلاعات فیلدها و خواص کلاس BankAccount استفاده کند (نکته تشخیص نیاز به این نوع Refactoring). بنابراین بهتر است که این متد را به همان کلاس تعریف کننده‌ی فیلدها و خواص اصلی آن انتقال داد. پس از این نقل و انتقالات خواهیم داشت:

namespace Refactoring.Day3.MoveMethod.After
{
public class BankAccount
{
public int AccountAge { get; private set; }
public int CreditScore { get; private set; }

public BankAccount(int accountAge, int creditScore)
{
AccountAge = accountAge;
CreditScore = creditScore;
}

public double CalculateInterestRate()
{
if (CreditScore > 800)
return 0.02;

if (AccountAge > 10)
return 0.03;

return 0.05;
}
}
}

namespace Refactoring.Day3.MoveMethod.After
{
public class AccountInterest
{
public BankAccount Account { get; private set; }

public AccountInterest(BankAccount account)
{
Account = account;
}

public double InterestRate
{
get { return Account.CalculateInterestRate(); }
}

public bool IntroductoryRate
{
get { return Account.CalculateInterestRate() < 0.05; }
}
}
}



به همین سادگی!

یک مثال دیگر:
در ادامه به دو کلاس خودرو و موتور خودروی زیر دقت کنید:

namespace Refactoring.Day4.MoveMethod.Ex2.Before
{
public class CarEngine
{
public float LitersPerCylinder { set; get; }
public int NumCylinders { set; get; }

public CarEngine(int numCylinders, float litersPerCylinder)
{
NumCylinders = numCylinders;
LitersPerCylinder = litersPerCylinder;
}
}
}


namespace Refactoring.Day4.MoveMethod.Ex2.Before
{
public class Car
{
public CarEngine Engine { get; private set; }

public Car(CarEngine engine)
{
Engine = engine;
}

public float ComputeEngineVolume()
{
return Engine.LitersPerCylinder * Engine.NumCylinders;
}
}
}

در اینجا هم متد Car.ComputeEngineVolume چندین‌بار به اطلاعات داخلی کلاس CarEngine دسترسی داشته است؛ بنابراین بهتر است این متد را به جایی منتقل کرد که واقعا به آن تعلق دارد:

namespace Refactoring.Day4.MoveMethod.Ex2.After
{
public class CarEngine
{
public float LitersPerCylinder { set; get; }
public int NumCylinders { set; get; }

public CarEngine(int numCylinders, float litersPerCylinder)
{
NumCylinders = numCylinders;
LitersPerCylinder = litersPerCylinder;
}

public float ComputeEngineVolume()
{
return LitersPerCylinder * NumCylinders;
}
}
}

namespace Refactoring.Day4.MoveMethod.Ex2.After
{
public class Car
{
public CarEngine Engine { get; private set; }

public Car(CarEngine engine)
{
Engine = engine;
}
}
}

بهبودهای حاصل شده:
یکی دیگر از اصول برنامه نویسی شیء گرا "Tell, Don't Ask" است؛ که در مثال‌های فوق محقق شده. به این معنا که: در برنامه نویسی رویه‌ای متداول، اطلاعات از قسمت‌های مختلف کد جاری جهت انجام عملی دریافت می‌شود. اما در برنامه نویسی شیء گرا به اشیاء گفته می‌شود تا کاری را انجام دهند؛ نه اینکه از آن‌ها وضعیت یا اطلاعات داخلی‌اشان را جهت اخذ تصمیمی دریافت کنیم. به وضوح، متد Car.ComputeEngineVolume پیش از Refactoring ، اصل کپسوله سازی اطلاعات کلاس CarEngine را زیر سؤال برده است. بنابراین به اشیاء بگوئید که چکار کنند و اجازه دهید تا خودشان در مورد نحوه‌ی انجام آن، تصمیم گیرنده نهایی باشند.

مطالب
C# 6 - Expression-Bodied Members
در ادامه مطالب منتشر شده در رابطه با قابلیت‌های جدید سی‌شارپ 6، در این مطلب به بررسی یکی دیگر از این قابلیت‌ها، با نام Expression-Bodied Members خواهیم پرداخت. در واقع در سی‌شارپ 6، هدف، ساده‌سازی سینتکس و افزایش بهره‌وری برنامه‌نویس می‌باشد. در نسخه‌های قبلی سی‌شارپ برای یکسری از اعمال روتین می‌بایستی روالی‌هایی را مدام تکرار می‌کردیم؛ به عنوان مثال در تعریف پراپرتی‌های یک کلاس در حالت get-only باید هر بار توسط return مقداری را برگردانیم:
public class Person
{
   public string FirstName { get; set; }
   public string LastName { get; set; }
   public string FullName
   {
       get
       {
                return FirstName + " " + LastName;
       }
   }
}
نوشتن پراپرتی‌هایی همانند FullName منجر به نوشتن خطوط کد اضافه‌تری خواهد شد، هرچند می‌توان این حالت را با برداشتن خطوط اضافی بهبود بخشید:
public string FullName
{
       get { return FirstName + " " + LastName; }
}
اما در سی‌شارپ 6 میتوان آن را توسط expression body به یک خط کاهش داد!

استفاده از expression body برای پراپرتی‌های get-only (فقط خواندنی):

اگر در کلاس‌هایتان پراپرتی‌های get-only دارید، به راحتی می‌توانید بدنه‌ی پراپرتی را با استفاده از expression syntax خلاصه‌نویسی کنید. در واقع شما با استفاده از سینتکس lambda expression اقدام به نوشتن بدنه پراپرتی‌های موردنظرتان می‌کنید. یعنی به جای نوشتن کدی مانند:
{ get { return your expression; } }
به راحتی می‌توانید از سینتکس زیر استفاده نمائید:
=> your expression;
به عنوان مثال، میتوان پراپرتی FullName را در کلاس Person با کمک قابلیت expression body به صورت زیر بازنویسی کنیم:
public class Person
{
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public string FullName => FirstName + " " + LastName;
}
با کد فوق به راحتی توانستیم قسمت‌های اضافه‌ای را حذف کنیم. اکنون ممکن است بپرسید آیا این تغییر در performance برنامه تاثیری دارد؟ خیر؛ زیرا سینتکس فوق دقیقاً همان کد ILی را تولید خواهد کرد که در حالت عادی تولید می‌شود. همچنین delegateی را تولید نخواهد کرد؛ بلکه تنها از سینتکس lambda expression برای خلاصه‌نویسی بدنه پراپرتی استفاده می‌کند. در حال حاضر برای حالت setter سینتکسی ارائه نشده است.

استفاده از expression body برای Indexerها: 

همچنین از این قابلیت برای Indexerها نیز میتوان استفاده کرد، مثلاً به جای نوشتن کد زیر:
public string this[int number]
{
            get
            {
                if (number >= 0 && number < _values.Length)
                {
                    return _values[number];
                }
                return "Error";
            }
}
می‌توانیم کد فوق را به این صورت خلاصه‌نویسی کنیم:
public string this[int number] => (number >= 0 && number < _values.Length) ? _values[number] : "Error";
نکته: توجه داشته باشید که در هر دو حالت فوق تنها می‌توانیم برای get از expression body استفاده کنیم، هنوز سینتکسی برای حالت set ارائه نشده است.

استفاده از expression body برای متدها: 

برای متدها نیز می‌توانیم از قابلیت عنوان شده استفاده نمائیم، به عنوان مثال اگر داخل کلاس Person متد زیر را داشته باشیم:
public override string ToString()
{
      return FirstName;
}
می‌توانیم آن را به صورت زیر بنویسیم:
public override string ToString() => FirstName;
همانطور که مشاهده می‌کنید به جای نوشتن curly braces یا {} از lambda arrow یا <= استفاده کرده‌ایم. در اینجا عبارت سمت راست lambda arrow نمایانگر بدنه‌ی متد است. همچنین برای متدهای دارای پارامتر نیز به این صورت عمل می‌کنیم:
public int DoubleTheValue(int someValue) => someValue * 2;
یک عضو از کلاس که به صورت expression body نوشته شده باشد، expression bodied member نامیده می‌شود. این عضو از کلاس در ظاهر شبیه به عبارات لامبدای ناشناس (anonymous lambda expression) است. اما یک expression bodied member باید دارای نام، مقدار بازگشتی و بدنه متد باشد. 
تقریباً تمامی access modifierها در این حالت قابلیت استفاده را دارند. تنها متدهای abstract نمی‌توانند استفاده شوند.

محدودیت‌های Expression Bodied Members 
  • یکی از محدودیت‌های استفاده از expression body داشتن چندین خط دستور برای بدنه متدهایمان است. در اینحالت باید از روش سابق (statement body) استفاده نمائید. 
  • یکی دیگر از محدودیت‌ها عدم امکان استفاده از if, else, switch است. به عنوان مثال نمی‌توان کد زیر را با داشتن if و else به صورت expression body نوشت:
public override string ToString()
{
       if (MiddleName != null)
       {
                return FirstName + " " + MiddleName + " " + LastName;
       }
       else
       {
                return FirstName + " " + LastName;
       }
}
برای حالت فوق به عنوان یک روش جایگزین می‌توان از conditional operator استفاده کرد:
public override string ToString() =>
                    (MiddleName != null)
                    ? FirstName + " " + MiddleName + " " + LastName
                    : FirstName + " " + LastName;
  • همچنین نمی‌توان از for, foreach, while, do در expression body استفاده کرد، به جای آن می‌توان از عبارت‌های LINQ برای بدنه تابع استفاده کرد. به عنوان مثال متد زیر:
public IEnumerable<int> SmallNumbers()
{
    for (int i = 0; i < 10; i++)
        yield return i;
}
را می‌توان در حالت expression body به این صورت نوشت:
public IEnumerable<int> SmallNumbers() => from n in Enumerable.Range(0, 10)
                                                                         select n;
و یا به این صورت:
public IEnumerable<int> SmallNumbers() => Enumerable.Range(0, 10).Select(n => n);
  • همانطور که عنوان شد، استفاده از expression body در قسمت پراپرتی‌ها تنها محدود به پراپرتی‌های get-only (فقط خواندنی) میباشد.
  • استفاده از این قابلیت برای متدهای سازنده
  • استفاده در رخدادها
  • استفاده در finalizers
نکته: اگر می‌خواهید expression bodied member شما هم initializer داشته باشد و همچنین یک read only auto property باشد، باید مقداری سینتکس آن را تغییر دهید. همانطور که می‌دانید auto propertyها نیازی به backing field ندارند؛ بلکه در زمان کامپایل به صورت خودکار تولید خواهند شد. در نتیجه برای مقداردهی اولیه به backing fieldها می‌توانیم درون سازنده کلاس آنها را initialize کنیم:
    public class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }

        public Person()
        {
            this.FirstName = "Sirwan";
            this.LastName = "Afifi";
        }
    }
برای نوشتن پراپرتی‌های فوق به صورت expression body می‌توانیم به این صورت عمل کنیم:
public string FirstName { get; set; } = "Sirwan";
public string LastName { get; set; } = "Afifi";
اگر ReSharper را نصب کرده باشید، به شما پیشنهاد می‌دهد که از expression body استفاده نمائید: :
برای حالت فوق:

برای پراپرتی‌ها: