‫۵ سال قبل، جمعه ۲۹ شهریور ۱۳۹۸، ساعت ۲۳:۲۳
- System JS منسوخ شده را در اولین قسمت‌های Angular ارائه شده‌ی در این سایت می‌توانید پیدا کنید. این روش با CLI آن جایگزین شده.
- فایل index.html ای را که در نهایت تولید کرده باز کنید. تمام تگ‌های اسکریپت ذکر شده‌ی در آن‌را نیاز خواهید داشت (بیشتر از یک مورد است).
‫۵ سال قبل، پنجشنبه ۲۸ شهریور ۱۳۹۸، ساعت ۱۶:۵۸
- این چند سطری را هم که نوشتید، به علت استفاده‌ی از الگوی مخزن، کارآیی بسیار پائینی دارد:
 var tags = _blogRepository.GetAllTags(blogID).OrderBy(s => s.Id);
    var currenttags = _mapper.Map<IList<TagsViewModel>>(tags);
            if (currenttags == null)
            {
                return NotFound();

            }
            return Json(currenttags.AsQueryable()
                       .ToDataSourceResult(request.Take, request.Skip, request.Sort,
                                                       request.Filter));
ابتدا تمام اطلاعات یک جدول را دریافت می‌کنید. بعد این لیست درون حافظه‌ای را نگاشت می‌کنید (که اگر از الگوی مخزن استفاده نمی‌کردید، با یک کوئری قابل انجام بود). بعد آن‌ها را تبدیل می‌کنید به Queryable و در آخر متد ToDataSourceResult را بر روی آن فراخوانی می‌کنید. هدف از متد ToDataSourceResult این بوده که مستقیما روی کوئری LINQ to Entities شما فراخوانی شود (پیاده سازی dynamic linq است) و نه به این شکل. کل این عملیات باید یک کوئری شود؛ نه سه کوئری که یک مورد آن بدترین حالت واکشی کل اطلاعات از بانک اطلاعاتی است و سپس فیلتر کردن آن در طی دو کوئری سمت کلاینت. استفاده از dynamic linq (یا ToDataSourceResult در اینجا)، یعنی اضافه کردن where، take و skip به صورت خودکار به کوئری نهایی شما؛ یعنی عدم نیاز به تنظیم دستی هرباره‌ی این‌ها و ساده شدن کوئری نویسی. هدف آن هم اعمال به کوئری اصلی LINQ to Entities است تا در SQL نهایی ظاهر شود. اینجا است که الگوی مخزن شما نه تنها کمکی نکرده، بلکه با مخفی کردن کوئری اصلی LINQ to Entites و بازگشت کل اطلاعات به صورت درون حافظه‌ای، کارآیی برنامه را هم به شدت کاهش داده.
- مثالی که اینجا ارائه شده جهت سهولت کار و توضیح و همچنین کاهش بار ذهنی خواننده، از یک منبع داده‌ی درون حافظه‌ای ساده‌ی بدون نیاز به بانک اطلاعاتی استفاده می‌کند. نه اینکه کدهای نهایی شما باید دقیقا به این شکل باشد.
‫۵ سال قبل، پنجشنبه ۲۸ شهریور ۱۳۹۸، ساعت ۱۶:۴۸
- چون بر اساس اطلاعات header رسیده (contentType و dataType)، سیستم Binding سمت سرور، اطلاعات دریافتی را به یک JSON Object تبدیل می‌کند که این شیء نهایی، قابل انتساب به یک رشته یا عدد ساده نیست: «نکته‌ای در مورد تک پارامترها در ASP.NET Core» 
+ این اطلاعات اضافی، سمت سرور با ارث بری از DataSourceRequest قابل تعریف هستند.
یک نکته‌ی تکمیلی: چگونه دقت خواصی از نوع decimal را به صورت سراسری تنظیم کنیم؟

فرض کنید قصد دارید دقت خواصی از نوع decimal را تنظیم کنید تا با اخطار زیر مواجه نشوید:
No type was specified for the decimal column 'Price' on entity type 'Movie'. 
This will cause values to be silently truncated if they do not fit in the default precision and scale.
یک روش رفع آن، قرار دادن ویژگی Column بر روی تک تک خواص از نوع decimal، در تمام موجودیت‌های تعریف شده و تنظیم دقت آن‌ها است:
public class Movie
{
    public int ID { get; set; }

    [Column(TypeName = "decimal(18, 2)")]
    public decimal Price { get; set; }
}
روش دیگر، انجام این تنظیم به صورت سراسری است:
protected override void OnModelCreating(ModelBuilder builder)
{
    base.OnModelCreating(builder);

    foreach (var property in builder.Model.GetEntityTypes()
                                    .SelectMany(t => t.GetProperties())
                                    .Where(p => p.ClrType == typeof(decimal)
                                                || p.ClrType == typeof(decimal?)))
    {
       property.SetColumnType("decimal(18, 6)");
    }
}
که هر دو نوع خاصیت decimal و ?decimal را پوشش می‌دهد.
‫۵ سال قبل، چهارشنبه ۲۷ شهریور ۱۳۹۸، ساعت ۱۳:۱۵
یک نکته‌ی تکمیلی: در ASP.NET Core 3.0 فراموش شدن ثبت سرویس‌ها در ابتدای اجرای برنامه گوشزد می‌شود

فرض کنید WeatherForecastService شما به DataService وابستگی دارد:
public class WeatherForecastService
{
    private readonly DataService _dataService;
    public WeatherForecastService(DataService dataService)
    {
        _dataService = dataService;
    }
و اکنون از این سرویس در یک کنترلر استفاده کرده‌اید:
public class WeatherForecastController : ControllerBase
{
    private readonly WeatherForecastService _service;
    public WeatherForecastController(WeatherForecastService service)
    {
        _service = service;
    }
و در این بین، در حین معرفی وابستگی‌ها:
public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.AddSingleton<WeatherForecastService>();
ثبت سرویس Data فراموش شده‌است. اکنون اگر برنامه را اجرا کنید، پیش از شروع به کار، این اعتبارسنجی رخ خواهد داد:
Unhandled exception. System.AggregateException: Some services are not able to be constructed
(Error while validating the service descriptor 
    'ServiceType: TestApp.WeatherForecastService Lifetime: Scoped ImplementationType:
     TestApp.WeatherForecastService': Unable to resolve service for type
    'TestApp.DataService' while attempting to activate 'TestApp.WeatherForecastService'.)
به این ترتیب قبل از شروع برنامه، کمبودهای تنظیمات سیستم تزریق وابستگی‌ها گوشزد می‌شود.
‫۵ سال قبل، سه‌شنبه ۲۶ شهریور ۱۳۹۸، ساعت ۲۲:۵۱
دلیل آن عدم استفاده از تنظیمات پیش‌فرض این پروژه مانند زمان بررسی security stamp تغییر کرده‌است. حالت پیش‌فرض آن 30 دقیقه است اما در این پروژه البته به صفر تنظیم شده تا Logout آنی پیاده سازی شود. 30 دقیقه‌ی پیش‌فرض یعنی اگر کاربری را غیرفعال کردید، این شخص تا 30 دقیقه‌ی بعد می‌تواند به خرابکاری خودش ادامه دهد و هنوز لاگین باشد؛ بدون مشکلی!
‫۵ سال قبل، دوشنبه ۲۵ شهریور ۱۳۹۸، ساعت ۱۵:۴۹
هدف از فراموش شدن، دقیقا «کاملا» فراموش شدن هست؛ حتی در بک‌آپ‌های شما هم نباید اثری از آن شخص باقی بماند. این‌ها را با یک متخصص GDPR مطرح کنید و همچنین مباحث فلسفی پشت آن‌را هم خارج از این سایت پیگیری کنید؛ چون الان به نظر با درک قسمت «حق» فراموش شدن، مشکل هست، چه برسد به پیاده سازی آن. گاهی از اوقات هدف از یک مطلب یا قابلیت این نیست که حتما باید از آن استفاده کرد. هدف، طرح موضوع مرتبط با آن است؛ حداقل برای چند ثانیه‌ای فکر کردن.