پاسخ به بازخورد‌های پروژه‌ها
موقع ویرایش کاربر خطا داره
بله قسمت ویرایش و حذف کاربران باقی مانده . تکمیل میکنم.
خطا مربوط به Mapping بین ویو مدل و مدل است.البته به صورت سراسری یک  ValueConverter برای تبدیل DateTime به string معرفی کردم ولی خطای Type 'System.String' does not have a default constructor 
داده شد.برای رفع خطا فعلا این تبدیلگر را غیر فعال کرده ام.
مطالب
مبانی TypeScript؛ ماژول‌ها
تاریخچه

تا پیش از نگارش 1.5 تایپ اسکریپت، مفاهیم internal modules و external modules وجود داشتند. جهت نامگذاری بهتر و کاهش سردرگمی در استفاده‌ی آن‌ها، از نگارش 1.5 به بعد، ماژول‌های داخلی به namespaces (فضاهای نام) تغییر نام یافتند و ماژول‌های خارجی به نام «ماژول» خلاصه شدند.
همچنین از نگارش 1.5 به بعد، پشتیبانی کاملی از نحوه‌ی تعریف «ماژول‌ها در ES 6» نیز به عمل می‌آید. بنابراین مطالعه‌ی آن نیز پیشنهاد می‌گردد.


مفهوم ماژول‌ها

هدف اصلی از ماژول‌ها، ارائه‌ی روشی برای مدیریت و ساماندهی پروژه‌های بزرگ با تعداد فایل‌های زیاد است. در اینجا فایل‌های ارجاعی، در زمان اجرا، توسط runtime جاوا اسکریپت بارگذاری شده و سپس به امکانات آن‌ها دسترسی خواهیم داشت. ماژول‌ها به صورت توکار در Node.JS نیز پشتیبانی می‌شوند؛ البته با فرمت common.js که کامپایلر TypeScript نیز قادر به تولید آن است.


امکان کامپایل به روش‌های قدیمی‌تر تعریف ماژول‌ها در TypeScript

در مورد انواع روش‌های قدیمی‌تر نحوه‌ی تعریف ماژول‌های در جاوا اسکریپت مانند common.js، AMD و امثال آن‌ها، مطالعه‌ی مطلب «ماژول‌ها در ES 6» توصیه می‌شود. فقط نکته‌ای که در اینجا حائز اهمیت است، این است که چون TypeScript قادر است به ES 5 نیز کامپایل شود و در ES 5 روش جدید ES 6 جهت تعریف ماژول‌ها وجود ندارد، امکان تبدیل و ترجمه‌ی کدهای TypeScript به تمام نوع‌های معروف و شناخته شده‌ی ماژول‌ها مانند common.js توسط کامپایلر TypeScript به صورت خودکار وجود دارد. برای این منظور از سوئیچ module کامپایلر استفاده می‌شود.


نحوه‌ی تعریف ماژول‌ها در TypeScript

برای تبدیل یک فایل ts به یک ماژول، تنها کافی است موردی را از آن export کنیم. آیتم‌های موجود در یک ماژول، تنها زمانی در سایر فایل‌ها قابل استفاده خواهند بود که از آن export شده باشند:
 // periodicals.ts
export interface Periodical {
   issueNumber: number;
}

export class Magazine implements Periodical {
   issueNumber: number;
}

export function GetMagazineByIssueNumber(issue: number): Magazine {
   // retrieve and return a magazine
}
در این مثال، یک اینترفیس، کلاس و متد export شده‌اند. برای این منظور واژه‌ی کلیدی export به پیش از هر کدام از آیتم‌های مدنظر اضافه شده‌است.
روش دیگر انجام این تعاریف، حذف واژه‌ی کلیدی export از تمام موارد تعریف شده و سپس خلاصه کردن آن‌ها در یک سطر، توسط روش export statement است؛ به نحو ذیل:
 // periodicals.ts
interface Periodical {
   issueNumber: number;
}

class Magazine implements Periodical {
   issueNumber: number;
}

function GetMagazineByTitle(title: string): Magazine {
   // retrieve and return a magazine
}

export { Periodical, Magazine, GetMagazineByTitle as GetMag}
مزیت این روش، مشخص بودن محل تعاریف خروجی‌ها است؛ بدون اینکه نیازی باشد تا تمام فایل‌را جهت یافتن exportها جستجو کرد.
همچنین در اینجا می‌توان نام دیگری را نیز برای خروجی‌ها درنظر گرفت. برای مثال بجای نام GetMagazineByTitle، با استفاده از as syntax، یک نام جدید معرفی شده‌است.


نحوه‌ی استفاده‌ی از ماژول‌ها در TypeScript

برای استفاده‌ی از امکانات خروجی مثال قبل، در یک ماژول دیگر، به نحو ذیل عمل می‌کنیم:
 // news.ts
import { Magazine, GetMag as GetMagazine} from './periodicals';
let newsMag: Magazine = GetMagazine('Weekly News');
در اینجا پس از تعریف واژه‌ی کلیدی import، لیست موارد مدنظر از خروجی‌های فایل periodicals را داخل یک {} می‌توان قید کرد. بنابراین نیازی نیست تا تمام خروجی‌های یک ماژول را import کرد. همچنین در اینجا نیز با استفاده از as syntax می‌توان نام جدیدی را برای موارد import شده تعیین کرد.
در انتها نیز مسیر نسبی فایل ts ماژول، بدون ذکر پسوند آن، پس از واژه‌ی کلیدی from ذکر می‌شود.

اگر نیاز است تمام خروجی‌های یک ماژول به صورت خودکار import شوند، می‌توان از * استفاده کرد:
 // kids.ts
import * as mag from './periodicals';
اینبار با توجه به as syntax استفاده شده، نحوه‌ی دسترسی به خروجی‌های ماژول مدنظر به صورت ذیل خواهد بود (ابتدا ذکر نام alias تعریف شده، به همراه یک دات):
 let kidMag: mag.Magazine= mag.GetMag('Games and Stuff!');


خروجی پیش فرض یک ماژول

اگر تنها قرار است یک آیتم از ماژولی export شود، می‌توان از مفهوم default export استفاده کرد:
 // movie.ts
export default class{
   title: string;
   director: string;
}
در این مثال export default بر روی یک کلاس بدون نام تعریف شده‌است. تعریف نام کلاس در اینجا اختیاری است و ماژول import کننده‌ی آن نیازی به دانستن این نام ندارد؛ زیرا در این حالت import کننده می‌تواند نام دلخواهی را به این خروجی پیش فرض بدهد؛ مانند AnimatedMovie بدون نیاز به ذکر {}:
 // kids.ts
import AnimatedMovie from './movie’;
let cartoon = new AnimatedMovie();
مطالب
استفاده از Fluent Validation در برنامه‌های ASP.NET Core - قسمت پنجم - اعتبارسنجی تنظیمات آغازین برنامه
در برنامه‌های ASP.NET Core، امکان دریافت تنظیمات برنامه از منابع مختلفی مانند فایل‌های JSON وجود دارد که در نگارش‌های اخیر آن، امکان اعتبارسنجی اطلاعات آن‌ها به صورت توکار نیز اضافه شده‌است؛ مانند:
services.AddOptions<BearerTokensOptions>()
           .Bind(configuration.GetSection("BearerTokens"))
           .Validate(bearerTokens =>
          {
                 return bearerTokens.AccessTokenExpirationMinutes < bearerTokens.RefreshTokenExpirationMinutes;
          }, "RefreshTokenExpirationMinutes is less than AccessTokenExpirationMinutes. Obtaining new tokens using the refresh token should happen only if the access token has expired.");
اما این امکان در مقایسه با امکاناتی که FluentValidation در اختیار ما قرار می‌دهد، بسیار ابتدایی به نظر می‌رسد. به همین جهت در این قسمت قصد داریم امکانات اعتبارسنجی کتابخانه‌ی FluentValidation را در حین آغاز برنامه، جهت تعیین اعتبار اطلاعات فایل کانفیگ آن، مورد استفاده قرار دهیم.


معرفی تنظیمات برنامه

فرض کنید فایل appsettings.json برنامه یک چنین محتوایی را دارد:
{
  "ApiSettings": {
    "AllowedEndpoints": [
      {
        "Name": "Service 1",
        "Timeout": 30,
        "Url": "http://service1.site.com"
      },
      {
        "Name": "Service 2",
        "Timeout": 10,
        "Url": "https://service2.site.com"
      }
    ]
  }
}

ایجاد مدل‌های معادل تنظیمات JSON برنامه

بر اساس تعاریف JSON فوق، می‌توان به مدل‌های زیر رسید:
using System;
using System.Collections.Generic;

namespace FluentValidationSample.Models
{
    public class AllowedEndpoint
    {
        public string Name { get; set; }
        public int Timeout { get; set; }
        public Uri Url { get; set; }
    }

    public class ApiSettings
    {
        public IEnumerable<AllowedEndpoint> AllowedEndpoints { get; set; }
    }
}
که نحوه‌ی معرفی آن به سیستم تزریق وابستگی‌های برنامه به صورت زیر است:
namespace FluentValidationSample.Web
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.Configure<ApiSettings>(Configuration.GetSection(nameof(ApiSettings)));
و پس از آن در هر قسمتی از برنامه با تزریق <IOptions<ApiSettings می‌توان به اطلاعات تنظیمات برنامه دسترسی یافت.


تعریف شرط‌های اعتبارسنجی مدل‌های تنظیمات برنامه

پس از مدلسازی تنظیمات برنامه و همچنین اتصال آن به <IOptions<ApiSettings، اکنون می‌خواهیم این مدل‌ها، شرایط زیر را برآورده کنند:
- باید مدخل ApiSettings در فایل تنظیمات برنامه وجود خارجی داشته باشد.
- می‌خواهیم AllowedEndpoint‌ها نامدار بوده و هر نام نیز منحصربفرد باشد.
- مقادیر timeout‌ها باید بین 1 و 90 تعریف شده باشند.
- تمام URLها باید منحصربفرد باشند.
- تمام URLها باید HTTPS باشند.

برای این منظور می‌توان تنظیمات زیر را توسط Fluent Validation تعریف کرد:
using System;
using System.Linq;
using FluentValidation;
using FluentValidationSample.Models;

namespace FluentValidationSample.ModelsValidations
{
    public class ApiSettingsValidator : AbstractValidator<ApiSettings>
    {
        public ApiSettingsValidator()
        {
            RuleFor(apiSetting => apiSetting).NotNull()
            .WithMessage("مدخل ApiSettings تعریف نشده‌است.");

            RuleFor(apiSetting => apiSetting.AllowedEndpoints).NotNull().NotEmpty()
            .WithMessage("مدخل AllowedEndpoints تعریف نشده‌است.");

            When(apiSetting => apiSetting.AllowedEndpoints != null,
            () =>
                {
                    RuleFor(apiSetting => apiSetting.AllowedEndpoints)
                        .Must(endpoints => endpoints.GroupBy(endpoint => endpoint.Name).Count() == endpoints.Count())
                        .WithMessage("نام‌های سرویس‌ها باید منحصربفرد باشند.");

                    RuleFor(apiSetting => apiSetting.AllowedEndpoints)
                        .Must(endpoints => !endpoints.Any(endpoint => endpoint.Timeout > 90 || endpoint.Timeout < 1))
                        .WithMessage("مقدار timeout باید بین 1 و 90 باشد");

                    RuleFor(apiSetting => apiSetting.AllowedEndpoints)
                        .Must(endpoints => endpoints.GroupBy(endpoint => endpoint.Url.ToString().ToLower()).Count() == endpoints.Count())
                        .WithMessage("آدرس‌های سرویس‌ها باید منحصربفرد باشند.");

                    RuleFor(apiSetting => apiSetting.AllowedEndpoints)
                        .Must(endpoints => endpoints.All(endpoint => endpoint.Url.Scheme.Equals("https", StringComparison.CurrentCultureIgnoreCase)))
                        .WithMessage("تمام آدرس‌ها باید HTTPS باشند.");
                });
        }
    }
}
که در اینجا نکات زیر قابل ملاحظه هستند:
- چگونه می‌توان از تعریف و وجود یک مدخل فایل JSON، اطمینان حاصل کرد (اعمال RuleFor به کل مدل).
- چگونه می‌توان اگر مدخلی تعریف شده بود، آنگاه برای آن اعتبارسنجی خاصی را تعریف کرد (متد When).
- چگونه می‌توان شرایط سفارشی خاصی را مانند بررسی منحصربفرد بودن‌ها، بررسی کرد (متد Must).


یکپارچه کردن اعتبارسنجی کتابخانه‌ی FluentValidation با اعتبارسنجی توکار مدل‌های تنظیمات برنامه توسط ASP.NET Core

در ابتدای بحث، امکان تعریف متد Validate را که از نگارش ASP.NET Core 2.2 اضافه شده‌است، مشاهده کردید:
services.AddOptions<BearerTokensOptions>()
           .Bind(configuration.GetSection("BearerTokens"))
           .Validate(bearerTokens =>
          {
                 return bearerTokens.AccessTokenExpirationMinutes < bearerTokens.RefreshTokenExpirationMinutes;
          }, "RefreshTokenExpirationMinutes is less than AccessTokenExpirationMinutes. Obtaining new tokens using the refresh token should happen only if the access token has expired.");
می‌توان این متد را با پیاده سازی اینترفیس توکار IValidateOptions نیز به سیستم ارائه داد:
namespace Microsoft.Extensions.Options
{
    public interface IValidateOptions<TOptions> where TOptions : class
    {
        ValidateOptionsResult Validate(string name, TOptions options);
    }
}
و اگر سرویس پیاده سازی کننده‌ی آن‌را با طول عمر Transient به سیستم اضافه کردیم، به صورت خودکار جهت اعتبارسنجی TOptions، مورد استفاده قرار خواهد گرفت. TOptions در این مثال همان ApiSettings است.
در ادامه یک نمونه پیاده سازی جنریک IValidateOptions استاندارد ASP.NET Core را مشاهده می‌کنید:
using System.Linq;
using FluentValidation;
using Microsoft.Extensions.Options;

namespace FluentValidationSample.ModelsValidations
{
    public class AppConfigValidator<TOptions> : IValidateOptions<TOptions> where TOptions : class
    {
        private readonly IValidator<TOptions> _validator;

        public AppConfigValidator(IValidator<TOptions> validator)
        {
            _validator = validator;
        }

        public ValidateOptionsResult Validate(string name, TOptions options)
        {
            if (options is null)
            {
                return ValidateOptionsResult.Fail("Configuration object is null.");
            }

            var validationResult = _validator.Validate(options);
            return validationResult.IsValid
                ? ValidateOptionsResult.Success
                : ValidateOptionsResult.Fail(validationResult.Errors.Select(error => error.ToString()));
        }
    }
}
همانطور که در قسمت دوم این سری این نیز بررسی کردیم، یکی از روش‌های اجرای اعتبارسنجی‌های FluentValidation، کار با اینترفیس IValidator آن است که در اینجا به سازنده‌ی این کلاس تزریق شده‌است. سپس در متد Validate این سرویس، با فراخوانی آن، کار اعتبارسنجی وهله‌ی دریافتی options صورت گرفته و اگر خطایی وجود داشته باشد، بازگشت داده می‌شود.
در آخر روش معرفی آن به سیستم به صورت زیر است:
namespace FluentValidationSample.Web
{
    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.Configure<ApiSettings>(Configuration.GetSection(nameof(ApiSettings)));
            services.AddTransient<IValidateOptions<ApiSettings>, AppConfigValidator<ApiSettings>>();
به این ترتیب هرگاه در برنامه یک چنین تعریفی را داشته باشیم که از طریق IOptions، تنظیمات برنامه را دریافت می‌کند:
namespace FluentValidationSample.Web.Controllers
{
    public class HomeController : Controller
    {
        private readonly IUsersService _usersService;
        private readonly ApiSettings _apiSettings;

        public HomeController(IUsersService usersService, IOptions<ApiSettings> apiSettings)
        {
            _usersService = usersService;
            _apiSettings = apiSettings.Value;
        }
اگر در سیستم یک <IValidateOptions<ApiSettings متناظر با <IOptions<ApiSettings ثبت شده باشد (مانند تنظیمات متد ConfigureServices فوق)، هرگاه که فراخوانی apiSettings.Value صورت گیرد، قبل از هرکاری متد Validate سرویس پیاده سازی کننده‌ی IValidateOptions متناظر، فراخوانی شده و اگر خطای اعتبارسنجی وجود داشته باشد، به صورت یک استثناء بازگشت داده می‌شود؛ مانند:
An unhandled exception occurred while processing the request.
OptionsValidationException: تمام آدرس‌ها باید HTTPS باشند.


کدهای کامل این سری را تا این قسمت از اینجا می‌توانید دریافت کنید: FluentValidationSample-part05.zip
اشتراک‌ها
ایجاد آسان دیاگرام بوسیله کامپوننت Nevron
جهت ترسیم دیاگرام کامپوننت‌های متفاوتی وجود دارند ولی Nevron کلیه پیچیدگی‌های ترسیم یک دیاگرام را پیاده سازی کرده است. یک از قابلیت‌های مثال زدنی آن ترسیم متصل کننده (connector) بصورت خودکار و هوشمند است که این قابلیت تقریباً عاری از هر گونه خطاست. بعنوان مثال هنگامی یک شیء همزمان به چند شیء متصل است ترسیم کننده‌ها بصورت مجزا و بدون هر گونه تداخلی ترسیم می‌شوند.
ایجاد آسان دیاگرام بوسیله کامپوننت Nevron
نظرات مطالب
C# 12.0 - Experimental Attribute
یک نکته‌ی تکمیلی: روش معرفی مستنداتی به استفاده کننده‌ها در مورد قابلیت آزمایشی در حال استفاده

اگر علاقمند هستید تا در حین نمایش خطاها، استفاده کننده‌ها را به آدرس خاصی نیز راهنمایی کنید، می‌توان از خاصیت UrlFormat به صورت زیر استفاده کرد:
[Experimental("SPC101", UrlFormat = "https://www.example.com/diagnostics/{0}.html")]
public static void TestMethod(string path)
در اینجا {0} به صورت خودکار با diagnostic ID جایگزین می‌شود.
نظرات مطالب
تغییرات بوجود آمده در Bundling and Minification -MVC4
- با توجه به محتوای فایل هست و این محاسبات فقط بر اساس درخواست مرورگر انجام می‌شود. یعنی هربار به ازای نمایش صفحات این کارها و محاسبات صورت نمی‌گیرد و اگر کش شده باشد (که شده برای یکسال)، اصلا فشاری به سرور وارد نمی‌شود چون مرورگر برای موارد کش شده درخواست جدیدی را به سرور ارسال نمی‌کند.
- نگارش تولیدی بر اساس هش محتوای فایل محاسبه می‌شود به صورت خودکار.
- در وب فرم‌ها هم این قابلیت مدتی هست که وجود دارد: (^)
اشتراک‌ها
استفاده از کتابخانه Puppeteer-Sharp برای خودکارسازی مرورگر در دات‌نت
Puppeteer-Sharp کتابخانه ای برای محیط دات‌نت است که به توسعه‌دهندگان این امکان را می‌دهد تا از Puppeteer، ابزار خودکارسازی مرورگر برای Node.js، در پروژه‌های خود استفاده کنند. این کتابخانه به‌ویژه برای رندر کردن صفحات وب، استخراج داده‌ها، و انجام تست‌های خودکار کاربرد دارد. با ویژگی‌هایی مانند پشتیبانی از JavaScript، امکان گرفتن اسکرین‌شات و تبدیل به PDF، و قابلیت مدیریت جلسات و کوکی‌ها، Puppeteer-Sharp ابزاری قدرتمند برای خودکارسازی و تست وب به شمار می‌رود.
استفاده از کتابخانه Puppeteer-Sharp برای خودکارسازی مرورگر در دات‌نت
مطالب
مقدمه‌ای بر صفحات Razor در ASP.NET Core 2.0 - بخش اوّل
Page یا «صفحه» در Razor، یکی از ویژگی‌های جدید در  ASP.NET Core MVC است که تمرکز کدنویسی را بر روی صفحات قرار می‌دهد و این موجب راحتی کدنویسی و بالارفتن راندمان می‌شود. این «صفحات» نیازمند استفاده از نسخۀ ASP.NET Core 2.0.0 و نسخه‌های بعد از آن هستند که در  Visual Studio 2017 Update 3 و نسخه‌های بعدی در دسترس است.
«صفحات» Razor به‌طور پیش‌‎فرض در MVC در دسترس است و کافیست در فایل  Startup.cs، «صفحات» Razor فعال شود:
public class Startup
{
    public void ConfigureServices(IServiceCollections services)
    {
        services.AddMvc(); // موجب فعال شدن «صفحات»  و کنترلرها می‌شود
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseMvc();
    }
}
تمام ویژگی‌های جدید «صفحات» Razor در اسمبلی Microsoft.AspNetCore.Mvc.RazorPages در دسترس است و کافیست بدان ارجاع دهید. همچنین اگر ارجاعی به پکیج  Microsoft.AspNetCore.Mvc  داشته باشید نیز «صفحات» Razor در دسترس خواهند بود.
«صفحۀ» زیر را در نظر بگیرید:
@page

@{
    var message = "Hello, World!";
}

<html>
<body>
    <p>@message</p>
</body>
</html>
این کد، بسیار شبیه «صفحات» ویوی Razor معمولی است؛ اما آنچه آن را متفاوت می‌سازد، استفاده از دایرکتیو page@  است. با استفاده از  page@، درواقع این فایل نقش اکشن متد MVC را نیز انجام می‌دهد و بدین معناست که می‌تواند به‌طورمستقیم، درخواست‌ها را بدون وساطت هیچ کنترلری مدیریت کند. دایرکتیو  page@، باید در ابتدای صفحۀ Razor قرار بگیرد. این دایرکتیو رفتار اصلی سایر Razorها را تحت تأثیر قرار می‌دهد.
ارتباط میان مسیرهای URL با صفحات، از طریق محل قرارگیری «صفحات» در فایل سیستم، اتفاق می‌افتد. جدول زیر نحوۀ ارتباط میان مسیر «صفحات» Razor و URL متناظر آن را نشان می‌دهد: 
 URL متناظر  نام فایل و مسیر آن 
/  یا  /Index
 /Pages/Index.cshtml
/Contact /Pages/Store/Contact.cshtml
/Store/Contact /Pages/Store/Contact.cshtml
برنامه هنگام اجرا، به‌طور پیش‌فرض، برای یافتن فایل «صفحات» Razor در پوشۀ «صفحات» جستجو می‌کند.
ویژگی‌های جدید «صفحات» Razor  بدین منظور طراحی شده‌اند تا الگوهای عمومی به‌کار رفته در پیمایش‌گر صفحات وب را آسان‌تر کنند. صفحۀ «تماس با ما» را در نظر بگیرید که در آن مدل Contact پیاده‌سازی شده است. فایل  MyApp/Contact.cs  بدین شکل است:
using System.ComponentModel.DataAnnotations;

namespace MyApp 
{
    public class Contact
    {
        [Required]
        public string Name { get; set; }

        [Required]
        public string Email { get; set; }
    }
}
و فایل ویوی آن یعنی MyApp/Pages/Contact.cshtml به شکل زیر است:
@page
@using MyApp
@using Microsoft.AspNetCore.Mvc.RazorPages
@addTagHelper "*, Microsoft.AspNetCore.Mvc.TagHelpers"
@inject ApplicationDbContext Db

@functions {
    [BindProperty]
    public Contact Contact { get; set; }

    public async Task<IActionResult> OnPostAsync()
    {
        if (ModelState.IsValid)
        {
            Db.Contacts.Add(Contact);
            await Db.SaveChangesAsync();
            return RedirectToPage();
        }

        return Page();
    }
}

<html>
<body>
    <p>فرم زیر را پر کنید تا در اسرع وقت، کارشناسان ما با شما بگیرند</p> 
    <div asp-validation-summary="All"></div>
    <form method="POST">
      <div>Name: <input asp-for="Contact.Name" /></div>
      <div>Email: <input asp-for="Contact.Email" /></div>
      <input type="submit" />
    </form>
</body>
</html>
این «صفحه»، هندلری با عنوان OnPostAsync  دارد که هنگام ارسال درخواست‌های POST (هنگامی‌که کاربری فرم را ثبت می‌کند) اجرا می‌شود. البته می‌توان برای هر نوع تقاضای HTTP، هندلری را اضافه کرد که معمولاً از  OnGet  برای هرگونه تقاضای نشان دادن یک صفحۀ HTML استفاده می‌شود و از  OnPost  برای ارسال اطلاعات از طریق فرم استفاده می‌شود و همان‌طور که می‌دانیم پسوند Async اختیاری است. اما اغلب به‌طور قراردادی به‌کار برده می‌شود. کد نوشته شده داخل OnPostAsync بسیار شبیه چیزی است که به‌طور معمول در داخل یک کنترلر نوشته می‌شود. این الگویی است برای صفحاتی که در آن‌ها بیشتر اصول اوّلیۀ MVC از قبیل بایند کردن مدل‌ها، اعتبارسنجی و نتایج اکشن‌ها قابل استفاده است.  
روند اصلی  OnPostAsync  به‌شکل زیر است:
کنترل خطاهای اعتبارسنجی.
  1. اگر خطایی نبود، اطلاعات ذخیره شده و به صفحۀ دیگر ریدایرکت می‌شود.
  2. درغیراین‌صورت، صفحه را دوباره به‌همراه خطاهای اعتبار سنجی نمایش می‌دهد.
  3. اگر اطلاعات موفقت‌آمیز وارد شوند، آنگاه متد هندلر OnPostAsync، هلپر RedirctToPage را برای برگرداندن نمونه‌ای از RedirectToPageResult فراخوانی می‌کند. این یک نوع جدید بازگشتی برای اکشن متد است که شبیه RedirectToAction  یا RedirectToRoute  است؛ با این تفاوت که مخصوص صفحات طراحی شده است.
هنگامیکه فرم ثبت شده، خطای اعتبارسنجی داشته باشد، آنگاه متد هندلر OnPostAsync هلپر متد Page را فراخوانی می‌کند. این هلپر یک نمونه از PageResult را برمی‌گرداند. این شبیه کاری است که اکشن‌ها در کنترلر‌ها، یک ویو را برگردانند. PageResult خروجی پیش‌فرض یک هندلر متد است و هندلر متدی که نوع  void  را برگرداند «صفحۀ» جاری را رندر می‌کند.
خصیصۀ  Contact از attribute جدید [BindProperty] برای مقید کردن مدل استفاده می‌کند. «صفحات» به‌طور پیش‌فرض، ویژگی‌هایی را که GET نیستند، مقید می‌کنند. مقیدکردن به خواص، موجب کاهش کدی می‌شود که شما باید در فرم مورد نظر خود بیاورید؛ مثلاً به‌راحتی می‌توان نوشت ( <input asp-for="Contacts.Name" /> ) که با این کار مقیدسازی فیلد و خصیصۀ مورد نظر به‌طور خودکار انجام می‌شود.
به‌جای استفاده از دایرکتیو  model@ در اینجا، از ویژگی جدید «صفحات» استفاده می‌کنیم. به‌طور پیش‌فرض دایرکتیو کلاس Page همان مدل است و ویژگی‌هایی شبیه مقیدکردن مدل‌ها، تگ هلپرها و هلپرهای HTML، همگی فقط با ویژگی‌هایی که درون functions@ نوشته شده‌اند، کار می‌کنند. هنگام استفاده از «صفحات» به‌طور خودکار به ویومدل دسترسی وجود دارد.
دایرکتیو  inject@  قبل از شروع هندلر متد، قرار گرفته و برای تزریق وابستگی در «صفحات» استفاده می‌شود که همانند Razor ویوهای قبل کار می‌کند. متغیر Db در اینجا از نوع  ApplicationDbContext است که به «صفحه» تزریق می‌شود. 
در اینجا نیازی به نوشتن هیچ دستوری برای اعتبارسنجی anti-forgery نیست. تولید و اعتبارسنجی anti-forgery به‌طور خودکار در «صفحات» انجام می‌شود و برای دستیابی به این ویژگی امنیتی نیاز به تنظیمات اضافه‌تری نیست.
می‌توان ویوی MyApp/Pages/Contact.chsml  را از مدل آن به شکل زیر جدا کرد: 
@page
@using MyApp
@using MyApp.Pages
@using Microsoft.AspNetCore.Mvc.RazorPages
@addTagHelper "*, Microsoft.AspNetCore.Mvc.TagHelpers"
@model ContactModel

<html>
<body>
    <p>فرم زیر را پر کنید تا در اسرع وقت، کارشناسان ما با شما بگیرند </p>
    <div asp-validation-summary="All"></div>
    <form method="POST">
      <div>Name: <input asp-for="Contact.Name" /></div>
      <div>Email: <input asp-for="Contact.Email" /></div>
      <input type="submit" />
    </form>
</body>
</html>
و بخش مدل «صفحه» را به شکل زیر:
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace MyApp.Pages
{
    public class ContactModel : PageModel
    {
        public ContactModel(ApplicationDbContext db)
        {
            Db = db;
        }

        [BindProperty]
        public Contact Contact { get; set; }

        private ApplicationDbContext Db { get; }

        public async Task<IActionResult> OnPostAsync()
        {
            if (ModelState.IsValid)
            {
                Db.Contacts.Add(Contact);
                await Db.SaveChangesAsync();
                return RedirectToPage();
            }

            return Page();
        }
    }
}
براساس قرارداد، کلاس باید به‌شکل PageModel باشد و در همان فضای نامی باشد که صفحۀ آن قرار دارد و نیازی به استفاده از functions @ نیست و تنها تغییر آن، تزریق وابستگی از طریق کلاس سازنده است. 
با استفاده از PageModel می‌توان از الگوی آزمون واحد بهره برد؛ اما مستلزم نوشتن صریح کلاس و سازندۀ آن است. مزیت «صفحات» بدون فایل PageModel این است که از کامپایل در زمان اجرا پشتیبانی می‌کنند که این قابلیت در هنگام کدنویسی مفید است.
ادامه دارد...
مطالب
کار با Docker بر روی ویندوز - قسمت سوم - نصب Docker بر روی ویندوز سرور
در قسمت قبل، Docker for Windows را بر روی ویندوز 10 نصب کردیم تا بتوانیم از هر دوی Linux Containers و Windows Containers استفاده کنیم. در این قسمت، نحوه‌ی نصب Docker را بر روی ویندوز سرور، صرفا جهت اجرای Windows Containers، بررسی می‌کنیم؛ از این جهت که در دنیای واقعی، عموما Linux Containers را بر روی سرورهای لینوکسی و Windows Containers را بر روی سرورهای ویندوزی اجرا می‌کنند.


Docker for Windows چگونه از هر دوی کانتینرهای ویندوزی و لینوکسی پشتیبانی می‌کند؟

زمانیکه docker for windows را اجرا می‌کنیم، سرویسی را ایجاد می‌کند که سبب اجرای پروسه‌ی ویژه‌ای به نام com.docker.proxy.exe می‌شود:


هنگامیکه برای مثال فرمان docker run nginx را توسط Docker CLI اجرا می‌کنیم، Docker CLI از طریق واسط یاد شده، دستورات را به MobyLinuxVM منتقل می‌کند. به این صورت است که امکان اجرای Linux Containers، بر روی ویندوز میسر می‌شوند:


اکنون اگر به Windows Containers سوئیچ کنیم (از طریق کلیک راست بر روی آیکن Docker در قسمت Tray Icons ویندوز)، پروسه‌ی dockerd.exe یا docker daemon شروع به کار خواهد کرد:


اینبار اگر مجددا از Docker CLI برای اجرای مثلا IIS Container استفاده کنیم، دستور ما از طریق واسط‌های com.docker.proxy و dockerd‌، به کانتینر ویندوزی منتقل و اجرا می‌شود:



نگاهی به معماری Docker بر روی ویندوز سرور

داکر بر روی ویندوز سرور، تنها به همراه موتور مدیریت کننده‌ی Windows Containers است:


در اینجا با صدور فرمان‌های Docker CLI، پیام‌ها مستقیما به dockerd یا موتور داکر بر روی ویندوز سرور ارسال شده و سپس کار اجرا و مدیریت یک Windows Container انجام می‌شود.


نصب Docker بر روی ویندوز سرور

جزئیات مفصل و به روز Windows Containers را همواره می‌توانید در این آدرس در سایت مستندات مجازی سازی مایکروسافت مطالعه کنید (قسمت Container Host Deployment - Windows Server آن). پیشنیاز کار با آن نیز نصب حداقل ویندوز سرور 2016 می‌باشد و بهتر است تمام به روز رسانی‌های آن‌را نیز نصب کرده باشید؛ چون تعدادی از بهبودهای کار با کانتینرهای آن، به همراه به روز رسانی‌ها آن ارائه شده‌اند.
برای شروع به نصب، نیاز است کنسول PowerShell ویندوز را با دسترسی Admin اجرا کنید.
سپس اولین دستوراتی را که نیاز است اجرا کنید، کار نصب موتور Docker و CLI آن‌را به صورت خودکار بر روی ویندوز سرور انجام می‌دهند:
Install-Module -Name DockerMsftProvider -Repository PSGallery -Force
Install-Package -Name docker -ProviderName DockerMsftProvider
Restart-Computer -Force
- که پس از نصب و ری‌استارت سیستم، نتیجه‌ی آن‌را در پوشه‌ی c:\Program Files\Docker می‌توانید ملاحظه کنید.
- به علاوه اگر دستور *get-service *docker را در کنسول PowerShell صادر کنید، مشاهده خواهید کرد که سرویس جدیدی را به نام Docker نیز نصب و راه اندازی کرده‌است که به dockerd.exe اشاره می‌کند.
- و یا اگر در کنسول PowerShell دستور docker را صادر کنید، ملاحظه خواهید کرد که CLI آن، فعال و قابل استفاده‌است. برای مثال، دستور docker version را صادر کنید تا بتوانید نگارش docker نصب شده را ملاحظه نمائید.


اجرای Image مخصوص NET Core. بر روی ویندوز سرور

تگ‌های مختلف Image مخصوص NET Core. را در اینجا ملاحظه می‌کنید. در ادامه قصد داریم tag مرتبط با nanoserver آن‌را نصب کنیم (با حجم 802MB):
docker run microsoft/dotnet:nanoserver
زمانیکه این دستور را اجرا می‌کنیم، پس از اجرای آن، ابتدا یک \:C را نمایش می‌دهد و بعد خاتمه یافته و به command prompt بازگشت داده می‌شویم. برای مشاهده‌ی علت آن، اگر دستور docker ps -a را اجرا کنیم، در ستون command آن، قسمتی از دستوری را که اجرا کرده‌است، می‌توان مشاهده کرد. برای مشاهده‌ی کامل این دستور، نیاز است دستور docker ps -a --no-trunc را اجرا کنیم. در اینجا سوئیچ no-trunc به معنای no truncate است یا عدم حذف قسمت انتهایی یک دستور طولانی. در این حالت مشاهده خواهیم کرد که این دستور، کار اجرای cmd.exe واقع در پوشه‌ی ویندوز را انجام می‌دهد (یا همان command prompt معمولی ویندوز). چون دستور docker run فوق به آن متصل نشده‌است، این پروسه ابتدا \:c را نمایش می‌دهد و سپس خاتمه پیدا می‌کند. برای رفع این مشکل، از interactive command که در قسمت قبل توضیح دادیم، استفاده خواهیم کرد:
docker run -it microsoft/dotnet:nanoserver
اینبار اگر این دستور را اجرا کنیم، به command prompt آغاز شده‌ی توسط آن، متصل خواهیم شد. اکنون اگر در همینجا (داخل container در حال اجرا) دستور dotnet --info را صادر کنید، می‌توان مشخصات NET Core SDK. نصب شده را مشاهده کرد. برای خروج از آن نیز دستور exit را صادر کنید.


چرا حجم Image مخصوص NET Core. نگارش nanoserver آن حدود 800 مگابایت است؟

در مثال قبلی، دسترسی به command prompt مجزایی نسبت به command prompt اصلی سیستم، در داخل یک container، شاید اندکی غیر منتظره بود و اکنون این سؤال مطرح می‌شود که یک image، شامل چه چیزهایی است؟
یک image شاید در ابتدای کار صرفا شامل فایل‌های اجرایی یک برنامه‌ی خاص به نظر برسد؛ اما زمانیکه قرار است تبدیل به یک container قابل اجرا شود، شامل بسیاری از فایل‌های دیگر نیز خواهد شد. برای درک این موضوع نیاز است لایه‌های نرم افزاری که یک سیستم را تشکیل می‌دهند، بررسی کنیم:


در این تصویر از پایین‌ترین لایه‌ای را که با سخت افزار ارتباط برقرار می‌کند تا بالاترین لایه‌ی موجود نرم افزاری را مشاهده می‌کنید. دراینجا هر چیزی را که در ناحیه‌ی کرنل قرار نمی‌گیرد، User Space می‌نامند. برنامه‌های قرار گرفته‌ی در User Space برای کار با سخت افزار نیاز است با کرنل ارتباط برقرار کنند و برای این منظور از System Calls استفاده می‌کنند که عموما کتابخانه‌هایی هستند که جزئی از سیستم عامل می‌باشند؛ مانند API ویندوز. برای مثال MongoDB توسط Win32 API و System Calls، فرامینی را به کرنل منتقل می‌کند.
در روش متداول توزیع و نصب نرم افزار، ما عموما همان بالاترین سطح را توزیع و نصب می‌کنیم؛ برای مثال خود MongoDB را. در اینجا نصاب MongoDB فرض می‌کند که در سیستم جاری، تمام لایه‌های دیگر، موجود و آماده‌ی استفاده هستند و اگر اینگونه نباشد، به مشکل برخواهد خورد و اجرا نمی‌شود. برای اجتناب از یک چنین مشکلاتی مانند عدم حضور وابستگی‌هایی که یک برنامه برای اجرا نیاز دارد، imageهای docker، نحوه‌ی توزیع نرم افزارها را تغییر داده‌اند. اینبار یک image بجای توزیع فقط MongoDB، شامل تمام قسمت‌های مورد نیاز User Space نیز هست:


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


به همین جهت بود که برای مثال در قسمت قبل موفق شدیم IIS مخصوص ویندوز سرور با تگ nanoserver را بر روی ویندوز 10 که بسیاری از وابستگی‌های مرتبط را به همراه ندارد، با موفقیت اجرا کنیم.
به علاوه چون یک container صرفا به معنای یک running process از یک image است، هر فایل اجرایی داخل آن image را نیز می‌توان به صورت یک container اجرا کرد؛ مانند cmd.exe داخل image مرتبط با NET Core. که آن‌را بررسی کردیم.


کارآیی Docker Containers نسبت به ماشین‌های مجازی بسیار بیشتر است

مزیت دیگر یک چنین توزیعی این است که اگر چندین container در حال اجرا را داشته باشیم:


 در نهایت تمام آن‌ها فقط با یک لایه‌ی کرنل کار می‌کنند و آن هم کرنل اصلی سیستم جاری است. به همین جهت کارآیی docker containers نسبت به ماشین‌های مجازی بیشتر است؛ چون هر ماشین مجازی، کرنل مجازی خاص خودش را نسبت به یک ماشین مجازی در حال اجرای دیگر دارد. در اینجا برای ایجاد یک لایه ایزوله‌ی اجرای برنامه‌ها، تنها کافی است یک container جدید را اجرا کنیم و در این حالت وارد فاز بوت شدن یک سیستم عامل کامل، مانند ماشین‌های مجازی نمی‌شویم.

شاید مطابق تصویر فوق اینطور به نظر برسد که هرچند تمام این containers از یک کرنل استفاده می‌کنند، اما اگر قرار باشد هر کدام OS Apps & Libs خاص خودشان را در حافظه بارگذاری کنند، با کمبود شدید منابع روبرو شویم. دقیقا مانند حالتیکه چند ماشین مجازی را اجرا کرده‌ایم و دیگر سیستم اصلی قادر به پاسخگویی به درخواست‌های رسیده به علت کمبود منابع نیست. اما در واقعیت، یک image داکر، از لایه‌های مختلفی تشکیل می‌شود که فقط خواندنی هستند و غیرقابل تغییر و زمانیکه docker یک لایه‌ی فقط خواندنی را در حافظه بارگذاری کرد، اگر container دیگری، از همان لایه‌ی تعریف شده‌، در image خود نیز استفاده می‌کند، لایه‌ی بارگذاری شده‌ی فقط خواندنی در حال اجرای موجود را با آن به اشتراک می‌گذارد (مانند تصویر زیر). به این ترتیب میزان مصرف منابع docker containers نسبت به ماشین‌های مجازی بسیار کمتر است:



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

با اجرای دستور docker run -it microsoft/dotnet:nanoserver ابتدا به command prompt داخلی و مخصوص این container منتقل می‌شویم و سپس می‌توان برای مثال با NET Core CLI. کار کرد. اما امکان اجرای این CLI به صورت زیر نیز وجود دارد:
docker run -it microsoft/dotnet:nanoserver dotnet --info
این دستور، مشخصات SDK نصب شده را نمایش می‌دهد و سپس مجددا به command prompt سیستم اصلی (که به آن میزبان، host و یا container host نیز گفته می‌شود) بازگشت داده خواهیم شد؛ چون کار NET Core CLI. خاتمه یافته‌است، پروسه‌ی متعلق به آن نیز خاتمه می‌یابد.
بدیهی است در این حالت تمام فایل‌های اجرایی داخل این container را نیز می‌توان اجرا کرد. برای مثال می‌توان کنسول پاورشل داخل این container را اجرا کرد:
docker run -it microsoft/dotnet:nanoserver powershell
زمانیکه به این کنسول دسترسی پیدا کردید، برای مثال دستور get-process را اجرا کنید. به این ترتیب می‌توانید لیست تمام پروسه‌هایی ر که هم اکنون داخل این container در حال اجرا هستند، مشاهده کنید.


هر کانتینر دارای یک File System ایزوله‌ی خاص خود است

تا اینجا دریافتیم که هر image، به همراه فایل‌های user space مورد نیاز خود نیز می‌باشد. به عبارتی هر image یک file system را نیز ارائه می‌دهد که تنها درون همان container قابل دسترسی می‌باشد و از مابقی سیستم جاری ایزوله شده‌است.
برای آزمایش آن، کنسول پاورشل را در سیستم میزبان (سیستم عامل اصلی که docker را اجرا می‌کند)، باز کرده و دستور \:ls c را صادر کنید. به این ترتیب می‌توانید لیست پوشه‌ها و فایل‌های موجود در درایو C میزبان را مشاهده نمائید. سپس دستور docker run -it microsoft/dotnet:nanoserver powershell را اجرا کنید تا به powershell داخل کانتینر NET Core. دسترسی پیدا کنیم. اکنون دستور \:ls c را مجددا اجرا کنید. خروجی آن کاملا متفاوت است نسبت به گزارشی که پیشتر بر روی سیستم میزبان تهیه کردیم؛ دقیقا مانند اینکه هارد درایو یک container متفاوت است با هارد درایو سیستم میزبان.


این تصویر زمانی تهیه شده‌است که دستور docker run یاد شده را صادر کرده‌ایم و درون powershell آن قرار داریم. همانطور که مشاهده می‌کنید یک Disk جدید، به ازای این Container در حال اجرا، به سیستم میزبان اضافه شده‌است. این Disk زمانیکه در powershell داخل container، دستور exit را صادر کنیم، بلافاصله محو می‌شود. چون پروسه‌ی container، به این ترتیب خاتمه یافته‌است.
اگر دستور docker run یاد شده را دو بار اجرا کنیم، دو Disk جدید ظاهر خواهند شد:


یک نکته: اگر بر روی این درایوهای مجازی کلیک راست کرده، گزینه‌ی change drive letter or path را انتخاب نموده و یک drive letter را به آن‌ها نسبت دهید، می‌توانید محتویات داخل آن‌ها را توسط Windows Explorer ویندوز میزبان نیز به صورت یک درایو جدید، مشاهده کنید.


خلاصه‌ای از ایزوله سازی‌های کانتینرها تا به اینجا

تا اینجا یک چنین ایزوله سازی‌هایی را بررسی کردیم:
- ایزوله سازی File System و وجود یک disk مجازی مجزا به ازای هر کانتینر در حال اجرا.

- پروسه‌های کانتینرها از پروسه‌های میزبان ایزوله هستند. برای مثال اگر دستور get-process را داخل یک container اجرا کنید، خروجی آن با خروجی اجرای این دستور بر روی سیستم میزبان یکی نیست. یعنی نمی‌توان از داخل کانتینرها، به پروسه‌های میزبان دسترسی داشت و دخل و تصرفی را در آن‌ها انجام داد که از لحاظ امنیتی بسیار مفید است. هر چند اگر به task manager ویندوز میزبان مراجعه کنید، می‌توان پروسه‌های داخل یک container را توسط Job Object ID یکسان آن‌ها تشخیص دهید (مثال آخر قسمت قبل)، اما یک container، قابلیت شمارش پروسه‌های خارج از مرز خود را ندارد.

- ایزوله سازی شبکه مانند کارت شبکه‌ی مجازی کانتینر IIS که در قسمت قبل بررسی کردیم. برای آزمایش آن دستور ipconfig را در داخل container و سپس در سیستم میزبان اجرا کنید. نتیجه‌ای را که مشاهده خواهید کرد، کاملا متفاوت است. یعنی network stack این دو کاملا از هم مجزا است. شبیه به اینکه به یک سیستم، چندین کارت شبکه را متصل کرده باشید. اینکار در اینجا با تعریف virtual network adaptors انجام می‌شود و لیست آن‌ها را در قسمت «All Control Panel Items\Network Connections» سیستم میزبان می‌توانید مشاهده کنید. یکی از مهم‌ترین مزایای آن این است که اگر در یک container، وب سروری را بر روی پورت 80 آن اجرا کنید، مهم نیست که در سیستم میزبان، یک IIS در حال سرویس دهی بر روی پورت 80 هم اکنون موجود است. این دو پورت با هم تداخل نمی‌کنند.

- در حالت کار با Windows Containers، رجیستری کانتینر نیز از میزبان آن مجزا است و یا متغیرهای محیطی این‌ها یکی نیست. برای مثال دستور \:ls env را در کانتینر و سیستم میزبان اجرا کنید تا environment variables را گزارش گیری کنید. خروجی این دو کاملا متفاوت است. برای مثال حداقل computer name، user name‌های قابل مشاهده‌ی در این گزارش‌ها، متفاوت است و یا دستور \:ls hkcu را در هر دو اجرا کنید تا خروجی رجیستری متعلق به کاربر جاری هر کدام را مشاهده کنید که در هر دو متفاوت است.

- در حالت کار با Linux Containers هر چیزی که ذیل عنوان namespace مطرح می‌شود مانند شبکه، PID، User، UTS، Mount و غیره شامل ایزوله سازی می‌شوند.


دو نوع Windows Containers وجود دارند

در ویندوز، Windows Server Containers و Hyper-V Containers وجود دارند. در این قسمت تمام کارهایی را که بر روی ویندوز سرور انجام دادیم، در حقیقت بر روی Windows Server Containers انجام شدند و تمام Containerهای ویندوزی را که در قسمت قبل بر روی ویندوز 10 ایجاد کردیم، از نوع Hyper-V Containers بودند.
تفاوت مهم این‌ها در مورد نحوه‌ی پیاده سازی ایزوله سازی آن‌ها است. در حالت Windows Server Containers، کار ایزوله سازی پروسه‌ها توسط کرنل اشتراکی بین کانتینرها صورت می‌گیرد اما در Hyper-V Containers، این ایزوله سازی توسط hypervisor آن انجام می‌شود؛ هرچند نسبت به ماشین‌های مجازی متداول بسیار سریع‌تر است، اما بحث به اشتراک گذاری کرنل هاست را که پیشتر در این قسمت بررسی کردیم، در این حالت شاهد نخواهیم بود. ویندوز سرور 2016 می‌تواند هر دوی این ایزوله سازی‌ها را پشتیبانی کند، اما ویندوز 10، فقط نوع Hyper-V را پشتیبانی می‌کند.


روش اجرای Hyper-V Containers بر روی ویندوز سرور

در صورت نیاز برای کار با Hyper-V Containers، نیاز است مانند قسمت قبل، ابتدا Hyper-V را بر روی ویندوز سرور، فعالسازی کرد:
Install-WindowsFeature hyper-v
Restart-Computer -Force
اکنون برای اجرای دستور docker run ای که توسط Hyper-V مدیریت می‌شود، می‌توان به صورت زیر، از سوئیچ isolation استفاده کرد:
docker run -it --isolation=hyperv microsoft/dotnet:nanoserver powershell
در این حالت اگر به disk management سیستم میزبان مراجعه کنید، دیگر حالت اضافه شدن disk مجازی را مشاهده نمی‌کنید. همچنین اگر به task manager ویندوز میزبان مراجعه کنید، دیگر لیست پروسه‌های داخل container را نیز در اینجا نمی‌بینید. علت آن روش ایزوله سازی متفاوت آن با Windows Server Containers است و بیشتر شبیه به ماشین‌های مجازی عمل می‌کند. در کل اگر نیاز به حداکثر و شدیدترین حالت ایزوله سازی را دارید، از این روش استفاده کنید.
نظرات مطالب
EF Code First #7
خیر. مدیریت این جدول واسط کاملا خودکار است.