مطالب دوره‌ها
مثال - نمایش بلادرنگ میزان مصرف CPU و حافظه سرور بر روی کلیه کلاینت‌های متصل توسط SignalR
یکی از کاربردهای جالب SignalR می‌تواند به روز رسانی مداوم صفحه نمایش کاربران، توسط اطلاعات ارسالی از طرف سرور باشد. در ادامه قصد داریم به عنوان منبع داده، آمار کارآیی سرور را به کلاینت‌ها ارسال کنیم و سپس به تصویری همانند شکل ذیل برسیم:


در اینجا از Smoothie Charts برای ترسیم نمودارهای بلادرنگ سازگار با Canvas مخصوص HTML5 استفاده شده است.


پیشنیازها
پیشنیازهای این مطلب با مطلب «مثال - نمایش درصد پیشرفت عملیات توسط SignalR» یکی است. برای مثال، نحوه دریافت وابستگی‌ها، تنظیمات فایل global.asax و افزودن اسکریپت‌ها، تفاوتی با مثال قبلی ندارند.


تهیه منبع داده اطلاعات نمایشی

using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace SignalR04.Common
{
    public class Counter
    {
        public string Name { set; get; }
        public float Value { set; get; }
    }

    public class PerformanceCounterProvider
    {
        private readonly List<PerformanceCounter> _counters = new List<PerformanceCounter>();

        public PerformanceCounterProvider()
        {
            _counters.Add(new PerformanceCounter("Processor", "% Processor Time", "_Total", readOnly: true));
            _counters.Add(new PerformanceCounter("Memory", "Pages/sec", readOnly: true));
            _counters.Add(new PerformanceCounter("PhysicalDisk", "% Disk Time", "_Total", readOnly: true));
        }

        public IList<Counter> GetResults()
        {
            return _counters.Select(c => new Counter
                                        {
                                            Name = c.CategoryName, 
                                            Value = c.NextValue() 
                                        }).ToList();
        }
    }
}
کلاس PerformanceCounterProvider، سه مؤلفه کارآیی سرور را بررسی کرده و هربار توسط متد GetResults، آن‌ها را بازگشت می‌دهد. از این منبع داده، در هاب برنامه استفاده خواهیم کرد.


تهیه هاب ارسال داده‌ها به کلاینت‌ها

using System.Threading;
using Microsoft.AspNet.SignalR;
using ThreadTimer = System.Threading.Timer;

namespace SignalR04.Common
{
    public class PerformanceCounterHub : Hub
    {
        private ThreadTimer _threadTimer; //keep it alive   
        private readonly PerformanceCounterProvider _perfService = new PerformanceCounterProvider();

        public PerformanceCounterHub()
        {
            _threadTimer = new ThreadTimer(timerCallback, null, Timeout.Infinite, 1000);
            _threadTimer.Change(dueTime: 1000, period: 2000);
        }

        private void timerCallback(object state)
        {
            var results = _perfService.GetResults();
            this.Clients.All.newCounters(results);
        }        
    }
}
در این هاب، یک thread timer ایجاد شده است که هر دو ثانیه یکبار، اطلاعات را از PerformanceCounterProvider دریافت و سپس با فراخوانی this.Clients.All.newCounters، آن‌ها را به کلیه کلاینت‌های متصل ارسال می‌کند.
این هاب به صورت خودکار با اولین بار وهله سازی، پس از فراخوانی متد connection.hub.start در سمت کلاینت، شروع به کار می‌کند.


کدهای سمت کلاینت نمایش نمودارها

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
    <script src="Scripts/jquery-1.6.4.min.js" type="text/javascript"></script>
    <script src="Scripts/jquery.signalR-1.1.3.min.js" type="text/javascript"></script>
    <script type="text/javascript" src='<%= ResolveClientUrl("~/signalr/hubs") %>'></script>
    <script src="Scripts/smoothie.js" type="text/javascript"></script>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <div>
            <h2>Processor</h2>
            <canvas id="Processor" width="800" height="100"></canvas>
        </div>
        <div>
            <h2>Memory</h2>
            <canvas id="Memory" width="800" height="100"></canvas>
        </div>
        <div>
            <h2>PhysicalDisk</h2>
            <canvas id="PhysicalDisk" width="800" height="100"></canvas>
        </div>
    </div>
    </form>
    <script type="text/javascript">
        var ChartEntry = function (name) {
            var self = this;
            self.name = name;
            self.chart = new SmoothieChart({ millisPerPixel: 50, labels: { fontSize: 15} });
            self.timeSeries = new TimeSeries();
            self.chart.addTimeSeries(self.timeSeries, { lineWidth: 3, strokeStyle: "#00ff00" });
        };

        ChartEntry.prototype = {
            addValue: function (value) {
                var self = this;
                self.timeSeries.append(new Date().getTime(), value);
            },

            start: function () {
                var self = this;
                self.canvas = document.getElementById(self.name);
                self.chart.streamTo(self.canvas);
            }
        };

        $(function () {
            $.connection.hub.logging = true;
            var performanceCounterHub = $.connection.performanceCounterHub;
            var charts = [];
            performanceCounterHub.client.newCounters = function (updatedCounters) {                
                $.each(updatedCounters, function (index, updateCounter) {
                    var entry;
                    $.each(charts, function (idx, chart) {                        
                        if (chart.name == updateCounter.Name) {
                            entry = chart;
                            return;
                        }
                    });

                    if (!entry) {
                        entry = new ChartEntry(updateCounter.Name);
                        charts.push(entry);
                        entry.start();                        
                    }
                    entry.addValue(updateCounter.Value);
                });
            };
            $.connection.hub.start();
        });
    </script>
</body>
</html>
- در ابتدا سه canvas بر روی صفحه قرار گرفته‌اند که معرف سه PerformanceCounter دریافتی از سرور هستند.
- id هر canavs به Name اطلاعات دریافتی از سرور تنظیم شده است تا نمودارها در جای صحیحی ترسیم شوند.
- سپس نحوه کپسوله سازی SmoothieChart را مشاهده می‌کنید؛ چطور می‌توان از آن یک شیء جاوا اسکریپتی ایجاد کرد و چطور اطلاعات را به آن اضافه نمود.
- نهایتا کار هاب را آغاز می‌کنیم. Callback ایی به نام performanceCounterHub.client.newCounters دقیقا متصل است به فراخوانی  this.Clients.All.newCounters سمت سرور. در اینجا updatedCounters دریافتی، یک آرایه جاوا اسکریپتی است که هر عضو آن دارای Name و Value است. بر این اساس، تنها کافی است این مقادیر را که هر دو ثانیه یکبار به روز می‌شوند، به SmoothieChart برای ترسیم ارسال کنیم.


کدهای کامل این مثال را از اینجا نیز می‌توانید دریافت کنید:
SignalR04.zip
 
نظرات مطالب
Blazor 5x - قسمت 34 - توزیع برنامه‌های Blazor بر روی IIS
نمونه‌ای از راه اندازی یک برنامه‌ی Blazor WASM در IIS

الف) به قسمت application pools در IIS Manager مراجعه کرده و گزینه‌ی add application pool را انتخاب کنید. سپس یک نمونه‌ی جدید را برای مثال به نام no-managed ایجاد کنید که net clr version. آن به گزینه‌ی no managed code اشاره می‌کند.
ب) پس از publish برنامه مطابق مطلب فوق (برای مثال با اجرای دستور dotnet publish -c Release) و معرفی مسیر پوشه‌ی publish به IIS (برای مثال به عنوان یک Application جدید ذیل default web site با کلیک راست بر روی default web site و انتخاب گزینه‌ی Add application)، این application pool جدید را به برنامه‌ی خود در IIS نسبت دهید. برای اینکار basic settings سایت را باز کرده و بر روی دکمه‌ی select که در کنار نام application pool هست، کلیک کرده و گزینه‌ی no-managed قسمت الف را انتخاب کنید.

نکته 1: برنامه‌های blazor wasm، یا standalone هستند و یا hosted. مورد standalone یعنی کاری به Web API ندارد و به خودی خود، به صورت یک سایت استاتیک قابل مشاهده‌است. حالت hosted یعنی به همراه web api هم هست و توسط دستور برای مثال «dotnet new blazorwasm -o BlazorIIS --hosted --no-https» ایجاد می‌شود که به همراه سه پوشه‌ی کلاینت، سرور و shared است. برای توزیع حالت متکی به خود، فقط محتویات پوشه‌ی publish، به عنوان مسیر برنامه، در IIS معرفی خواهند شد. در حالت hosted، مسیر اصلی، پوشه‌ی publish مربوط به پروژه‌ی سرور است؛ یعنی: Server\bin\Release\net5.0\publish. در این حالت پوشه‌ی Client\bin\Release\net5.0\publish باید به داخل همین پوشه‌ی publish سرور کپی شود. یعنی پوشه‌ی publish پروژه‌ی client باید به درون پوشه‌ی publish پروژه‌ی server کپی شود تا با هم یک برنامه‌ی قابل توزیع توسط IIS را تشکیل دهند.
در اینجا تنها فایل‌هایی که تداخل پیدا می‌کنند، فایل‌های web.config هستند که باید یکی شوند. فایل web.config برنامه‌ی web api با برنامه‌ی client یکی نیست، اما می‌توان محتویات این دو را با هم یکی کرد.
نکته 2: محل اجرای دستور dotnet publish -c Release مهم است. اگر این دستور را در کنار فایل sln پروژه‌ی hosted اجرا کنید، سه خروجی نهایی publish را تولید می‌کند و پس از آن باید فایل‌های کلاینت را به سرور، به صورت دستی کپی کرد. اما اگر دستور publish را درون پوشه‌ی سرور اجرا کنید، کار کپی فایل‌های کلاینت را به درون پوشه‌ی نهایی publish تشکیل شده، به صورت خودکار انجام می‌دهد؛ علت اینجا است که اگر به فایل csproj. پروژه‌ی سرور دقت کنید، ارجاعی را به پروژه‌ی کلاینت نیز دارد (هر چند ما از کدهای آن در برنامه‌ی web api استفاده نمی‌کنیم). این ارجاع تنها کمک حال دستور dotnet publish -c Release است و کاربرد دیگری را ندارد.

ج) اکنون اگر برنامه را برای مثال با مسیر فرضی جدید http://localhost/blazortest اجرا کنید، خطای 500.19 را دریافت می‌کنید. علت آن‌را در مطلب «بررسی خطاهای ممکن در حین راه اندازی اولیه برنامه‌های ASP.NET Core در IIS» بررسی کرده‌ایم. باید IIS URL Rewrite ماژول را نصب کرد؛ تا این مشکل برطرف شود. همچنین دلیل دیگر مشاهده‌ی این خطا، عدم نصب بسته‌ی هاستینگ متناظر با شماره نگارش NET. مورد استفاده‌است (اگر برنامه‌ی شما از نوع hosted است و web api هم دارد).
د) پس از آن باز هم برنامه اجرا نمی‌شود! اگر در خطاها دقت کنید، به دنبال اسکریپت‌هایی شروع شده از مسیر localhost است و نه از پوشه‌ی جدید blazortest. برای رفع این مشکل باید فایل publish\wwwroot\index.html را مطابق نکته‌ی base-URL که کمی بالاتر ذکر شد، ویرایش کرد تا blazor بداند که فایل‌ها، در چه مسیری قرار دارند (و در ریشه‌ی سایت واقع نشده‌اند):
<head>
<base href="/blazortest/" />
اکنون برنامه بدون مشکل بارگذاری و اجرا می‌شود.
مطالب
بهبودهای تولید برنامه‌های اجرایی تک فایلی در NET 6x.
تولید برنامه‌های اجرایی تک فایلی در زمان NET Core 3x. ارائه شد؛ اما به همراه این مسائل نیز بود:
- فایل اجرایی تک فایلی تولید شده در اصل یک فایل zip خود باز شونده بود که در یک مکان موقتی به صورت خودکار باز و اجرا می‌شد. این حالت با آنتی‌ویروس‌ها و یا سیستم‌هایی که قسمت‌های اصلی آن‌ها جهت کاربران عادی قفل شده‌اند، مشکلاتی را ایجاد می‌کرد.
- حجم فایل نهایی تولید شده قابل توجه بود. برای نمونه یک برنامه‌ی کنسول Hello world آن حدود 70 مگابایت می‌شد. البته باید درنظر داشت که یک چنین خروجی به همراه یک NET Core runtime. کامل نیز می‌شد.

از آن زمان تغییرات تدریجی مفیدی در این زمینه رخ داده‌اند که خلاصه‌ا‌ی از آن‌ها را تا دات نت 6 در ادامه مرور می‌کنیم.


اصول تولید برنامه‌های اجرایی تک فایلی دات نت

فرض کنید برنامه‌ی کنسول ما از این سه سطر تشکیل شده‌است:
using System;
Console.WriteLine("Hello, World!");
Console.ReadLine();
برای تولید یک برنامه‌ی اجرایی تک فایلی بر اساس آن، می‌توان دستور زیر را در خط فرمان اجرا کرد:
dotnet publish -p:PublishSingleFile=true -r win-x64 -c Release --self-contained true
در این حالت ذکر سیستم عامل هدف، اجباری است؛ از این جهت که خروجی نهایی تنها برای یک سیستم عامل تهیه می‌شود.
پس از اجرای دستور فوق، اگر به مکان C:\MyProject\bin\Release\net6.0\win-x64\publish مراجعه کنیم، به یک فایل exe حدود 62 مگابایتی خواهیم رسید که کمی کم حجم‌تر از نمونه‌ی NET Core 3x. آن است! البته همانطور که عنوان شد این خروجی به همراه runtime متناظری نیز هست. اگر بخواهیم این runtime را از آن حذف کنیم می‌توان به صورت زیر عمل کرد:
dotnet publish -p:PublishSingleFile=true -r win-x64 -c Release --self-contained false
با استفاده از سوئیچ self-contained false دیگر خروجی نهایی به همراه runtime دات نت تشکیل نخواهد شد و حجم حاصل تنها 150 کیلوبایت خواهد بود. در این حالت استفاده کننده‌ی نهایی باید runtime را خودش به صورت مجزایی نصب کند.

یک نکته: می‌توان سوئیچ‌های فوق را به فایل csproj نیز به صورت زیر اضافه کرد:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>
</Project>


تک فایل‌های اجرایی دات نت 6 دیگر فایل‌های zip خود باز شونده نیستند

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


فعالسازی IL Trimming

به صورت پیش‌فرض با اجرای دستورات تولید تک فایل‌های اجرایی برنامه‌های دات نت، تمام وابستگی‌های استفاده شده بدون هیچگونه بهینه سازی در کنار هم قرار می‌گیرند. با فعالسازی قابلیت IL Trimming می‌توان وابستگی‌هایی را که برنامه از آن‌ها استفاده نمی‌کند، از خروجی نهایی حذف کرد که در نتیجه‌ی آن، شاهد کاهش حجم قابل ملاحظه‌ی فایل تولیدی نهایی خواهیم بود. برای اینکار می‌توان سوئیچ PublishTrimmed را فعالسازی کرد:
dotnet publish -p:PublishSingleFile=true -r win-x64 -c Release --self-contained true -p:PublishTrimmed=true
پس از آن برنامه‌ی 60 مگابایتی تولیدی در ابتدای بحث، تبدیل به یک برنامه‌ی اجرایی تک فایلی 11 مگابایتی می‌شود که کاهش حجم قابل توجهی است.
باید دقت داشت که این حجم نهایی، یک فایل اجرایی واقعی بدون نیاز به نصب هیچ نوع runtime ای است و کاملا متکی به خود است.


فعالسازی فشرده سازی

به همراه دات نت 6، امکان فشرده سازی خودکار این خروجی نهایی تک فایلی، جهت کاهش هرچه بیشتر حجم آن نیز میسر شده‌است. برای اینکار می‌توان سوئیچ EnableCompressionInSingleFile را فعالسازی کرد:
dotnet publish -p:PublishSingleFile=true -r win-x64 -c Release --self-contained true -p:EnableCompressionInSingleFile=true
خروجی آن یک فایل 30 مگابایتی بدون IL Trimming است که نسبت به خروجی 60 مگابایتی ابتدای بحث، باز هم کاهش قابل ملاحظه‌ای داشته‌است.
نظرات مطالب
ASP.NET MVC #4
به این منو مراجعه کنید: Tools/Import and Export Settings 
مطالب
بررسی روش تعریف انقیاد دو طرفه‌ی سفارشی در کامپوننت‌های Angular
برخلاف AngularJS، در برنامه‌های Angular امکانات two way data binding به صورت پیش‌فرض ارائه نمی‌شوند تا از تمام مشکلات آن مانند digest cycle ،watchers و غیره خبری نباشد. اما گاهی از اوقات نیاز است انقیاد دو طرفه‌ی سفارشی را بین دو کامپوننت ایجاد کنیم. در این مطلب روش ایجاد یک چنین انقیادهایی را بررسی خواهیم کرد و در اینجا در ابتدا نیاز است دو پیشنیاز Property Binding و Event Binding را بررسی کنیم که از جمع آن‌ها two way data binding حاصل می‌شود:


البته Angular به همراه دایرکتیو ویژه‌ای به نام ngModel است که two-way data binding را با import ماژول ویژه‌ی فرم‌ها میسر می‌کند:


که آن نیز در اصل از جمع Property Binding و Event Binding تشکیل شده‌است:
<input [ngModel]="username" (ngModelChange)="username = $event">
و یا به صورت خلاصه:
<input [(ngModel)]='username' />
در اینجا می‌خواهیم یک چنین امکانی را بدون استفاده از ngModel و ماژول فرم‌ها پیاده سازی کنیم.


انقیاد به خواص یا Property binding

فرض کنید دو کامپوننت والد و فرزند را ایجاد کرده‌ایم:


در کامپوننت والد، مقداری را توسط متد deposit هربار 100 آیتم افزایش می‌دهیم:
import { Component, OnInit } from "@angular/core";

@Component({
  selector: "app-parent",
  templateUrl: "./parent.component.html",
  styleUrls: ["./parent.component.css"]
})
export class ParentComponent implements OnInit {

  amount = 500;

  constructor() { }

  ngOnInit() {
  }

  deposit() {
    this.amount += 100;
  }
}
با این قالب:
<h2>Custom two way data binding</h2>

<div class="panel panel-primary">
  <div class="panel-heading">
    <h2 class="panel-title">Parnet Component</h2>
  </div>
  <div class="panel-body">
    <label>Available amount:</label> {{amount}}
    <button (click)="deposit()" class="btn btn-success">Deposit 100</button>
    <div>
      <app-child [amount]="amount"> </app-child>
    </div>
  </div>
</div>
که در آن مقدار amount کامپوننت والد نمایش داده شده‌است و همچنین این مقدار به خاصیت ورودی کامپوننتی به نام app-child نیز نسبت داده شده‌است.

کامپوننت فرزند به صورت ذیل تعریف می‌شود:
import { Component, OnInit, Input } from "@angular/core";

@Component({
  selector: "app-child",
  templateUrl: "./child.component.html",
  styleUrls: ["./child.component.css"]
})
export class ChildComponent implements OnInit {

  @Input() amount: number;

  constructor() { }

  ngOnInit() {
  }

  withdraw() {
    this.amount -= 100;
  }
}
که در آن خاصیت amount، از والد آن، توسط ویژگی Input دریافت می‌شود. سپس در متد withdraw هربار می‌توان 100 آیتم را از آن کسر کرد.
با این قالب:
<div class="panel panel-default">
  <div class="panel-heading">
    <h2 class="panel-title">Child Component</h2>
  </div>
  <div class="panel-body">
    <label>Amount available: </label> {{amount}}

    <button (click)="withdraw()" class="btn btn-danger">Withdraw 100</button>
  </div>
</div>
که در آن مقدار amount فرزند نمایش داده شده‌است و همچنین امکان فراخوانی متد withdraw وجود دارد.

در اینجا زمانیکه data binding را به صورت ذیل تعریف می‌کنیم:
<app-child [amount]="amount"> </app-child>
روش مقدار دهی خاصیت amount داخل [] ، انقیاد به خواص نامیده می‌شود و سمت راست آن نیز یک خاصیت درنظر گرفته می‌شود. یعنی مقدار خاصیت amount والد (درون "") به مقدار خاصیت amount فرزند (درون []) نسبت داده خواهد شد.
این ارتباط نیز یک طرفه‌است. برای مثال اگر بر روی دکمه‌ی Deposit والد کلیک کنیم:


مقدار افزایش یافته‌ی در والد، به فرزند نیز منتقل می‌شود و نمایش داده خواهد شد. اما اگر بر روی دکمه‌ی withdraw فرزند کلیک کنیم:


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


انقیاد به رخ‌دادها یا Event binding

یک کامپوننت می‌تواند به رخ‌دادهای صادر شده‌ی توسط کامپوننتی دیگر گوش فرا دهد:
import { Component, OnInit, Input, Output, EventEmitter } from "@angular/core";

@Component({
  selector: "app-child",
  templateUrl: "./child.component.html",
  styleUrls: ["./child.component.css"]
})
export class ChildComponent implements OnInit {

  @Input() amount: number;
  @Output() amountChange = new EventEmitter();

  constructor() { }

  ngOnInit() {
  }

  withdraw() {
    this.amount -= 100;
    this.amountChange.emit(this.amount);
  }
}
برای این منظور در کامپوننت فرزند، یک خاصیت Output را به نام amountChange از نوع EventEmitter تعریف می‌کنیم. سپس جایی که قرار است کار کاهش amount صورت گیرد، با صدور رخ‌دادی (this.amountChange.emit)، این مقدار را به والد اعلام می‌کنیم.
اکنون در قالب کامپوننت والد، این رخ‌داد را درون یک () معرفی خواهیم کرد:
<app-child [amount]="amount" (amountChange)="this.amount= $event"> </app-child>
به این ترتیب زمانیکه کامپوننت فرزند، مقدار amount را تغییر می‌دهد، این مقدار توسط this.amountChange.emit به والد منتشر خواهد شد و می‌توان در سمت والد توسط event$ به آن دسترسی یافته و آن‌را به خاصیت this.amount کامپوننت والد نسبت دهیم.
اکنون اگر برنامه را آزمایش کنیم، با کلیک بر روی دکمه‌ی withdraw فرزند، مقدار کاهش یافته به والد نیز منعکس می‌شود:



پیاده سازی syntax ویژه‌ی Banana in a box

تا اینجا پیاده سازی two way data-binding سفارشی به پایان می‌رسد. اما تعریف طولانی:
<app-child [amount]="amount" (amountChange)="this.amount= $event"> </app-child>
به صورت ذیل هم قابل نوشتن و ساده سازی است:
<app-child [(amount)]="amount"> </app-child>
که به آن syntax ویژه Banana in a box نیز گفته می‌شود.
نکته‌ی ویژه‌ی آن، وجود پسوند Change در نام رخ‌داد تعریف شده‌است:
  @Input() amount: number;
  @Output() amountChange = new EventEmitter();
 اگر نام خاصیت Input مساوی x باشد، باید جهت فعالسازی syntax ویژه Banana in a box، نام رخ‌داد متناظر با آن دقیقا مساوی xChange انتخاب شود. مانند amount ورودی در اینجا و amountChange خروجی تعریف شده.

بنابراین به صورت خلاصه جهت تعریف یک انقیاد دو طرفه سفارشی:
- ابتدا باید انقیاد به یک خاصیت ورودی x را تعریف کرد.
- سپس نیاز است انقیاد به یک رخ‌داد خروجی هم‌نام، که نام آن، پسوند Change را اضافه‌تر دارد، یعنی xChange را تعریف کرد.
- اکنون می‌توان two-way data binding syntax ویژه‌ای را به نام banana in a box بر روی این‌دو تعریف کرد[(x)].


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


Duck typing چیست؟

duck typing به این معنا است که اگر پرنده‌ای بتواند مانند یک اردک راه برود، شنا کند و صدا در بیاورد، یک اردک نامیده می‌شود. بنابراین همینقدر که یک شیء بتواند قراردادی را پیاده سازی کند، نوع آن با نوع اینترفیس یکی درنظر گرفته می‌شود. برای نمونه به مثال ذیل دقت کنید:
interface Duck {
    walk: () => void;
    swim: () => void;
    quack: () => void;
}

let probablyADuck = {
    walk: () => console.log('walking like a duck'),
    swim: () => console.log('swimming like a duck'),
    quack: () => console.log('quacking like a duck')
}

function FlyOverWater(bird: Duck) { }

FlyOverWater(probablyADuck); // works!
در این مثال اینترفیس Duck، متدهایی را تعریف کرده‌است که یک Duck می‌تواند انجام دهد.
در ادامه متغیر و شیءایی بدون تعریف نوع آن ایجاد شده‌است که همان متدهای اینترفیس Duck را پیاده سازی می‌کند و امضای آن‌ها با امضای متدهای اینترفیس Duck یکی هستند.
سپس متد FlyOverWater تعریف شده که در آن، نوع پارامتر ورودی آن به صورت صریحی به نوع اینترفیس Duck مقید شده‌است.
در سطر بعدی، این متد با دریافت شیء probablyADuck فراخوانی شده‌است و چون این شیء تمام اجزای قرارداد Duck را پیاده سازی کرده‌است، مشکلی در اجرای آن نخواهد بود. به این حالت duck typing می‌گویند.


نحوه‌ی تعریف یک اینترفیس در TypeScript

تعریف یک اینترفیس با واژه‌ی کلیدی interface شروع شده و سپس خواص و متدهای مدنظر این قرارداد، به همراه نوع آن‌ها تعریف خواهند شد:
interface Book {
    id: number;
    title: string;
    author: string;
    pages?: number;
    markDamaged: (reason: string) => void;
}
در این مثال خواص id، title و author اجباری هستند و پیاده سازی کننده موظف است آن‌ها را به همراه داشته باشد.
در اینترفیس‌های TypeScript می‌توان خواص اختیاری و optional را نیز تعریف کرد. نمونه‌ی آن خاصیت pages در این مثال است که با ? مشخص شده‌است و نمونه‌ی آن‌را در حین تعریف پارامترهای اختیاری متدها نیز پیشتر ملاحظه کرده بودید.
تعریف متدها در یک اینترفیس، با مشخص سازی نام آن متد و ذکر یک کولن و سپس مشخص سازی امضای پارامترهای دریافتی  انجام می‌شود. نوع خروجی متد، در سمت راست علامت <= قرار خواهد گرفت.


استفاده از اینترفیس‌ها برای تعریف نوع خروجی توابع

در مثال زیر، متد CreateCustomerID دارای دو پارامتر ورودی از نوع‌های رشته‌ای و عددی است و خروجی آن نیز از نوع رشته‌ای تعریف شده‌است:
function CreateCustomerID(name: string, id: number): string {
    return name + id;
}
در ادامه تعریف متغیری را مشاهده می‌کنید که نوع آن، متدی است که با امضای متد CreateCustomerID یکسان است:
 let IdGenerator: (chars: string, nums: number) => string;
به این ترتیب امکان انتساب متد CreateCustomerID به متغیر IdGenerator وجود خواهد داشت:
IdGenerator = CreateCustomerID;
جهت مدیریت بهتر یک چنین تعریف‌هایی و همچنین امکان استفاده‌ی مجدد از آن‌ها، می‌توان از اینترفیس‌ها کمک گرفت:
interface StringGenerator {
     (chars: string, nums: number): string;
}
اینترفیس StringGenerator نام بهتر و با قابلیت استفاده‌ی مجددی را به نوع متدی که قابل انتساب است به متغیر IdGenerator، تعریف می‌کند. در اینجا syntax تعریف نوع متد، در اینترفیس StringGenerator اندکی با حالت‌های قبلی متفاوت است. در اینجا بجای استفاده از <= جهت مشخص کردن نوع خروجی متد، از کولن استفاده شده‌است.
اکنون می‌توان نحوه‌ی تعریف متغیر IdGenerator را به صورت زیر Refactor کرد و تغییر داد:
 let IdGenerator: StringGenerator;
به عنوان نمونه می‌توان یک چنین تغییری را در نحوه‌ی تعریف اینترفیس Book ابتدای بحث و تغییر متد markDamaged آن نیز اعمال کرد.


بسط و توسعه‌ی اینترفیس‌ها

بسط و توسعه‌ی اینترفیس‌ها شبیه به مباحث ارث بری هستند. به این ترتیب که با بسط یک اینترفیس از طریق اینترفیسی دیگر، می‌توان به نوعی مرکب رسید:
interface LibraryResource {
   catalogNumber: number;
}

interface LibraryBook {
   title: string;
}

interface Encyclopedia extends LibraryResource, LibraryBook {
   volume: number;
}
در این مثال، ابتدا دو اینترفیس منابع و کتاب‌های یک کتابخانه تعریف شده‌اند. سپس اینترفیس جدیدی به نام Encyclopedia با بسط این دو اینترفیس توسط واژه‌ی کلیدی extends ایجاد شده‌است.
این نوع مرکب، علاوه بر دارا بودن خاصیت volume مختص به خودش، اکنون حاوی دو خاصیت موجود در سایر اینترفیس‌های ذکر شده‌ی در قسمت extends نیز هست.
حال اگر متغیر جدیدی را از نوع Encyclopedia تعریف کنیم، جهت برآورده شده تمام اجزای قرارداد، لازم است هر سه خاصیت را مقدار دهی نمائیم:
let refBook: Encyclopedia = {
   catalogNumber: 1234,
   title: 'The Book of Everything',
   volume: 1
}


نوع کلاس‌ها

مبحث کلاس‌ها به صورت جداگانه‌ای در این سری بررسی خواهند شد. اما جهت تکمیل بحث جاری نیاز است اشاره‌ی کوتاهی به آنها شود.
همانطور که عنوان شد، اینترفیس‌ها تنها شکل و قرارداد پیاده سازی یک شیء را تعریف می‌کنند؛ بدون ارائه‌ی پیاده سازی خاصی از آن‌‌ها. تا اینجا در بحث جاری، اشیاء را توسط object literals داخل {} تعریف کردیم (مانند متغیر refBook مثال قبل). اما کلاس‌ها روش بهتری برای انجام این‌کار و تعریف اشیاء هستند.
در ذیل تعریف اینترفیس کتابدار را با تک متد doWork آن ملاحظه می‌کنید:
interface Librarian {
   doWork: () => void;
}
متد doWork دارای پارامتری نیست و خروجی نیز ندارد. سپس با استفاده از واژه‌ی کلیدی class، یک کلاس جدید را ایجاد کرده‌ایم که با استفاده‌ی واژه‌ی کلیدی implements، یک پیاده سازی مشخص از اینترفیس Librarian را ارائه می‌دهد:
class ElementarySchoolLibrarian implements Librarian {
   doWork() {
     console.log('Reading to and teaching children...');
   }
}
اکنون داخل این کلاس، پیاده سازی خاصی از متد doWork مشخص شده‌ی در قرارداد و اینترفیس Librarian را مشاهده می‌کنید.
در ادامه برای ایجاد شیءایی از روی این تعریف، به نحو ذیل عمل می‌کنیم:
 let kidsLibrarian: Librarian = new ElementarySchoolLibrarian();
kidsLibrarian.doWork();
در اینجا متغیر kidsLibrarian از نوع اینترفیس کتابدار تعریف شده‌است. به این معنا که شیءایی که به آن انتساب داده می‌شود باید این اینترفیس را پیاده سازی کند. این شیء نیز توسط واژه‌ی کلیدی new، نمونه سازی/وهله سازی می‌شود. در ادامه می‌توان به متدها و خواص شیء kidsLibrarian دسترسی یافت و آن‌ها را فراخوانی کرد.
مطالب
معرفی Docu

Docu ابزار مستند سازی کدهای دات نت شما است که هدف اصلی آن سادگی است (سادگی در مقابل نمونه‌ای مانند sandcastle و برنامه‌های کمکی آن).
مشاهده‌ی سایت اصلی آن

برای استفاده از آن، در قسمت خواص پروژه در VS.NET ، در قسمت build ، تیک مربوط به تولید XML documentation را باید گذاشت و سپس دستور زیر را در خط فرمان اجرا نمائید و همین:

docu your-assembly-name.dll


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


مطالب
تفاوت AngularJS با KnockoutJS
با پیشرفت HTML 5 و پدید آمدن چارچوب‌های مختلف JavaScript توسعه‌ی نرم افزار‌های تک صفحه ای تحت وب (Single Page Applications) محبوب شده است. 
اخیرا مطالب خوبی در رابطه با AngularJS در وبسایت جاری منتشر شده است. KnockoutJS توسط Microsoft معرفی شد و در قالب پیشفرض پروژه‌های SPA قرار گرفت ، بنابراین احتمالا این سوال برای افرادی مطرح شده است که تفاوت بین KnockoutJS و AngularJS چیست ؟ 
می توان پاسخ داد این مقایسه ممکن نیست. 
KnockoutJS : یک پیاده سازی مستقل JavaScript از الگوی MVVM با امکانات Databinding می‌باشد. Knokcout یک کتابخانه‌ی Databinding است نه یک کتاب خانه‌ی SPA
AngularJS : طبق معرفی در این مطلب AngularJS فریم ورکی متن باز و نوشته شده به زبان جاوا اسکریپت است. هدف از به وجود آمدن این فریم ورک، توسعه هر چه ساده‌تر SPA‌ها با الگوی طراحی MVC و تست پذیری هر چه آسان‌تر آن‌ها است. این فریم ورک توسط یکی از محققان Google در سال 2009 به وجود آمد. بعد‌ها این فریم ورک تحت مجوز MIT به صورت متن باز در آمد و اکنون گوگل آن را حمایت می‌کند و توسط هزاران توسعه دهنده در سرتاسر دنیا، توسعه داده می‌شود. 

بنابراین شاید بهتر باشد ذکر شود AngularJS یک Presentation Framework مخصوص برنامه‌های وب تک صفحه ای می‌باشد در حالی که KnockoutJS کتاب خانه ای با تمرکز بر Databinding می‌باشد ، بنابراین مقایسه‌ی این‌ها چندان صحیح نیست.

اگر قصد بر بررسی گزینه‌های دیگر در کنار Angular باشد ، می‌توان از Durandal نام برد. Durandal یک چارچوب SPA می‌باشد ، این چارچوب بر فراز jQuery ، RequireJS و Knockout توسعه پیدا کرده است. (سابقا برای routing از SammyJS استفاده می‌کرد که در نسخه‌های اخیر از موتور خودش استفاده می‌کند.)

Durandal از Knockout جهت Databinding و از RequireJS برای مدیریت وابستگی‌ها استفاده می‌کند.
Angular همه‌ی امکانات بالا را مستقل پیاده سازی کرده و حتی نیازی به jQuery ندارد. اگر jQuery وجود داشته باشد Angular از آن استفاده می‌کند در غیر این صورت از jQuery Lite یا jqLite استفاده می‌کند. jqLite پیاده سازی توابع متداول jQuery برای دستکاری DOM می‌باشد. اطلاعات بیشتر در اینجا

بنابراین با استفاده تنها از KnockoutJS نمی‌توان یک برنامه‌ی کامل SPA توسعه داد ، در کنار آن نیاز به کتابخانه‌های دیگری مثل jQuery برای مدیریت درخواست‌های  AJAX و استفاده از دیگر API‌ها ، Sammy برای routing و RequireJS برای مدیریت وابستگی‌ها می‌باشد.

در Knockout و در نتیجه Durandal عمل Databinding به این صورت است :
// JavaScript
var vm = {
    firstName = ko.observable('John')
};
ko.applyBindings(vm);
<!-- HTML -->
<input data-bind="value:firstName"/>
در Angular :
// JavaScript
// Inside of a personController
this.firstName = 'John';
در Angular همچنین از یک روش Controller As استفاده می‌شود :
<!-- HTML -->
<div ng-controller="personController as vm">
    <input ng-model="vm.firstName"/>
</div>
اگر تنها نیاز به یک کتابخانه‌ی Databinding باشد ، Knockout گزینه‌ی مناسبی است ، به خوبی از عمل مقید سازی داده‌ها پشتیبانی می‌کند و Syntax خوش دستی دارد اما اگر نیاز به چارچوبی برای توسعه‌ی پروژه‌های SPA می‌باشد می‌توان از Angular یا Durandal استفاده کرد. 
مقایسه‌ی Knockout با Angular همانند مقایسه‌ی موتور بنز با ماشین پورشه می‌باشد. 



مطالب
مدیریت خروجی نال از اکشن متدهای برنامه‌های ASP.NET Core
فرض کنید اکشن متد Web API شما قرار است اطلاعات رکوردی را بازگشت دهد:
using Microsoft.AspNetCore.Mvc;

namespace Core3xWebApi.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class HomeController : ControllerBase
    {
        [HttpGet]
        public ActionResult<string> Get()
        {
            return null;
        }
    }
}
و در این حالت خاص، خروجی کوئری مدنظر، نال است. اگر کلاینت سعی کند این اطلاعات را دریافت نماید، با تصویر/خروجی زیر مواجه خواهد شد:


همانطور که مشاهده می‌کنید، هیچ خروجی تولید نشده و تنها به تنظیم status-code مساوی 204 که به معنای no content است، اکتفا کرده‌است.


چرا از کشن متدهای ASP.NET Core نمی‌توان خروجی نال گرفت؟

فرمت خروجی اکشن متدها در ASP.NET Core بر اساس output formatter‌های متفاوتی مانند JSON ،XML و غیره، تعیین می‌شود. اما زمانیکه به نال می‌رسد، از یک output formatter خاص به نام HttpNoContentOutputFormatter کمک می‌گیرد. کار آن تبدیل null، به خروجی مخصوصی است که توضیح داده شد. به این معنا که هیچگاه خروجی نال برنامه، برای مثال به نحو متداولی تبدیل به یک خروجی استاندارد JSON نمی‌شود و این مساله برای Http Client‌های مختلفی که منتظر یک خروجی استاندارد هستند (مانند انواع برنامه‌های تک صفحه‌ای وب)، عموما مساله ساز است؛ چون هر status-code دیگری بجز 200 را به صورت بروز یک خطا تفسیر می‌کنند که در حالت فوق، فقط به معنای نبود اطلاعات است و نه بروز خطایی.


چگونه خروجی نال را به همان شکلی که هست بازگشت دهیم؟

HttpNoContentOutputFormatter به همراه خاصیت TreatNullValueAsNoContent نیز هست که اگر در ابتدای تنظیمات برنامه به false تنظیم شود، دیگر مقادیر نال را به خروجی no content تبدیل نمی‌کند:
namespace Core3xWebApi
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers(options =>
            {
                // remove formatter that turns nulls into 204 - No Content responses
                // this formatter breaks SPA's Http response JSON parsing
                options.OutputFormatters.RemoveType<HttpNoContentOutputFormatter>();
                options.OutputFormatters.Insert(0, new HttpNoContentOutputFormatter
                {
                    TreatNullValueAsNoContent = false
                });
            });
        }
پس از این تغییر، اگر برنامه‌ی سمت کلاینت، سعی در دریافت اطلاعاتی از API فوق کند، اینبار یک خروجی استاندارد JSON را که در آن null درج شده‌است، دریافت خواهد کرد؛ به همراه status-code مساوی 200 که در سمت کلاینت، به یک خطا نگاشت نخواهد شد (اگر کوئری ما خروجی ندارد، دلیل بر بروز خطایی نبوده؛ فقط اطلاعاتی برای نمایش نیست):

مطالب
ارتقاء به ASP.NET Core 1.0 - قسمت 10 - بررسی تغییرات Viewها
تا اینجا یک پروژه‌ی خالی ASP.NET Core 1.0 را به مرحله‌ی فعال سازی ASP.NET MVC و تنظیمات مسیریابی‌های اولیه‌ی آن رسانده‌ایم. مرحله‌ی بعد، افزودن Viewها، نمایش اطلاعاتی به کاربران و دریافت اطلاعات از آن‌ها است و همانطور که پیشتر نیز عنوان شد، برای «ارتقاء» نیاز است «15 مورد» ابتدایی مطالب ASP.NET MVC سایت را پیش از ادامه‌ی این سری مطالعه کنید.

معرفی فایل جدید ViewImports

پروژه‌ی خالی ASP.NET Core 1.0 فاقد پوشه‌ی Views به همراه فایل‌های آغازین آن است. بنابراین ابتدا در ریشه‌ی پروژه، پوشه‌ی جدید Views را ایجاد کنید.
فایل‌های آغازین این پوشه هم در مقایسه‌ی با نگارش‌های قبلی ASP.NET MVC اندکی تغییر کرده‌اند. برای مثال در نگارش قبلی، فایل web.config ایی در ریشه‌ی پوشه‌ی Views قرار داشت و چندین مقصود را فراهم می‌کرد:
الف) در آن تنظیم شده بود که هر نوع درخواستی به فایل‌های موجود در پوشه‌ی Views، برگشت خورده و قابل پردازش نباشند. این مورد هم از لحاظ مسایل امنیتی اضافه شده بود و هم اینکه در ASP.NET MVC، برخلاف وب فرم‌ها، شروع پردازش یک درخواست، از فایل‌های View شروع نمی‌شود. به همین جهت است که درخواست مستقیم آن‌ها بی‌معنا است.
در ASP.NET Core، فایل web.config از این پوشه حذف شده‌است؛ چون دیگر نیازی به آن نیست. اگر مطلب «ارتقاء به ASP.NET Core 1.0 - قسمت 4 - فعال سازی پردازش فایل‌های استاتیک» را به خاطر داشته باشید، هر پوشه‌ای که توسط میان افزار Static Files عمومی نشود، توسط کاربران برنامه قابل دسترسی نخواهد بود و چون پوشه‌ی Views هم به صورت پیش فرض توسط این میان افزار عمومی نمی‌شود، نیازی به فایل web.config، جهت قطع دسترسی به فایل‌های موجود در آن وجود ندارد.

ب) کاربرد دیگر این فایل web.config، تعریف فضاهای نام پیش فرضی بود که در فایل‌های View مورد استفاده قرار می‌گرفتند. برای مثال چون فضای نام HTML Helperهای استاندارد ASP.NET MVC در این فایل web.config قید شده بود، دیگر نیازی به تکرار آن در تمام فایل‌های View برنامه وجود نداشت. در ASP.NET Core، برای جایگزین کردن این قابلیت، فایل جدیدی را به نام ViewImports.cshtml_ معرفی کرده‌اند، تا دیگر نیازی به ارث بری از فایل web.config وجود نداشته باشد.


برای مثال اگر می‌خواهید بالای Viewهای خود، مدام ذکر using مربوط به فضای نام مدل‌ها برنامه را انجام ندهید، این سطر تکراری را به فایل جدید view imports منتقل کنید:
 @using MyProject.Models

و این فضاهای نام به صورت پیش فرض برای تمام viewها مهیا هستند و نیازی به تعریف مجدد، ندارند:
• System
• System.Linq
• System.Collections.Generic
• Microsoft.AspNetCore.Mvc
• Microsoft.AspNetCore.Mvc.Rendering


افزودن یک View جدید

در نگارش‌های پیشین ASP.NET MVC، اگر بر روی نام یک اکشن متد کلیک راست می‌کردیم، در منوی ظاهر شده، گزینه‌ی Add view وجود داشت. چنین گزینه‌ای در نگارش RTM اول ASP.NET Core وجود ندارد و مراحل ایجاد یک View جدید را باید دستی طی کنید. برای مثال اگر نام کلاس کنترلر شما PersonController است، پوشه‌ی Person را به عنوان زیر پوشه‌ی Views ایجاد کرده و سپس بر روی این پوشه کلیک راست کنید، گزینه‌ی add new item را انتخاب و سپس واژه‌ی view را جستجو کنید:


البته یک دلیل این مساله می‌تواند امکان سفارشی سازی محل قرارگیری این پوشه‌ها در ASP.NET Core نیز باشد که در ادامه آن‌را بررسی خواهیم کرد (و ابزارهای از پیش تعریف شده عموما با مکان‌های از پیش تعریف شده کار می‌کنند).


امکان پوشه بندی بهتر فایل‌های یک پروژه‌ی ASP.NET Core نسبت به مفهوم Areas در نگارش‌های پیشین ASP.NET MVC

حالت پیش فرض پوشه بندی فایل‌های اصلی برنامه‌های ASP.NET MVC، مبتنی بر فناوری‌ها است؛ برای مثال پوشه‌های views و Controllers و امثال آن تعریف شده‌اند.
Project   
- Controllers
- Models
- Services
- ViewModels
- Views
روش دیگری را که برای پوشه بندی پروژه‌های ASP.NET MVC پیشنهاد می‌کنند (که Area توکار آن نیز زیر مجموعه‌ی آن محسوب می‌شود)، اصطلاحا Feature Folder Structure نام دارد. در این حالت برنامه بر اساس ویژگی‌ها و قابلیت‌های مختلف آن پوشه بندی می‌شود؛ بجای اینکه یک پوشه‌ی کلی کنترلرها را داشته باشیم و یک پوشه‌ی کلی views را که پس از مدتی، ارتباط دادن بین این‌ها واقعا مشکل می‌شود.
هرکسی که مدتی با ASP.NET MVC کار کرده باشد حتما به این مشکل برخورده‌است. درحال پیاده سازی قابلیتی هستید و برای اینکار نیاز خواهید داشت مدام بین پوشه‌های مختلف برنامه سوئیچ کنید؛ از پوشه‌ی کنترلرها به پوشه‌ی ویووها، به پوشه‌ی اسکریپت‌ها، پوشه‌ی اشتراکی ویووها و غیره. پس از رشد برنامه به جایی خواهید رسید که دیگر نمی‌توانید تشخیص دهید این فایلی که اضافه شده‌است ارتباطش با سایر قسمت‌ها چیست؟
ایده‌ی «پوشه بندی بر اساس ویژگی‌ها»، بر مبنای قرار دادن تمام نیازهای یک ویژگی، درون یک پوشه‌ی خاص آن است:


همانطور که مشاهده می‌کنید، در این حالت تمام اجزای یک ویژگی، داخل یک پوشه قرار گرفته‌اند؛ از کنترلر مرتبط با Viewهای آن تا فایل‌های css و js خاص آن.
برای پیاده سازی آن:
1) نام پوشه‌ی Views را به Features تغییر دهید.
2) پوشه‌ای را به نام StartupCustomizations به برنامه اضافه کرده و سپس کلاس ذیل را به آن اضافه کنید:
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc.Razor;
 
namespace Core1RtmEmptyTest.StartupCustomizations
{
  public class FeatureLocationExpander : IViewLocationExpander
  {
   public void PopulateValues(ViewLocationExpanderContext context)
   {
    context.Values["customviewlocation"] = nameof(FeatureLocationExpander);
   }
 
   public IEnumerable<string> ExpandViewLocations(
    ViewLocationExpanderContext context, IEnumerable<string> viewLocations)
   {
    return new[]
    {
      "/Features/{1}/{0}.cshtml",
      "/Features/Shared/{0}.cshtml"
    };
   }
  }
}
حالت پیش فرض ASP.NET MVC، یافتن فایل‌ها در مسیرهای Views/{1}/{0}.cshtml و Views/Shared/{0}.cshtml است؛ که در اینجا {0} نام view است و {1} نام کنترلر. این ساختار هم در اینجا حفظ شده‌است؛ اما اینبار به پوشه‌ی جدید Features اشاره می‌کند.
RazorViewEngine برنامه، بر اساس وهله‌ی پیش فرضی از اینترفیس IViewLocationExpander، محل یافتن Viewها را دریافت می‌کند. با استفاده از پیاه سازی فوق، این پیش فرض‌ها را به پوشه‌ی features هدایت کرده‌ایم.
3) در ادامه به کلاس آغازین برنامه مراجعه کرده و پس از فعال سازی ASP.NET MVC، این قابلیت را فعال سازی می‌کنیم:
public void ConfigureServices(IServiceCollection services)
{
  services.AddMvc();
  services.Configure<RazorViewEngineOptions>(options =>
  {
   options.ViewLocationExpanders.Add(new FeatureLocationExpander());
  });
4) اکنون تمام فایل‌های مرتبط با یک ویژگی را به پوشه‌ی خاص آن انتقال دهید. منظور از این فایل‌ها، کنترلر، فایل‌های مدل و ویوومدل، فایل‌های ویوو و فایل‌های js و css هستند و نه مورد دیگری.
5) اکنون باید پوشه‌ی Controllers خالی شده باشد. این پوشه را کلا حذف کنید. از این جهت که کنترلرها بر اساس پیش فرض‌های ASP.NET MVC (کلاس ختم شده‌ی به کلمه‌ی Controller واقع در اسمبلی که از وابستگی‌های ASP.NET MVC استفاده می‌کند) در هر مکانی که تعریف شده باشند، یافت خواهند شد و پوشه‌ی واقع شدن آن‌ها مهم نیست.
6) در آخر به فایل project.json مراجعه کرده و قسمت publish آن‌را جهت درج نام پوشه‌ی Features اصلاح کنید (تا در حین توزیع نهایی استفاده شود):
"publishOptions": {
 "include": [
  "wwwroot",
  "Features",
  "appsettings.json",
  "web.config"
 ]
},


در اینجا نیز یک نمونه‌ی دیگر استفاده‌ی از این روش بسیار معروف را مشاهده می‌کنید.


امکان ارائه‌ی برنامه بدون ارائه‌ی فایل‌های View آن

ASP.NET Core به همراه یک EmbeddedFileProvider نیز هست. حالت پیش فرض آن PhysicalFileProvider است که بر اساس تنظیمات IViewLocationExpander توکار (و یا نمونه‌ی سفارشی فوق در مبحث پوشه‌ی ویژگی‌ها) کار می‌کند.
برای راه اندازی آن ابتدا نیاز است بسته‌ی نیوگت ذیل را به فایل project.json اضافه کرد:
{
  "dependencies": {
        //same as before
   "Microsoft.Extensions.FileProviders.Embedded": "1.0.0"
  },
سپس تنظیمات متد ConfigureServices کلاس آغازین برنامه را به صورت ذیل جهت معرفی EmbeddedFileProvider تغییر می‌دهیم:
services.AddMvc();
services.Configure<RazorViewEngineOptions>(options =>
{
  options.ViewLocationExpanders.Add(new FeatureLocationExpander());
 
  var thisAssembly = typeof(Startup).GetTypeInfo().Assembly; 
  options.FileProviders.Clear();
  options.FileProviders.Add(new EmbeddedFileProvider(thisAssembly, baseNamespace: "Core1RtmEmptyTest"));
});
و در آخر در فایل project.json، در قسمت build options، گزینه‌ی embed را مقدار دهی می‌کنیم:
"buildOptions": {
  "emitEntryPoint": true,
  "preserveCompilationContext": true,
  "embed": "Features/**/*.cshtml"
},
در اینجا چند نکته را باید مدنظر داشت:
1) اگر نام پوشه‌ی Views را به Features تغییر داده‌اید، نیاز به ثبت ViewLocationExpanders آن‌را دارید (وگرنه، خیر).
2) در اینجا جهت مثال و بررسی اینکه واقعا این فایل‌ها از اسمبلی برنامه خوانده می‌شوند، متد options.FileProviders.Clear فراخوانی شده‌است. این متد PhysicalFileProvider  پیش فرض را حذف می‌کند. کار PhysicalFileProvider  خواندن فایل‌های ویووها از فایل سیستم به صورت متداول است.
3) کار قسمت embed در تنظیمات build، افزودن فایل‌های cshtml به قسمت منابع اسمبلی است (به همین جهت دیگر نیازی به توزیع آن‌ها نخواهد بود). اگر صرفا **/Features را ذکر کنید، تمام فایل‌های موجود را پیوست می‌کند. همچنین اگر نام پوشه‌ی Views را تغییر نداده‌اید، این مقدار همان Views/**/*.cshtml خواهد بود و یا **/Views


4) در EmbeddedFileProvider می‌توان هر نوع اسمبلی را ذکر کرد. یعنی می‌توان برنامه را به صورت چندین و چند ماژول تهیه و سپس سرهم و یکپارچه کرد (options.FileProviders یک لیست قابل تکمیل است). در اینجا ذکر baseNamespace نیز مهم است. در غیر اینصورت منبع مورد نظر از اسمبلی یاد شده، قابل استخراج نخواهد بود (چون نام اسمبلی، قسمت اول نام هر منبعی است).


فعال سازی کامپایل خودکار فایل‌های View در ASP.NET Core 1.0

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